What a reviewer can read after an automated action

Someone will ask, weeks later, why an account was disabled at 03:00 on a Sunday. It may be internal audit. It may be the business owner of the account. It may be a customer, an insurer or a regulator. They were not there, they do not know your tooling, and they will read the record cold.

A record that only the SOC can interpret is not an audit trail. This guide sets out what the record should contain, so you can check what a vendor produces.

For every automated or approved containing action, the record should state:

1. What was done, against which object, in which product.
2. When it was requested, approved and confirmed effective.
3. What triggered it: the alert, the rule or the analyst.
4. What evidence the decision used, with links to the source records.
5. Who or what decided: a named person, a role or an automated policy, and which version of the policy.
6. Which approval mode applied, and the approver if there was one.
7. The result, including failures and partial success.
8. The undo, if one was run, with its own record.

Add a ninth for the field most tools skip: the reasoning, in plain language, written at decision time and not reconstructed later.

Two properties matter as much as the fields. The record must not be editable after the fact, and it must leave the platform in a form that a reviewer can open without a vendor login. Ask for a sample export in the first week of the evaluation. If the answer is "available in the UI", ask who can read the UI in three years.

Retention matters too. A record that expires after 90 days is useless for a review that starts in month five.

Documentation is uneven, and several vendors describe the audit trail in a single phrase.

• D3 Security's platform page describes an audit record that is immutable, timestamped and attributed at the command level, covering playbook steps, analyst approvals, integration calls and outcomes, with exports it calls regulator-ready (read 2026-11-03). These are vendor claims. The page does not show a sample.
• Torq's home page says every verdict, decision, exception and override is captured with the context of when and why (read 2026-11-03). The wording is about triage, so ask whether it covers containing actions.
• CrowdStrike says every agent action and workflow run is logged in Charlotte Agentic SOAR (page, read 2026-11-03), a vendor claim with no field list.
• Google's Response Agent documentation says executed actions show success or failure in the workflow, and read-only users can view execution history and output (read 2026-11-03). No export or retention is stated.
• Microsoft's automation docs let a rule condition on who last updated an incident, whether a user, a playbook or an automation rule. That gives change attribution (read 2026-11-03), and the page does not describe a per-action execution record.
• Cyware describes complete audit trails for playbook changes (Orchestrate page, read 2026-11-03). That covers who edited the playbook, not what each run did.
• Palo Alto's Cortex XSOAR page says auto-documentation supports audit reporting and describes a war room (product page, read 2026-11-03). No record fields or retention are given.
• Splunk's SOAR page names case management and describes no audit trail or per-action record (product page, read 2026-11-03).

D3 Security says Morpheus keeps an audit trail per incident (d3security.com, read 2026-11-03), a vendor claim. Log format, export and retention are not described on the pages read.

A testimonial that a vendor publishes from a customer's security leadership is a vendor claim. It usually concerns investigation work in the SOC and says nothing about containment, response time or an audit record format. Scope, dates and contract terms are unknown unless a case study or a statement from the customer exists, and a logo is not a reference.

So do not read a testimonial as evidence that a customer uses a product for containment, or that any regulator has accepted the vendor's records. Ask the vendor for a sample record and an export.

Pick one automated action in a pilot, such as a session revocation on a test account. Then ask a colleague outside the SOC to answer these questions using only the exported record:

• What was done, to whom, and when?
• Why did the platform do it?
• Who approved it, or was it automatic?
• Did it work?
• How would it be undone?

If they cannot answer all five without calling you, the record fails. Record the gaps, send them to the vendor and keep the answers.

Regulated teams should agree a retention period and a format with their own compliance function before the pilot, not after. The platform's default is rarely the requirement. Add the record's format to the contract schedule and ask for an export route that does not depend on the vendor staying in business.

• The vendor has supplied a sample record and a sample export for a containing action.
• The record carries all eight fields listed above.
• Records cannot be edited after the fact, and the vendor states how this is enforced.
• Retention is stated in months and matches your compliance requirement.
• A person outside the SOC has answered the five questions from the exported record alone.
• Approvals, including who approved and when, appear in the same record as the action.
• Undo actions generate their own records.
• The export format and retention are written into the contract.