How do you read an approved emergency change record as evidence when triaging a 04:00 database bulk export?

## What a change record is, and what it is not A change record is a workflow artefact: someone asserted an intention, someone else approved it, and a system stamped the times. In triage it is the single most useful non-security lookup, because it is the only place where a human wrote down in advance that unusual activity was going to happen. It is also the lookup most often over-read. **A change record is testimony about intent, not an authorisation decision made by a security control.** Nothing in a change system verifies that the statements executed were the statements described, and nothing prevents a person who holds the right credentials from raising a ticket to paper over their own activity - or an intruder holding those credentials from doing the same. So the skill is not *find the ticket*, it is *join the ticket to the observation and report the residue*. ## The four joins ### 1. Time Three timestamps matter and they are not the same: created, approved, and the planned implementation window. Compare all three to the activity time. - Ticket created and approved comfortably before the window, activity inside it: strong corroboration. - Ticket created after the activity: **a new question, not a verdict either way.** Many organisations' emergency change processes explicitly permit retrospective raising - the engineer fixes the outage at 04:00 and documents it at 04:05, because that is what the policy tells them to do. The analyst's job is to know the local policy. If retrospective raising is normal here, the finding is neutral; if it is not, you have a person who chose to create a paper trail immediately after being observed, which raises rather than lowers your suspicion. - Activity outside the stated window even though the window exists: ask why, because the window is the part the approver actually agreed to. ### 2. Scope Read what the ticket says it covers and compare it, field by field, against the record you are holding: the configuration item or hostname, the schema and object, the operation, and the volume. An emergency ticket that says *correct three rows in the payments reference table* does not cover a four-million-row read of a cardholder table. The pressure at 04:00 is to accept a ticket that is *about the same system* as though it were *about this activity*; resisting that is most of the value an analyst adds here. ### 3. Identity The audit trail carries the account that executed the statements. On a production database fleet that is very often a shared break-glass account, which names nobody. The chain you need is: audit record -> account -> break-glass checkout register (or the jump-host session log, or the privileged access management checkout) -> a human -> compare with the ticket's requester. Every hop can fail, and each failure is itself a finding: a checkout with no ticket reference, a checkout by one engineer while a different one raised the change, or an account used with no checkout at all. ### 4. Approval path Who approved it, and could they meaningfully refuse? Self-approval collapses the control to a self-declaration. Approval by a manager who was on leave, or by a group mailbox nobody reads, is the same thing wearing a suit. In an emergency-change process the approval is often a named on-call authoriser; if the record shows an approver who is not in that role, that is worth a sentence in the case. ## Enrichment that makes the alert worse Most people learn enrichment as the thing that de-escalates: you find the ticket and the alert goes away. The mirror case is the one interviewers probe. A ticket created ninety seconds after the export, requested and approved by the same person, referencing a configuration item that is not the database that was read, and with the break-glass checkout carrying no ticket reference, is **four independent facts that all point the same way**. The alert that arrived as one anomalous query is now a case with a named subject and a documented attempt at cover. The correct move is to escalate to an incident lead - and, importantly, to stop doing the obvious thing of ringing that person to ask about it, because at this point they may be the subject rather than the witness. ## What you write down Whatever the outcome, the case note should say which record you looked at, its identifier, the four join results, and the residual uncertainty in one sentence: *change CHG0048812 covers this host and window but was created after the activity and self-approved; the export volume exceeds the stated scope; break-glass checkout at 03:58 by the same engineer, no ticket reference.* That sentence is what a reviewer, an auditor or the next analyst needs, and it is the difference between an alert that was closed and an alert whose reasoning can be re-examined. ## The line to hold in the interview A change record is corroboration, never authorisation. It raises or lowers your confidence in an innocent explanation, and it can do either. If someone answers *there was an approved change, so it was a false positive*, they have handed an adversary a very cheap way to close their own alerts.