MSP AI Resource Hub GOVERNANCE SERIES
OVERSIGHT STANDARD Vol. 6 · v1.0 · 2026
GOVERNANCE SERIES — VOL. 6

AI Automation Oversight Standard

Defines which AI-driven automation actions require human approval before execution, who holds approval authority, how exceptions are logged, and what constitutes a human-in-the-loop control for SOC 2 audit purposes.

SOC 2 CC7.2 SOC 2 CC7.4 SOC 2 CC8.1 OPERATIONS HARD GATE REQUIRED EXCEPTION LOG INCLUDED
DOCUMENT OWNER
Security Lead + Operations Owner
EFFECTIVE DATE
2026-01-01
REVIEW CYCLE
Quarterly
VERSION
1.0
APPLIES TO
All AI-driven automation · RMM · PSA · Security tooling
01 Purpose

AI-driven automation can execute actions faster than any human reviewer — including actions that affect client environments, billing, security posture, or data integrity. Speed is the value proposition. It is also the risk. This standard defines exactly where the human review gate sits so that automation speed is preserved for low-risk actions while high-impact decisions always have a named human accountable for them.

This document closes the SOC 2 CC7.2 and CC8.1 gap identified in the AI Controls Mapping: the requirement that AI automation acting on client environments have documented human-in-the-loop controls, exception logging, and a quarterly review cadence.

CORE RULE Any AI-driven action that modifies a client environment, changes a security policy, affects billing, or moves or deletes data requires explicit human approval before execution. This is a hard gate — not a guideline. Automation that bypasses this gate without a logged exception is a policy violation.
02 Action Tiers

Every AI-driven automation action falls into one of three tiers. Tier determines whether the action can execute automatically, requires human approval, or is blocked from AI automation entirely.

TIER 1 — HARD GATE
HUMAN APPROVAL REQUIRED
Isolating or quarantining a client endpoint
Executing IR runbooks on client environments
Disabling or locking user accounts
Modifying firewall rules or security policies
Deploying software to client endpoints
Deleting or moving client data
Changing backup schedules or retention
Modifying billing or contract records
Escalating a ticket to a client contact
Any action flagged Critical or High severity
TIER 2 — CONDITIONAL
AUTO WITH LOGGING
Rebooting endpoints during approved maintenance windows
Applying pre-approved patches in approved windows
Routing tickets between internal queues
Generating and saving ticket summaries
Sending pre-approved internal alerts
Updating ticket fields (status, priority, category)
Running read-only diagnostic scripts
Generating scheduled reports
TIER 3 — AUTO PERMITTED
NO GATE REQUIRED
Fetching read-only data from APIs
Drafting internal documentation (not sent)
Populating dashboards from existing data
Summarizing tickets for internal use
Generating cost or ROI estimates
Logging entries to internal registers
Sending automated read receipts or acknowledgements
PLATFORM / TOOLEXAMPLE AI AUTOMATIONTIERGATE
NinjaRMMEndpoint isolation on ransomware detectionTier 1HUMAN APPROVAL
NinjaRMMPatch deployment in approved maintenance windowTier 2AUTO + LOG
NinjaRMMPull device health data for dashboardTier 3AUTO
ConnectWise PSAClose ticket and send client summaryTier 1HUMAN APPROVAL
ConnectWise PSARe-route ticket between internal queuesTier 2AUTO + LOG
ConnectWise PSAGenerate ticket summary for internal logTier 3AUTO
SentinelOneQuarantine endpoint on Tier 1 threatTier 1HUMAN APPROVAL
SentinelOneRun Deep Visibility query and log resultsTier 3AUTO
Microsoft CopilotDraft client-facing email or reportTier 1HUMAN REVIEW BEFORE SEND
Microsoft CopilotSummarize meeting notes internallyTier 3AUTO
Power AutomateTrigger IR runbook steps on client environmentTier 1HUMAN APPROVAL
Power AutomateRoute approval request to named approverTier 2AUTO + LOG
03 Human Gate Definition

A human gate is not a notification. It is not a summary sent after the action completes. It is a named human reviewing the proposed action and explicitly approving it before the automation executes. The following criteria define what counts as a valid human gate for SOC 2 purposes.

