D3 Security · Security Operations Glossary

What Is Chain of Custody (Decision Record)?

A standalone glossary definition, part of the D3 Security Operations Glossary.

Definition

A chain of custody in security operations is the traceable record of a triage decision, running from alert intake to final action: what was read, what was queried, what came back, what was concluded, what was recommended, what was executed, and under whose authority.

The phrase comes from forensics, where it tracks physical evidence from seizure to courtroom, and an unbroken log of possession decides whether that evidence is admitted at all. Security operations inherited the term and changed its object. The thing in custody is no longer a disk image. It is a decision.

A new set of stakeholders has arrived in security operations evaluations, and they do not attend demos. Legal teams, AI-compliance functions, insurers, and financial regulators send questionnaires that ask a consistent set of questions. Show me what you did. Show me the thought process. Tell me what happened at this timestamp and why that decision was made. What data trained your models? Does our data train models used for other customers? Where does the data live, and who can access it?

Speed and accuracy claims sail through these reviews. Clarity and transparency fail them, because for most systems the honest answer is that the reasoning lives inside a model and cannot be reproduced. Regulators have never accepted trust me as documentation, and they are not starting with AI. The chain of custody is what replaces the essay with a record.

What the record has to contain

A decision record earns its name only if it covers the whole path from intake to action. The seven elements below are the ones a reviewer actually asks for:

What was read: the alert as it arrived, and the context attached to it.
What was queried: the specific lookups run against surrounding systems.
What came back: the evidence retrieved, including the queries that returned nothing.
What was concluded: the disposition, with the factors and weights behind it.
What was recommended: the action proposed, and the risk attached to that action.
What was executed: the action actually taken, with its timestamp.
Under whose authority: the human or the autonomy setting that authorized it.

Each element answers to something already written down. No single standard demands all seven, which is the reason this list has to be assembled rather than adopted.

Element	What a reviewer is testing	Nearest codified requirement
What was read	Whether the system started from the alert as it actually arrived	EU AI Act Art. 12; NIST SP 800-53 AU-3 (event, source)
What was queried	Whether the investigation was active, or inference over the alert text	RFC 3227; AU-3 (event type)
What came back	Whether absence was recorded alongside what was found	RFC 3227 (evidence collection and archiving)
What was concluded	Whether the disposition ties to specific evidence and weights	EU AI Act Art. 12 (reconstruction of decisions), Art. 13
What was recommended	Whether the risk of the action was assessed before it was proposed	NIS2 Art. 21 (incident handling); DORA Art. 17
What was executed	Whether execution is recorded separately from recommendation	AU-3 (outcome, timestamp); FRE 803(6)
Under whose authority	Whether a specific authority can be named for this action	EU AI Act Art. 14 (human oversight); AU-3 (identity)

The mapping also exposes what the standards leave out. NIST SP 800-53 control AU-3 sets out what an audit record must contain: the type of event, when it occurred, where it occurred, its source, its outcome, and the identity of the parties involved. Read that list against the seven elements and the gap is plain. AU-3 establishes what happened. It never asks why. An audit log built to AU-3 can be complete, conformant, and still useless in a dispute, because the disputed thing is the reasoning.

One caveat on scope, since published guidance gets this wrong in both directions. Whether a given security operations platform falls inside the EU AI Act’s high-risk category is unsettled and turns on deployment context. Read the logging obligations anyway. They describe what reviewers in every regime have started asking for, whatever the classification turns out to be.

Auditable and admissible are different bars

Most vendor material stops at auditable, meaning a reviewer can follow the record. Admissible is a higher bar, and it has specific tests attached to it.

Under Federal Rule of Evidence 902(13), a record produced by an electronic process can authenticate itself, without live testimony, if a qualified person certifies that the process produces an accurate result. Read that carefully. The certification attaches to the process rather than to the record. Somebody has to describe how the system generates its records, state their qualifications for saying so, and stand behind it. When the only people who can do that work for the vendor, the customer’s evidence depends on the vendor’s cooperation.

