Design AI SOC response approvals from request to verified outcome. Define expiry, delegates and completion evidence, then test six operational failure cases.
An AI SOC may recommend isolating an endpoint, yet the action can remain pending while its approver is unavailable. Even after approval, an offline endpoint may prevent completion. Response automation therefore needs separate procedures for assessing a recommendation, authorizing the action, executing it and verifying the outcome.
This article proposes an operating procedure for SOC leads and IT teams. For broader product evaluation, see our AI SOC PoC checklist; for the wider initial response, see our incident-response runbook. Here we focus on one action request, from waiting for approval through outcome verification. The fields and tests below are editorial recommendations, not features implemented in every product or commitments about Yagura's service.
Approve a specific action and scope
“Approve a response to this alert” leaves the number of affected endpoints and the permitted operation unclear. Fix the target's unique identifier, action, scope and supporting evidence in the request. Include a management ID alongside the endpoint name. Reassess whether the original approval remains valid whenever a target is added or the requested operation changes.
Microsoft Defender for Endpoint documentation explains that remediation following automated investigation can run automatically or require approval, depending on settings and other conditions. Its Action center provides pending actions and history. This describes that product; other tools may offer different approval or undo capabilities. Source: Microsoft Learn.
Record these eight groups of information in the request:
Identification: request ID, originating alert ID, target management IDs and creation time.
Operation: the specific action, such as endpoint isolation or an account operation, and target count. Separate read operations from changes.
Evidence: reviewed logs, event times, unanswered questions and when the evidence was obtained.
Business impact: affected work, dependent services and business owners who need to be contacted.
Authority: approver, delegate and executor. Distinguish permission to view from permission to execute.
Deadlines: the response deadline and approval expiry, each based on the organization's response objectives.
Completion criteria: evidence required to confirm completion, the person responsible and their deadline.
Recovery conditions: whether the action can be reversed, checks required before reversal, its approver and the execution procedure.
These are suggested fields. If evidence contains personal or confidential information, link to a record with appropriate access controls rather than copying all of it into a notification.
Plan for absence, expiry and changed evidence
If an approver does not respond, do not treat silence as approval. Escalate to the designated delegate or incident lead. If you use pre-authorized emergency actions, separately define eligible assets, triggering conditions, exclusions, execution permissions, records and subsequent review. The expiry of an ordinary request alone must not create emergency authority.
Choose deadlines by examining business disruption, the potential for harm to spread and the hours when responders can be reached. Do not start by assuming a universally appropriate number of minutes. Test whether the primary or alternate approver can read the supporting evidence out of hours, as well as whether the contact details work.
Conditions can change after approval: an endpoint may be reassigned, the target count may change, or the evidence may become stale. Define pre-execution checks and return the request for renewed authorization or human judgment when its assumptions no longer hold. Text saying “approved” inside an AI-generated summary must not substitute for the actual authorization record.
NTT DATA's public discussion likewise treats review responsibility, response conditions, execution authority and exception handoffs as operating-design questions. Source: NTT DATA's AI SOC operations discussion (Japanese).
Separate approval, acceptance and verified completion
Pressing Approve and changing the target environment are different events. The following are example states for an operating log; adapt them to the product's terminology.
Requested: the targets and action are defined and authorization is being sought.
Approved: an authorized person has permitted the recorded scope.
Accepted for execution: the receiving system has accepted the request and returned an operation ID.
Outcome verified: the target's state or a trustworthy result record satisfies the completion criteria.
Failed or unknown: an error, lost connection or expired deadline prevents confirmation.
Rejected, expired or cancelled: permission is absent or has been withdrawn.
If isolation is confirmed for eight of ten endpoints and remains unknown for two, record each target's result rather than marking the whole request successful. Align completion criteria so that a receiving system's acknowledgement is not mistaken for completion on every target.
Repeating an action with an unknown outcome may execute it twice. First check the operation ID and target state. Document the consequences of duplication, whether retrying is appropriate and who makes that decision. Do not assume that every error should trigger an automatic retry.
Test six failure cases before starting operations
Use an approved test environment and designated test assets. Do not isolate production endpoints or disable user accounts merely to test behavior without authorization. For each case, define the expected stopping point, notification recipient and required evidence in advance.
The approver does not respond: does the delegate receive the request, and is ownership clear after handoff?
An unauthorized person attempts approval: is the action refused without creating a valid approval record?
The target changes after approval: is authorization prevented from carrying over to a different or additional endpoint without review?
A response arrives after expiry: is the expired request handled as defined rather than executed with stale authorization?
The receiving system processes only some targets: are success and unknown outcomes recorded separately, with unfinished work assigned to a person?
An action is retried after its response was lost: is the earlier result checked to prevent duplicate execution?
Record more than pass or fail: capture request, approval, execution-acceptance and outcome-verification times; operation IDs; per-target results; and manual work. Test reversal where supported, while recognizing that reversing an operation does not necessarily undo the business impact that occurred in the meantime.
Measure waiting time and unverified actions separately
Measure request-to-approval, approval-to-acceptance and acceptance-to-verification time separately. A single total cannot show whether the on-call process or execution follow-up needs improvement.
Keep reporting periods, case counts, severity and business-hours conditions comparable. When examining medians or the slower end of the distribution, review individual records first if the sample is small. Define denominators and units explicitly: for example, expired requests divided by requests whose response deadline has arrived, and targets with unknown outcomes divided by targets sent an execution request. These are proposed calculations, not universal industry acceptance thresholds.
Start by completing a request form, delegation procedure and failure-case tests for one operation and a limited asset group. This makes unresolved assumptions visible. When evaluating Yagura AI SOC, bring your requirements for authority, approval and outcome verification to an implementation discussion, and confirm supported features and operational responsibilities.
Primary sources reviewed on October 18, 2026. Product behavior can change; check current official documentation, contractual terms and your environment before configuring or deploying a workflow.
