SOC 2 emergency change evidence is how a hotfix survives a sample. Production broke, someone changed it, and the normal pull-request gate did not run first. Auditors allow that path when you can show who approved it after the fact, when the change landed, and when the emergency record closed. A Slack thread and a calm incident review are not those three fields.
The compliance lead reconstructs them under a deadline. The engineer who clicked in the console is on leave. Rutagon builds the record so the triple is captured while the incident is open, then files it in the GRC you already run. The planned path stays the infrastructure change evidence pipeline. Emergency is the exception path with the same audit questions and a different clock.
The triple the sample asks for
Who approved it. The approver is a person who did not make the change. Dual control after the fact is the point. The actor from CloudTrail cannot be the only name on the ticket. If your policy names a role that may approve emergencies, we check the approver against that role. A self-approval stays open.
When it landed. The timestamp comes from CloudTrail eventTime on the mutating call, or from the deploy job if the hotfix went through a pipeline with a skipped gate. Laptop clocks and "sometime during the incident" do not go in the record. AWS describes eventTime in the CloudTrail record contents. We copy eventID as well so the sample can open the event.
When it closed. Close means the emergency ticket reached the done state your policy defines, inside the window your policy defines. Many programs use the next business day. We encode your window. We do not invent one. A ticket left open because the follow-up pull request never merged is correctly unclosed. Closing it to clear a dashboard hides the drift.
actor: userIdentity.arn from CloudTrail
approver: a different person, after the fact
landed_at: eventTime
event_id: eventID
closed_at: GRC state change
follow_up_change: pull request that reconciles code
The follow-up belongs on the record. A console edit that is never reconciled comes back as Terraform drift or as a surprise at the next deploy. The emergency record stays open until that follow-up change is linked, or until an explicit accept says the console state is now the source of truth and code was updated to match. CI approval gates apply to the follow-up. The emergency path is not a permanent bypass.
SOC 2 emergency change evidence while the incident is open
Capture starts when someone declares the emergency, not the next morning. The on-call opens the GRC item with the symptom and the system. The actor is filled from the identity they used. If they have not changed anything yet, the record waits for the CloudTrail event and still exists so the approver has somewhere to sign.
The approver's action is a decision on the GRC item: approved after the fact, or rejected. Rejected means the change must be reverted and the revert has its own landed time. We have seen teams "approve" every emergency by social custom. The form still requires a second identity. A shared on-call login makes dual control impossible, so emergency access uses named users. Break-glass accounts are rare and already reviewed under break-glass AWS access review. An emergency performed as the break-glass user cites that register.
Automation watches CloudTrail for mutating calls in production by human roles outside the CI apply role. Each one needs an open emergency id or it pages. The page is how records come into existence during an incident instead of during the audit. A daily detective job is the backstop when the page was snoozed. Both write the same fields.
We do not require a full postmortem essay inside the evidence object. The auditor sample is the triple plus the follow-up link. The postmortem can live beside it. Stuffing narrative into the only structured fields makes the next export useless.
Windows, drift, and repeated emergencies
The close window is measured from landed_at to closed_at using the calendar your policy uses. We flag misses. A miss is not edited to look on time. It is a deviation with an owner, which is itself evidence that the control operates. Editing timestamps to fit the window is the failure mode we refuse to automate.
Repeated emergencies on the same system are a pipeline problem. If every release uses the emergency path, the planned change control is fiction. The monthly evidence pack includes a count of emergency records and the systems they touch. That count is for your control owner, filed in the same GRC. Rutagon does not decide your risk acceptance. We make the count honest.
Drift detection closes the loop. The next infrastructure plan that shows a change in production must reference the emergency id or open a new exception. CloudTrail evidence supplies the event. This record supplies the human approval the event does not contain. Neither is sufficient alone for an emergency sample.
Multi-account incidents stamp recipientAccountId on each event. One incident can include several events and one approval that names them. We do not clone the approval text without the event ids. A vague approval attached to the wrong account fails the sample as surely as a missing approval.
What Rutagon delivers
The form in your GRC, the CloudTrail join, the dual-control check, the close-window flag, and the link to the follow-up change. Your incident commander keeps running the incident. We do not take over communications or claim a SOC 2 attestation. The outcome you can hand an auditor is a closed emergency with actor, approver, landed time, close time, and the commit that made git true again.
If the GRC you already run has an emergency change type, we use it. If it only has a generic ticket, we use a required field set so the export still contains the triple. The tool stays yours.
Frequently Asked Questions
What has to be true for an emergency change to pass a sample?
A second person approved it, the landing time comes from CloudTrail or the deploy job, and the record closed inside the window your policy already sets. The actor and the approver are different people. A follow-up change reconciles the code or an explicit accept documents the new source of truth.
Can the person who made the change approve it later?
After-the-fact approval is dual control, so the CloudTrail actor cannot be the approver. Self-approval leaves the record open. Shared on-call logins make this check impossible, so emergency actions use named users.
When is the emergency record closed?
When your GRC reaches the done state you defined and the follow-up link is present, inside your close window. Leaving the ticket open because git was never updated is accurate. Closing it without that link hides drift until the next plan.
How do console edits get tied to a ticket during the incident?
A detector matches human mutating calls in production to an open emergency id. Unmatched calls page. The record stores eventID and eventTime. The approver signs that item rather than a reconstructed story the next week.
Where does this sit relative to normal change evidence?
Planned applies use the infrastructure change record: an approved plan, then the apply. Emergencies use this triple because the approval comes after the change lands. Both are filed in the GRC you already run, and Rutagon builds the capture without attesting your controls.
Ask us to file this evidence in the GRC you already run. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.