Rule 902(14) covers copies, and the Advisory Committee notes point at hash values as the way to prove a copy is identical to the original. Hashing a decision record therefore serves an evidentiary purpose alongside a technical one.

A record generated in the ordinary course of monitoring also looks like a business record under Rule 803(6), which matters because business records are an exception to the hearsay rule. Records assembled later, for the purpose of a dispute, fit that exception far less comfortably. Generating the record at decision time has a legal payoff as well as an operational one.

A further rule is in motion. Proposed Federal Rule of Evidence 707 would apply the reliability standards of Rule 702 to machine-generated evidence offered without a human expert behind it. It was published for comment in 2025, the comment period closed in February 2026, and in June 2026 the Advisory Committee declined to recommend it, revised the text, and sent it back for further study. Treat the rule as unsettled. The record is what survives either outcome, because every version of the argument turns on whether the output can be examined.

What immutable has to mean

Immutable is the most repeated word in this category and the least specified. Vendor pages assert it and almost none say what implements it.

Two different properties hide behind the word. Tamper resistance means the record is hard to alter. Tamper evidence means alteration can be detected by someone other than the party holding the record. The second property is the one a dispute needs, and it is the harder one to build.

The mechanisms are well established and worth naming, because a vendor who cannot name any of them is describing an intention:

Append-only storage, so records are written once and never updated in place.
Hash chaining, where each record carries the digest of the one before it, so removing or editing an entry breaks the chain.
Signed log segments, which bind a segment to a key rather than to a claim.
Trusted timestamping under RFC 3161, which takes the time from a third party instead of from the machine under review.
External append-only or WORM storage, which moves the integrity guarantee outside the system being audited.

The test is short. Ask who can prove the record was not edited. If the answer is only the vendor, the record is an assertion by the vendor. That may carry an internal review. It is thin for arbitration, and thinner for an insurance claim.

The record outlives the evidence it cites

This failure surfaces in year two rather than during a proof of concept. A decision record that points at evidence is only as durable as the systems holding that evidence.

Retention windows do not line up. Under Article 19 of the EU AI Act, deployers of high-risk systems keep the logs generated under Article 12 for at least six months. Six months is a floor attached to one obligation, and it is short next to the windows that decide disputes. SIEM hot tiers commonly expire in thirty to ninety days. Litigation, insurance claims, and regulatory lookbacks run for years.

So a record built from pointers decays. Its queries resolve to nothing, and what remains is a claim that evidence once existed. A record built to survive carries the retrieved evidence inside it: the query as issued, the response as returned, and the time of retrieval. That costs storage, and it is the difference between a record and a citation.

Ask a vendor whether the record still means anything after the systems it queried have rolled over. Retention length alone will not tell you.

What the record means after the model changes

Every model in production is a moving target. It gets retrained, retuned, upgraded, and eventually retired. A decision made in March by a version that no longer exists raises a question this category has mostly avoided. What is that record evidence of?

Two properties get confused here. Reproducibility means running the same input again and getting the same output. Traceability means establishing what actually happened on the day. Reproducibility is a pleasant property, and for any system with a stochastic component it is a promise that will not hold across versions. Traceability is the one that has to hold, and it holds only if the record is self-contained.

Self-contained means the record carries its own provenance: the component versions in force, the configuration and policy in effect, the rule set or prompt applied, and the evidence as retrieved at the time. With that, the record stands on its own after the model that produced it is gone. Without it, the record describes a system that no longer exists and cannot be examined.

Ask a vendor which version produced a given decision. The speed of the answer tells you whether provenance sits in the record or in a changelog.

Why a summary is not a record

Many systems can produce a narrative after the fact. Far fewer can produce the trail the narrative was built from. The difference shows up the moment somebody disputes a decision, because a narrative can be regenerated and a record cannot be quietly revised.

