How do you decide whether to call the DBA at 04:20 to confirm a bulk export you cannot explain?

## Why this is a decision rather than a step Every other enrichment lookup on this leaf is read-only: querying a CMDB, a change system or a checkout register changes nothing in the world. **Contacting a human is the first enrichment that writes back into the environment you are investigating.** It can resolve a case faster than any query, and it can also destroy one. Interviewers use it because it separates people who have a triage checklist from people who have thought about what the checklist does. ## Step one: name the hypothesis the call tests At 04:20 the live hypotheses for an unexplained bulk export from a production customer table are roughly: 1. **Authorised work.** The engineer was paged, took the break-glass account, and did something legitimate that no ticket cleanly covers yet. 2. **Credential compromise.** Someone else is using that engineer's access. 3. **The engineer is the subject.** They are taking data, and any paperwork around it is theirs. Under (1) and (2) the call is excellent. Under (2) especially: if the credential is stolen, the legitimate holder is not the adversary, so ringing them neither tips off anyone nor costs you anything, and it converts a maybe into a confirmed intrusion in one exchange. Under (3) the call is the single worst thing you can do at 04:20 - it tells the subject the SOC is watching, and what follows is deleted history, a cleaned laptop and a lawyer. So the real question is not *should I call* but *how much of my probability mass sits on hypothesis 3*, and **who is entitled to decide that**. Once an insider hypothesis is live, contact with the subject stops being triage enrichment and becomes an investigative decision taken by the incident lead together with legal and HR, often with employment-law constraints on what may be asked and recorded. A tier-1 analyst who makes that call alone has taken a decision that was not theirs. ## Step two: work out who you are actually calling On a shared production fleet the audit trail names an account, not a person. The chain is account -> break-glass checkout register or privileged-access session -> a named human -> a contact number. Two traps live in that chain. First, **the contact details must come from a system the possible adversary does not control**. A phone number typed into the change ticket, a signature block in an email, or a chat account are all in scope of the very compromise you are investigating. Use the corporate directory or HR record, and prefer a voice call over a message to an account that may already be in someone else's hands. Second, **the CMDB owner field is frequently stale**, and this is where that abstract data-quality problem turns into wall-clock time. If the owner named against the database left the company two years ago, the analyst spends twenty-five minutes at 04:20 walking a manager chain to find a human, while the export - if it is hostile - continues. Pre-building the fallback path is what separates a SOC that can do this at 04:00 from one that cannot: the service's on-call rota, recent deploy or change actors, code owners, the platform team's escalation line. ## Step three: ask whether something cheaper settles it Before burning a human at 04:20, spend two minutes on the lookups that might make the call unnecessary: the break-glass checkout timestamp and whether it references a ticket, the sign-in record for the session (where it originated, what authenticated), the on-call rota and paging history showing the engineer was actually woken by an incident, the change record joins. Often one of these resolves it. The call is what you do when the cheap evidence is ambiguous and the potential loss is large. ## If you call: how - **Out of band.** Voice, on a directory number, not the channel the suspicious activity used. - **Open questions, minimal disclosure.** *Are you working right now? What are you working on?* rather than *did you export four million rows from the cardholder table at 04:03?* The second sentence hands a script to anyone who wants one, and it teaches every future subject exactly what your detection sees. - **Record it.** Who you called, on which number, at what time, what they said, verbatim where it matters. This is evidence with a timestamp, and it will be read later by people who were not there. - **Treat the answer as one input.** *Yes, that was me* is a claim that must corroborate with the telemetry - the checkout, the session origin, the paging record, the destination of the rows. If they confirm activity that the records show came from an address they cannot explain, you have learned something far more valuable than a closure. ## The cost nobody records There is a human ledger too. Waking the wrong engineer three times a quarter with accusatory questions is how a SOC loses the cooperation it depends on. Calling politely, early, with a clear explanation of why, and then telling them the outcome, is what buys you a fast answer next time. The chair on the other end of that phone is a person who did nothing wrong in most of these cases, and how the SOC treats them is part of the control's effectiveness.