CRITERIONREQUIREDNOTES
Named approver identifiedREQUIREDA specific person — not a group or role — is identified as the approver before the action is queued
Approver sees the proposed action in fullREQUIREDThe approver must see exactly what will execute — not a summary. Scope, target, and expected outcome must be visible.
Explicit approve or deny action takenREQUIREDA button click, form submission, or logged response. Silence or inaction does not count as approval.
Timestamp of approval loggedREQUIREDThe timestamp of when the approver acted must be captured and retained. This is the audit trail.
Action does not execute until approval is loggedREQUIREDThe automation must be blocked pending approval — not post-hoc reviewable. Execution before approval is a gate failure.
Denial results in no actionREQUIREDIf the approver denies, the automation stops entirely. The denial must also be logged.
Timeout handling documentedRECOMMENDEDDefine what happens if the approver does not respond. Default must be no action — not auto-approve on timeout.
WHAT DOES NOT COUNT AS A HUMAN GATE An alert sent after execution. A notification that an action was taken. A weekly review of automation logs. A summary email to a manager. None of these satisfy the gate requirement. The gate must occur before the action executes — not after.
04 Approval Authority

Approval authority is determined by action tier and impact scope. Actions affecting multiple clients or with irreversible consequences require a higher level of approval.

ACTION SCOPEMINIMUM APPROVERESCALATION IF UNAVAILABLE
Tier 1 — single client, reversibleAssigning technician's team leadOn-call senior tech
Tier 1 — single client, irreversible (data deletion, account disable)Security Lead or Operations OwnerOn-call Security Lead
Tier 1 — multiple clients or portfolio-wideSecurity Lead + Operations Owner (both)Escalate to executive on-call
Tier 1 — IR runbook on client environmentSecurity LeadOn-call Security Lead
Tier 2 — conditional auto actionPre-approval via maintenance window approval or change requestRevert to Tier 1 gate if window not approved
Exception to this standardSecurity Lead + Risk OwnerNo exception without both approvers
AFTER-HOURS COVERAGE Tier 1 actions do not pause because it is after hours. An on-call rotation must be maintained for Security Lead and Operations Owner roles. Any Tier 1 action that cannot reach an approver must default to no action — not auto-approve. Document the failed approval attempt in the exception log.
05 Exception Logging Requirements

Every gate failure, gate bypass, and approved exception must be logged. Logging is not optional. An unlogged exception is indistinguishable from a deliberate policy violation for SOC 2 purposes. The exception log is reviewed quarterly as part of this standard's operating cadence.

EVENT TYPELOG REQUIREDFIELDS REQUIREDRETENTION
Tier 1 action approved and executedYESDate, action, target, approver, timestamp, outcome12 months
Tier 1 action deniedYESDate, action, target, approver, denial reason, outcome12 months
Gate failure — action executed without approvalYES — IMMEDIATEDate, action, target, how bypass occurred, who detected it24 months
Approved exception to this standardYESDate, requestor, justification, approvers, expiry dateDuration + 12 months
Tier 2 conditional auto actionYES — AUTOMATEDDate, action, target, triggering condition, outcome6 months
Approver unavailable — action deferredYESDate, action, target, contact attempts, resolution12 months
06 Submit an Exception or Gate Event

Use this form to log a gate event, a gate failure, or a request for an approved exception to this standard. All submissions are routed to the Security Lead and Risk Owner. Exceptions require dual approval and an expiry date — permanent exceptions are not permitted.

EXCEPTION / GATE EVENT LOG
Gate Event Submission
✓ LOG ENTRY SUBMITTED — Routed to Security Lead and Risk Owner. Wire to SharePoint AI Automation Exception Log list in Phase 1.
07 Quarterly Review

This standard and its exception log are reviewed quarterly. The review meeting must be attended by the Security Lead, Operations Owner, and Risk Owner. The output of each review is a dated record confirming the standard remains current and all open exceptions have been evaluated.

REVIEW ITEMACTION
Exception log — all entries since last reviewReview all entries. Confirm gate failures have been remediated. Confirm approved exceptions have not expired.
Gate failure count and trendIf more than two gate failures in a quarter, trigger a root cause review and update automation configuration.
Tier assignments — new automations added since last reviewClassify any new AI automation actions into Tier 1, 2, or 3. Update the action table in Section 02.
Approver availability — on-call coverage confirmedConfirm on-call rotation is current and all approvers know their responsibilities.
Standard version — material changes since last reviewIf scope has changed significantly, increment version number and redistribute.
DATE
REVIEW NOTES
OWNER
STATUS
Q1 2026 — Initial standard published. Baseline exception log opened.
Risk Owner
PENDING