Sequence is what separates them. Reasoning captured before the system acts is a record of a decision. Text produced afterward, when a reviewer opens the case, is a description of an outcome. Both read the same on screen, and only one of them constrained what the system did. The FINOS AI governance framework reaches the same conclusion in its guidance on agent decision audit, recommending that explicit reasoning be generated and logged ahead of tool calls rather than reconstructed later.

This is also the test that separates investigation from summarization. A summarizer produces better prose about the alert it was handed. An investigation produces the queries it ran, the evidence it retrieved, and a record connecting evidence to conclusion to action. If that record does not exist, the autonomy is a claim, not a capability.

Under whose authority, when nobody is awake

The seventh element gets treated most casually. Vendors answer it with access control, showing that an agent inherits the permissions of a user and cannot exceed them. That answers whether the action was permitted. It does not answer who authorized this one.

At three in the morning the authorizing party is a policy rather than a person. So the record has to capture the autonomy setting in force at that timestamp, which pulls configuration history into the chain of custody. Who set that level, when, with whose approval, and what it was the day before are all part of the answer to why the system was allowed to act alone.

A record stating that an action was automated has named a mechanism. A record stating which setting authorized it, and who put that setting in place, has named an authority.

What the record does for the analyst

Auditors are the reason the record gets built, and analysts are the reason it gets used. At handoff between shifts, the record is what a receiving analyst reads to understand a case without redoing it. When an escalation arrives, the evidence and the narrative arrive with it, so the analyst can challenge the reasoning without reconstructing it.

The same record answers a client question. When an MSSP customer asks why their host was isolated, the defensible answer is the trail, not a recollection.

Who owns the record

A decision record is a customer asset, and it usually lives in the vendor’s platform. Those two facts collide at the end of a contract.

For an MSSP the collision is doubled. The MSSP holds records of decisions made in client environments, the client may carry regulatory obligations attached to those records, and the platform holding them belongs to neither party. When any of the three relationships ends, somebody still has to answer for a decision made two years earlier.

Three questions settle it before signing. Can the records be exported in a form that is readable without the vendor’s interface? Does the export preserve whatever integrity mechanism made them verifiable? And do the records survive termination, or does access end with the subscription? A record you cannot take with you is a record you have borrowed.

Records are not free

Full reasoning capture costs money, and the vendors promising complete audit trails rarely mention it. Recording explicit reasoning ahead of every action adds inference cost. Keeping evidence inline rather than by reference adds storage. The FINOS guidance is unusually direct about this, noting that deeper reasoning capture significantly increases token costs and produces large volumes of data to store.

This is worth knowing because it predicts where corners get cut. A platform billed per alert or per token has a structural reason to record less. Ask how the record is priced, and whether the depth of the record changes the bill.

How Morpheus AI keeps the chain of custody

In Morpheus AI, a traceable record of every step runs from alert intake to final action. Read-only investigation through Attack Path Discovery records what it queried and what returned. Scoring opens to its factors, its weights, and the evidence behind each one, including the evidence that cut against the verdict. Actions carry command-risk tagging, so the approval gate is set by the risk of the command itself, and the record captures who or what authorized each one.

Weak evidence never closes an alert, and an investigation that cannot get what it needs fails toward a human. When Morpheus is uncertain, it defers to a human. When the questionnaire arrives, the answer is the record.

Also see:Governed Agentic SOC Effective Alert Risk Command-Risk Tagging

Frequently asked questions

What is a chain of custody in security operations?
The traceable record of a triage decision, running from alert intake to final action: what was read, what was queried, what came back, what was concluded, what was recommended, what was executed, and under whose authority.

How is a decision record different from an audit log?
An audit log usually captures that an action occurred. NIST SP 800-53 control AU-3 asks for the type of event, when and where it happened, its source, its outcome, and the identity of the parties involved. None of that requires a reason. A decision record captures why, connecting the evidence retrieved to the conclusion reached to the action taken, with the authorizing party attached.

