System Operations
Automated or one-click mitigation features are restricted, logged, authorized, reversible where practical, and protected by safeguards that limit unauthorized or excessive customer impact.
Use this guide to put the control into operation, decide what records to retain, and check that an auditor can trace the evidence back to the work your team performed.
Maintained by GreenHat Security · Reviewed August 21, 2026
Automated containment or mitigation can act only within approved boundaries, leaves an attributable record, limits unintended impact, and can be stopped or reversed when behavior is unsafe.
First SOC 2 program
Inventory every automated action, use narrow service permissions and allowlists, require human approval for high-impact actions, log each decision, and test a kill switch that responders can reach quickly.
As the company scales
Apply risk-tiered approval, policy enforcement, rate and blast-radius limits, staged activation, dual control for sensitive actions, independent health checks, and regular rollback exercises.
List what each workflow can change, affected systems and customers, triggering signals, executing identity, owner, and maximum intended scope.
You should end up with: Automated-action register and risk tier
Define allowed targets, confidence thresholds, approval points, rate limits, excluded conditions, and escalation for uncertain or high-impact cases.
You should end up with: Enforceable action policy
Give automation a dedicated identity with only the permissions needed for its approved actions and separate authority for configuration changes.
You should end up with: Least-privilege automation role
Log the trigger, input evidence, rule or workflow version, decision, approver when applicable, target, result, and reversal status.
You should end up with: Attributable mitigation action log
Create a clearly owned way to disable actions and restore affected state, avoiding dependence on the same failed workflow where practical.
You should end up with: Kill-switch and rollback procedure
Test excessive volume, false positives, partial failure, permission error, unavailable dependencies, kill-switch activation, and recovery.
You should end up with: Guardrail exercise with corrective actions
Build the evidence set in three layers: what defines the control, who approved or reviewed it, and what proves it operated. Collect operating records when the work happens so they remain dated, attributable, correctly scoped, and traceable to the underlying activity.
Before sharing, remove unrelated personal or customer data, never expose passwords, tokens, or secret values, preserve enough source context to authenticate the record, and use the secure exchange approved for the engagement.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
Confirm what the record proves
Each automation identity has only the access needed for approved actions, with scope, owner, and review state visible.
Include this context
Automation identity
Include this context
Permitted actions and targets
Include this context
Environment
Include this context
Owner
Include this context
Effective access
Include this context
Last review
Weak evidence to avoid
A shared administrator role used by several workflows with no action boundaries, accountable owner, or current review.
Confirm what the record proves
Every covered automated mitigation can be traced from trigger and workflow version through decision, target, result, and reversal status.
Include this context
Action ID and time
Include this context
Trigger evidence
Include this context
Workflow version
Include this context
Target and scope
Include this context
Decision or approver
Include this context
Result and reversal
Weak evidence to avoid
A count of blocked actions without the trigger, target, workflow version, decision path, individual result, or rollback state.
Confirm what the record proves
High-impact or uncertain actions cannot proceed until the required named reviewer records a decision through an enforced workflow step.
Include this context
Covered action tier
Include this context
Approval condition
Include this context
Authorized approver role
Include this context
Enforcement configuration
Include this context
Decision log
Include this context
Bypass rule
Weak evidence to avoid
A procedure asks operators to seek approval, but the automation can execute without a recorded decision.
Confirm what the record proves
Authorized responders can stop covered actions through a known control path and have demonstrated that the stop works under realistic failure conditions.
Include this context
Covered workflows
Include this context
Activation authority
Include this context
Control path
Include this context
Test scenario and time
Include this context
Observed stop result
Include this context
Findings and owner
Weak evidence to avoid
A document says disable the automation but has no tested control path, authorized responder, test date, measured result, or corrective action.
Confirm what the record proves
Affected state can be restored or otherwise corrected after an unsafe action, with the reversal result and remaining impact recorded.
Include this context
Original action ID
Include this context
Affected target
Include this context
Rollback method
Include this context
Actor and time
Include this context
Validation result
Include this context
Residual impact
Weak evidence to avoid
A ticket says reverted with no original action, target, reversal steps, validation, timestamp, or remaining customer impact.
Type 1
The current automated-action inventory, execution permissions, guardrail and approval configuration, working kill-switch path, and a recent traceable action or safe test at the review date.
Type 2
Every execution of each covered automated mitigation during the review period, including blocked, approved, rejected, failed, partially completed, rolled-back, and manually overridden actions, plus every production workflow or permission change and every kill-switch or rollback exercise due during the period.
Reconcile immutable execution logs from every covered workflow to approval, incident, and reversal records; reconcile workflow and permission change history to change approvals, then compare the exercise schedule to kill-switch and rollback results, accounting for blocked, failed, overridden, and zero-action periods.
Use this checklist to prepare for procedures an auditor may perform. The exact steps and sample selection depend on your engagement scope and the service auditor's professional judgment.
Determine whether the control is designed to achieve this result: Automated containment or mitigation can act only within approved boundaries, leaves an attributable record, limits unintended impact, and can be stopped or reversed when behavior is unsafe.
Compare the documented owner with the intended role (Security Operations / Engineering / Infrastructure), then compare dated records with the stated cadence: Continuous/ongoing; periodic review by risk.
Reconcile immutable execution logs from every covered workflow to approval, incident, and reversal records; reconcile workflow and permission change history to change approvals, then compare the exercise schedule to kill-switch and rollback results, accounting for blocked, failed, overridden, and zero-action periods.
The current automated-action inventory, execution permissions, guardrail and approval configuration, working kill-switch path, and a recent traceable action or safe test at the review date.
Every execution of each covered automated mitigation during the review period, including blocked, approved, rejected, failed, partially completed, rolled-back, and manually overridden actions, plus every production workflow or permission change and every kill-switch or rollback exercise due during the period.
Dated proof that the control actually ran, such as tickets, logs, settings, exports, reports, and test results.
For each selected record, confirm it demonstrates Each automation identity has only the access needed for approved actions, with scope, owner, and review state visible.
For each selected record, confirm it demonstrates Every covered automated mitigation can be traced from trigger and workflow version through decision, target, result, and reversal status.
For each selected record, confirm it demonstrates High-impact or uncertain actions cannot proceed until the required named reviewer records a decision through an enforced workflow step.
For each selected record, confirm it demonstrates Authorized responders can stop covered actions through a known control path and have demonstrated that the stop works under realistic failure conditions.
For each selected record, confirm it demonstrates Affected state can be restored or otherwise corrected after an unsafe action, with the reversal result and remaining impact recorded.
Use the categories that apply to this control: connect any policy or design artifact to its approval or review record, then trace a selected operating record through execution, result, and any exception or remediation.
These identifiers help you navigate related Trust Services Criteria. They do not reproduce the criteria or prove that this control fully addresses them in your environment.
Confirm final scope, mappings, and testing expectations with your service auditor. SOC 2® is an AICPA trademark; GreenHat Security is not affiliated with or endorsed by AICPA.