SOC 2 CC7.4 incident response evidence is the chain from detect to ticket to contain to close. An auditor who samples an incident wants those four steps with times and an owner, not a policy PDF and a green dashboard. The client is the one in the audit. Rutagon builds the record and files it in the GRC platform you already run.
Vulnerability records are a different control. We file those as SOC 2 CC7.1 vulnerability management evidence. Proof that monitoring operated is SOC 2 CC7.2 monitoring evidence. This article starts when something was detected and someone had to respond. The runbook you already keep can be named on the ticket. The evidence is the chain, not the runbook file by itself. The operational write-up of that runbook lives in the AWS security incident response runbook. We link the name. We do not paste a second copy into the sample.
The four steps, in order
Detect is an alert or a finding with a stable reference. When the detector is GuardDuty, the finding type names the issue and the resource, and the finding describes what happened, which resources were involved, and when the activity took place. AWS documents that format in GuardDuty finding format. We store the type, the resource, the time the finding describes, and the severity the finding already carries. We do not copy exploit detail into the GRC. The sample needs a pointer a reviewer can open, not a recipe.
Ticket is the work item opened from that detect reference. A ticket with no detect reference stays open in our record even if the tracker shows it closed. People write tickets from memory. The reference is what ties the story to a detector. A detect with no ticket is the other open state: something fired and nobody accepted it. Both states are visible. We do not auto-close a detect because a similar ticket exists from another week.
Contain is a recorded action with a time and a workforce id. The action is the one your runbook already names, written as a fact: access revoked, host isolated, credential retired. The record does not explain how to perform the action against a live system. Close comes after contain is present. A close time with an empty contain step leaves the chain open. Tracker status alone is not close.
detect_ref: finding-type-and-resource
detected_at: finding-time
ticket_id: required
contained_at: required-before-close
contain_action: revoke-or-isolate
owner: workforce-id
closed_at: after-contain
grc_ticket: required
The order is the control. Containment noted in chat before a ticket exists can be attached, and the ticket still has to be opened with the detect reference. We do not reorder the chain to match the order people typed. If contain truly happened first, the times say so, and the ticket still has to exist before we will mark the chain closed.
SOC 2 CC7.4 incident response evidence in the window
The population is incidents in the audit window, plus the explicit statement when the population is empty. An empty window is evidence only if detection was on. That proof is the monitoring pack, referenced by id, not recopied here. A sentence that says "no incidents" without a pointer to monitoring evidence is an open row. We will not take the team's word that nothing fired if the detector's own export is missing.
Each chain is one record in the GRC you already run. The GRC ticket id comes back onto the record so a sample is a lookup. When several alerts are the same incident, they share one ticket and the detect section lists each reference. Splitting one incident across five closed tickets with no contain step is a failure we surface. Merging unrelated detects into one ticket to make the count look small is the other failure. The owner decides the grouping. The record shows the references either way.
Severity stays the severity the detector assigned. We do not relabel a finding to match the ticket priority after the fact without keeping the original value. The reviewer can see both. A priority change is a decision with a reason, not a quiet edit.
What the reviewer still has to do
The pipeline does not declare an incident handled. A person confirms the contain action matches the runbook step they named, and a person sets close. We reject close when contain is empty, when the owner is a shared mailbox, or when the detect reference does not open. Those rejects are the production lesson. Teams close the tracker page because the graph returned to normal. The GRC chain stays open until the four fields are filled in order.
Customer-visible notice, if your procedure requires it, is a field on the same record: sent or not required, with a time. We do not invent a notice. If the procedure says notice is required and the field is empty, close is blocked. If the procedure says notice is not required for that class of detect, the field says not required and names the procedure step. The sample can then tell the difference between "we forgot" and "the procedure did not ask."
After close, the record is immutable except for an addendum. A corrected time is an addendum with an author, not an overwrite. Auditors compare the ticket history with the GRC record. A silent edit is the discrepancy. We would rather show an addendum than a clean file that does not match the tracker.
Filing without a second incident system
We read the detector and the tracker you already use. We do not ask the responder to type the same story into a third console during the incident. The collector runs when the ticket changes state, pulls the detect reference and the times, and writes the chain. If the ticket is missing a field, it opens a task for the owner. The task is the nudge. The chain is the evidence.
This is security automation behind the GRC you already run. The detector stays yours. The tracker stays yours. Rutagon builds the join from finding to ticket to contain to close. An empty contain step cannot hide inside a closed status. That join is the whole deliverable. It is not an attestation anyone else can borrow, and it is not a vulnerability scan.
Frequently Asked Questions
How is SOC 2 CC7.4 incident response evidence different from monitoring evidence?
Monitoring evidence shows the detector operated. This record starts when a detect reference exists and follows it through a ticket, a contain action, and a close. We reference the monitoring pack when the window had no incidents. We do not paste it again as if it were a response.
What is stored from a finding?
The finding type, the resource, the time the finding describes, and the severity it already carries. The GRC holds a pointer a reviewer can open. Exploit detail is not copied into the evidence file. The sample needs identity and time, not a procedure for abuse.
Can a ticket close the chain by itself?
Close in our record requires a contain time and a workforce-id owner, which a tracker status does not supply by itself. A ticket with no detect reference stays open, and a detect with no ticket stays open. Both gaps remain visible until someone fills them.
What if several alerts are one incident?
They share one ticket, and the detect section lists each reference. The owner chooses the grouping. Unrelated detects are not merged to shrink the count. Each reference remains visible on the record the auditor samples.
Where does the chain get filed?
In the GRC you already run, with the ticket id stored on the record. The collector reads the detector and the tracker you already use. Responders do not retype the story into a third tool while they are containing the issue.
Ask us what your GRC platform isn't covering. Contact Rutagon at rutagon.com/contact, 907-841-8407, or contact@rutagon.com.