Is an auditable record the same as an admissible one?
No. Auditable means a reviewer can follow it. Admissible has tests attached. Federal Rule of Evidence 902(13) lets a record produced by an electronic process authenticate itself if a qualified person certifies that the process produces an accurate result, so somebody must be able to describe how records are generated and stand behind it. A record generated in the ordinary course of monitoring also fits the business-records exception under Rule 803(6) far better than one assembled after a dispute begins.

What does it take for a record to count as immutable?
Something more than the word. Tamper resistance means the record is hard to alter. Tamper evidence means alteration can be detected by someone other than the party holding the record, which is the property a dispute needs. The mechanisms that deliver it include append-only storage, hash chaining, signed log segments, trusted timestamping under RFC 3161, and storage outside the system being audited. If only the vendor can prove the record was not edited, the record is the vendor’s assertion.

How long does a decision record need to be kept?
Longer than the obligations suggest. Article 19 of the EU AI Act has deployers of high-risk systems keep the logs generated under Article 12 for at least six months. Disputes, insurance claims, and regulatory lookbacks run for years, and SIEM hot tiers commonly expire in thirty to ninety days. A record that only points at evidence decays as the underlying systems roll over, so the record has to carry the retrieved evidence inside it.

What happens to a record when the model that produced it changes?
Nothing, if the record is self-contained. Reproducibility, meaning the same input returns the same output, will not hold across retraining and version changes. Traceability will, provided the record carries its own provenance: the component versions in force, the configuration and policy in effect, the rule set applied, and the evidence as retrieved. A record that depends on the producing system still existing stops being evidence when that version is retired.

Is a generated narrative enough?
No. A narrative can be regenerated after the fact, which is exactly why it settles nothing in a dispute. Sequence is the test. Reasoning logged before the system acts constrained what it did. Text produced when a reviewer opens the case describes an outcome. Both look the same on screen.

Does the chain of custody cover automated actions?
Yes. Every executed action is recorded with its timestamp and its authority, whether that authority was a named human approval or the autonomy setting in force at the time. Access control answers whether an action was permitted, which is a different question from who authorized this one, so configuration history belongs in the record too.

What does the record show when evidence was missing?
It shows which queries failed or returned nothing, which is the point. Missing evidence raises uncertainty, weak evidence never closes an alert, and the investigation fails toward a human.

Who owns the decision record?
The customer, in principle, while the vendor usually stores it. Settle three things before signing: whether records export in a form readable without the vendor’s interface, whether the export preserves the integrity mechanism that made them verifiable, and whether the records survive termination of the contract.

Why do regulators ask for a decision record?
Because a per-decision record is the only way to answer what happened at a given timestamp and why. Article 12 of the EU AI Act asks high-risk systems to log events across their lifetime at a level of traceability that allows decisions to be reconstructed. A reasoning process locked inside a model cannot be reproduced on request.

What should I ask a vendor about this?
Show me the complete record of one real triage decision on my data. Then ask who can prove it was not edited, which version produced it, whether the evidence it cites still exists, and whether I can take it with me. Treat the absence of any of those answers as a finding.

Related terms

Governed Agentic SOC — The operating model that keeps autonomous triage inside explicit governance.

Effective Alert Risk — The environment-specific risk score that opens to its factors, weights, and evidence.

Command-Risk Tagging — Setting the approval gate by the risk of the command itself.

Agentic SOC — A security operations model in which AI agents autonomously triage, investigate, and respond to alerts while human analysts supervise.

MSSP AI Governance — Governing autonomous security operations across multiple client environments.

Standards and rules referenced

NIST SP 800-53 AU-3
RFC 3227
RFC 3161
EU AI Act Art. 12
EU AI Act Art. 19
FRE 902
FRE 803(6)
FINOS AIR MI-21