The first hour, and the report

Every containment action in a data incident costs something the business wants. Revoking the suspected key stops the pipeline that feeds the morning dashboards. Cutting egress to external stages breaks the partner feed. Restoring from the immutable copy throws away a day of legitimate writes. At three in the morning, with an incomplete picture and a tired on-call, the argument for waiting always sounds reasonable, and waiting is how a contained incident becomes a breach.

The fix is not braver on-calls. It is that the decision has already been taken, in daylight, by the person whose budget it costs, and written down with their name. The on-call then executes a decision rather than making one. That single change is worth more than most tooling purchases, and it costs an afternoon.

• Containment - stopping the attacker's current path from being used further: revoke, cut, isolate. It removes an edge from the live graph, at a cost to the business that must be paid without a meeting.
• Respond - the NIST CSF 2.0 function covering actions taken regarding a detected incident: analysis, containment, communication, evidence. It ends when the attacker can no longer act.
• Recover - the separate CSF function that restores assets and operations. It is only possible if a copy exists that the attacker could not reach, which is the whole argument of session 4.
• Evidence preservation - keeping the attacker's traces intact: their objects, the query history, the login records. The postmortem is built from them, and the instinct to clean up destroys them.
• The three numbers - open paths to the crown jewels, how many cross no log, and how many tables are recoverable if the admin login is lost. The report, in the form a board can compare across months.

Each of these is cheap to agree in daylight and ruinous to debate at night. Each is written as one sentence, names the role that may take it without asking, and names what it will break, so that the breakage is a known cost and not a surprise.

• Revoke the suspected credential, even if it breaks the ETL. A key that is authenticating from an unknown place is an attacker's key until proven otherwise. The 06:00 load failing is a bad morning; the reads continuing for the fifty minutes it takes to find an approver is a breach. Ironwood's sentence: "The on-call may revoke any service key or disable any login on suspicion of misuse, and the platform lead owns the resulting outage."
• Cut egress to external stages. A read that stays inside the warehouse is a smaller event than a copy that leaves. Disabling the paths by which data exits, external stages, shares, export buckets, contains the size of the incident while the credential question is worked out. It breaks the partner feed. That is the cost, and the data owner has already accepted it.
• Restore from the immutable copy rather than trust the current tables. Once an attacker has held write access, every row is suspect. The clean state is the copy they could not reach, and the day of legitimate writes lost is the price of certainty. Without session 4's immutable copy this decision does not exist, because there is nothing clean to restore from.

Notification has an order because each person on the list has a decision to make, and telling everyone at once means nobody knows whose decision is next. The order is a chain of ownership, not a chain of seniority.

Step 4 is where the technical incident becomes a legal one. What must be reported, to whom, and within how many hours varies by jurisdiction and by the kind of data, and it is a matter of law rather than platform. Those duties are taught properly in the data-governance course under breach response. What belongs on the platform side is only this: legal and communications are on the list, they are told within the hour, and they are handed the evidence rather than a summary.

NIST CSF 2.0 keeps Respond and Recover as separate functions for a reason that shows up in the first hour. Respond is the set of actions taken about a detected incident: confirming it, containing it, communicating it, preserving what it left behind. Every organisation can Respond, well or badly, because responding only requires acting on what is in front of you.

Recover is restoring the assets and the operations. It requires something to restore from, and that thing has to have survived an attacker who held the admin login. Ironwood's ladder reports recoverable tables at 0 until immutable, restore-tested backups are on, and 12 afterwards. Before session 4, Ironwood could Respond and could not Recover, and no amount of good decision-making in the first hour changes that. The first hour is where a leader finds out whether the backup decision was made.

The strongest instinct in the first hour is to clean up: drop the strange table, delete the unfamiliar stage, remove the user nobody recognises. Every one of those actions destroys the record of what happened, and the postmortem that decides what to fund next is built from exactly that record. Contain by revoking access to the objects; do not remove the objects.

• Leave the attacker's objects in place. A stage they created, a table they wrote, a role they granted. Revoke every grant on them so nothing can use them, then leave them for the investigation. Their creation timestamps and owners are the timeline.
• Snapshot the query history now. Most warehouses keep query history for a bounded window and it is not immune to housekeeping. Copy the rows for the suspect accounts, for the whole retention window, into a table the incident team owns and nobody else can write to.
• Snapshot the login history and the egress log. Which credential, from which address, at which time, and what left. The notification decision in step 4 depends on knowing what left, and the log that says so is the one that gets rotated first.
• Record who did what, when, during the response. Containment actions are themselves changes to the estate. A postmortem that cannot separate the attacker's changes from the responders' changes reaches the wrong conclusions.
• Do not rotate the evidence away. Rotating every key is the right recovery action, and it must wait until the login records tied to the old keys have been copied. The order is copy, then rotate.

The postmortem's job is one question: which edge on the inventory did this path use, and why was the control that should have closed it not there. That question can only be answered from evidence that survived the first hour.

The second and third numbers exist because two rungs of the ladder move them while the first stands still. Query logging and egress alerting leave the path count at 3 and take unseen paths from 3 to 0. Immutable backups leave the count at 3 and take recoverable tables from 0 to 12. A report with only the first number would show both controls doing nothing, and a report with only a control count would show them as one line each, indistinguishable from the firewall.

The firewall column is the reason the report matters. Seven open paths and seven unseen is a bad estate. The questionnaire answer that described it was accurate, approved, and repeated for three years, because nobody had asked for a number that could be compared to anything.

The report is also the budget. Each number, when it is the worst of the three, points at a family of controls and away from the others. Spending on the wrong family is how an estate ends up with an excellent firewall and a dark warehouse.

Recoverable at zero jumps the queue regardless of the other two, because it is the only number that decides whether there is a business to protect after the incident. Everything else is a question of how much is lost; that one is whether anything is left.

The report is worth nothing as a one-off, because the estate changes every month: a new export bucket for a new agency, a contractor's login that stayed, a key that was rotated on paper. The report is a monthly page with three parts, and its value is the diff against last month.

• The inventory file, diffed. Which nodes and edges appeared or disappeared since last month. A new edge with a blank "closed by" cell is the finding, and it is found by a diff rather than by an audit.
• The three numbers, with last month's beside them. Paths up by one means somebody opened a door; unseen up by one means a log was switched off or a copy of the data was made somewhere the log does not reach.
• The date of the last successful restore, from the immutable copy, of the crown-jewel table, into a place somebody could query. If the date is more than a quarter old, recoverable is reported as unknown, not as 12, because a backup that has not been restored is a hope.

• Never zero paths. A support agent reads customer records to do the job. That is a path, it cannot be closed without stopping the work, and a report that says zero has either stopped the work or stopped counting insiders. Promise instead that every remaining path is one the business chose to keep, and that every one of them is logged and reviewed.
• Never "no breach is possible". Promise the three numbers, their direction of travel, and the date of the last restore. Those are things the estate can deliver every month; the other sentence is a thing no estate has ever delivered.
• Never a control count as the answer. "Fourteen of sixteen controls in place" describes a checklist. The firewall-only estate scored well on one, at 7 open paths and 7 unseen. If a questionnaire insists on a control list, attach the three numbers underneath it.
• Never a recovery time without a restore date. A recovery objective is a wish until a restore has been done, timed, and written down. Report the date and the duration of the last one, or report that it has not been done.