An AI agent that can read contracts, search Microsoft 365, and send messages has more exposure than a chat window. A poor permission or unreviewed response can leak customer data, interrupt operations, or create an audit finding.
A SOC 2 AI governance assessment puts defensible controls around that exposure before a customer review, insurance renewal, or enterprise procurement process exposes the gap. I advise security leaders to assess the full agent workflow, not only the model provider or a prompt library.
That workflow includes identity, permissions, retrieved data, decisions, tool calls, outputs, and supporting evidence. The work begins by documenting what every agent can access, decide, and change.
Key Takeaways
- Map each agent’s identity, permissions, data access, decisions, tool calls, and outputs.
- Test whether controls and evidence can support customer reviews and audits.
- Assess the full workflow, not only the model provider or prompt library.
Key Takeaways
- Assess each AI agent as a privileged application identity, including its permissions, data access, decisions, tool calls, and outputs.
- Define the SOC 2 scope around the full workflow, including model providers, retrieval sources, connectors, logs, vendors, and agents using live data.
- Write controls with clear owners, boundaries, review frequencies, approval requirements, and evidence sources that can support Type 2 testing.
- Use SOC 2 alongside NIST AI 600-1 and ISO 42001 to address operational controls, AI-specific risks, and formal governance practices.
- Maintain continuous evidence through access reviews, change management, monitoring, incident response, vendor reassessments, and audit-window log retention.
Where SOC 2 Covers AI, and Where It Stops
SOC 2 evaluates the security controls surrounding a service under the Trust Services Criteria. It does not declare that an artificial intelligence model is accurate, fair, or safe. Security is required; availability, processing integrity, confidentiality, and data privacy enter the report only when scope includes them.
For Generative AI systems, that distinction matters. A scoped SOC 2 Type 2 report can provide evidence of operating controls, while a SOC 2+ report may address additional customer assurance needs. A security-only report may leave data privacy commitments outside the auditor’s opinion, so security leaders should select criteria reflecting contractual promises and real data exposure.
The Common Criteria translate well to the operating environment: CC6 supports workforce and workload identity, including access controls. CC7 supports continuous monitoring and incident response. CC8 applies change management to model, prompt, connector, and retrieval changes. CC9 covers third-party risk across model providers, data stores, and other vendors.
However, auditors cannot attest that large language models will eliminate AI hallucinations. The examination can test whether the company constrains high-risk uses, detects unreliable outputs, documents human review, and blocks unsafe automated actions.
I treat an AI agent as a privileged application identity with an unpredictable language interface. In Microsoft 365 environments, its scope can span SharePoint retrieval, Teams messages, Exchange mailboxes, and workflow actions. Therefore, place every production agent, pilot using live data, and vendor-hosted connector inside the assessment boundary.
SOC 2 AI Governance Assessment: Scope and Client Deliverables
A thorough assessment starts with a workshop for security, legal, platform owners, and the business unit that owns the workflow. The workshop supports SOC 2 Type 2 preparation by tracing each data path, including user input, retrieval sources, model endpoint, tool calls, output channel, logs, and deletion path.
The review also records regions, subcontractors, and whether prompts, outputs, embeddings, or training data can contain restricted information, including data privacy considerations.
At completion, clients receive an evidence package mapped to their audit scope and operating reality.
| Area assessed | Evidence the client receives |
|---|---|
| Agent inventory and data flows | An audit-ready inventory with a named owner, purpose, system diagram, data classification, and connected applications for each agent |
| Access and tool permissions | A least-privilege matrix for human accounts, service identities, APIs, and delegated actions, with approval evidence |
| Retrieval sources and data handling | Approved data sources, retention rules, data steward approvals, and restrictions on sensitive content |
| High-impact agent actions | Documented human approval rules for external messages, record changes, financial actions, and permission changes, with test evidence |
| Change management and vendors | A control matrix and contract review evidence covering model updates, prompt changes, new connectors, provider terms, third-party risk, and incident response obligations |
These are working audit artifacts, not a slide deck. My completion package supports audit readiness with a prioritized risk register, a SOC 2 control crosswalk, an annual examination evidence request list, and an executive readout. Together, they map the examination scope to remediation owners and due dates.
The same package can support compliance automation and a customer security questionnaire, but it doesn’t replace accountable review.
Each gap should link to a commercial outcome. Excessive SharePoint retrieval can cause data leakage and erode customer trust. Weak vendor review can delay enterprise sales. Missing logs can produce audit findings. Uncontrolled agent actions can create downtime and productivity loss.
Write Controls That Can Survive Audit Testing
Vague statements such as “we use AI responsibly” do not give an auditor much to test. Good security controls name the owner, action, boundary, frequency, and evidence source.
For Generative AI workflows, I recommend control language that reflects how agents and content-generation systems operate:
- “The company maintains an inventory of production AI agents, their business owners, connected systems, approved data classifications, and permitted actions. The security team reviews the inventory quarterly.”
- “Each AI agent uses a unique workload identity. Administrators grant only the API permissions required for the approved workflow, and the security team reviews those access controls at least quarterly.”
- “Data owners approve retrieval sources before an agent accesses them. The company blocks restricted repositories unless the documented use case and access policy permit retrieval.”
- “A designated employee approves external communications, financial actions, identity changes, and irreversible record updates initiated by an AI agent before execution.”
- “Engineering records and approves changes to models, prompts, retrieval, connectors, and tool permissions through change management before production deployment.”
Testing these security controls should sample evidence and demonstrate operational effectiveness for a SOC 2 Type 2 examination. Compliance automation can gather logs and approvals, but reviewers must validate their completeness and relevance. The review should include incident response records and proof that a failed guardrail triggered escalation.
A policy may describe responsible AI use, but an execution log proves whether a privileged agent acted within its approved boundary.
Add NIST AI 600-1 and ISO 42001 to the Control Map
SOC 2 provides the audit structure, but it does not prescribe a complete AI risk management program. The NIST AI framework, formally the NIST AI Risk Management Framework, gives security leaders a practical companion for identifying AI-specific risks. These include confabulation, harmful content, intellectual property exposure, and weak human oversight.
NIST AI 600-1 helps teams translate those risks into controls for design, deployment, and monitoring. It also addresses training data provenance and the behavior of machine learning models. Its Generative AI Profile is useful when an agent generates content or takes actions based on generated content.
| Framework | What it demonstrates | Best fit |
|---|---|---|
| SOC 2 | An auditor’s opinion on selected controls and evidence over a defined scope | Enterprise security reviews and customer trust requirements |
| ISO 42001 | A certifiable AI management system with policies, risk treatment, objectives, and internal review | Organizations building a formal responsible AI program |
| NIST AI 600-1 | Practical guidance for identifying and managing Generative AI risks | Control design, risk assessments, and AI governance workshops |
ISO 42001 does not replace a SOC 2 report when a buyer wants independent assurance over security controls. Conversely, SOC 2 alone may not demonstrate mature governance for model risk, fairness, and accountable AI decision-making. Formal governance may also be needed for regulatory compliance.
If a buyer requests a SOC 2+ report, map the requested assurance to the relevant control set. Do not treat the report as a universal AI certification.
A strong program uses the NIST AI framework to identify and treat AI-specific risks. It uses ISO 42001 to structure management practices and SOC 2 to validate operational evidence. Together, they form an AI governance framework for AI risk management. This includes third-party risk across providers, data stores, and external model services.
Prepare for SOC 2 Type 2 With Continuous Evidence
A SOC 2 Type I report evaluates whether controls are suitably designed at a point in time. A SOC 2 Type 2 report tests operational effectiveness over an examination period, often six to 12 months.
That difference changes how security leaders should prepare for SOC 2 Type 2 examinations and maintain audit readiness. Annual policy reviews aren’t enough when the environment changes weekly, so AI agents need recurring access reviews, continuous monitoring, and audit-window log retention. Change management should record model, prompt, connector, and permission updates, alongside incident response exercises and vendor reassessments.
Compliance automation platforms such as Vanta and Secureframe can reduce manual evidence collection by connecting identity, ticketing, endpoint, and cloud systems. They do not replace control design or human review. Compliance automation can collect evidence, but it can’t determine whether an agent’s permissions match its business purpose or whether the security controls are appropriate.
Keep AI Controls Attached to Operating IT
AI governance cannot sit apart from operational IT. In my technology consulting work, I include cloud infrastructure, cloud management, endpoint security, device hardening, and secure cloud architecture in the review. That approach catches old entitlements from a Microsoft 365 migration, administrator endpoints, and data center technology that feeds a retrieval pipeline.
Restaurant groups need the same discipline. An agent connected to restaurant POS support or kitchen technology solutions can affect orders and employee access. Its action permissions, outage procedures, and logs belong in business continuity and security testing.
For small business IT and managed IT for small business, the scope should follow IT strategy for SMBs, infrastructure optimization, and digital transformation priorities. A business technology partner can provide cybersecurity services and tailored technology services, with compliance automation supporting evidence collection around the agent. Even innovative IT solutions still require approved changes, accountable owners, recurring reviews, and evidence that controls operated as written.
Frequently Asked Questions
What is the difference between SOC 2 Type 1 and the Type 2 report?
Type 1 assesses whether controls are suitably designed at a specific point in time. The Type 2 report examines whether those controls operated consistently across the examination period.
What does an AI governance assessment evaluate?
It evaluates an agent’s purpose, permissions, model and prompt changes, connected vendors, incidents, logs, and ownership. It also checks whether evidence shows controls operated as written.
How does evidence support an audit?
Evidence shows when a control ran, who owned it, what changed, and whether exceptions were resolved. That record helps leaders demonstrate consistent operation during an audit.
How does SOC 2 relate to ISO 42001 and the NIST AI framework?
SOC 2 focuses on controls relevant to security and related trust commitments. ISO 42001 provides a management-system standard for AI, while the NIST AI framework offers voluntary risk guidance. Organizations can use them together by mapping governance practices to operational controls and audit evidence.
Frequently Asked Questions
What does a SOC 2 AI governance assessment evaluate?
It evaluates an agent’s identity, permissions, data sources, model and prompt changes, connected vendors, tool calls, outputs, and ownership. The assessment also checks whether controls operated as written and whether the evidence supports customer reviews or an audit.
Does SOC 2 certify that an AI model is accurate or safe?
No. SOC 2 assesses selected controls around a service and does not attest that a model eliminates hallucinations, bias, or other AI risks. It can test whether the organization limits high-risk uses, requires human review, and blocks unsafe actions.
Why is SOC 2 Type 2 important for AI governance?
A Type 2 report evaluates whether controls operated consistently over an examination period rather than only whether they were designed at one point in time. AI environments therefore need recurring access reviews, change records, monitoring, incident response evidence, and vendor reassessments.
How do SOC 2, ISO 42001, and the NIST AI framework work together?
SOC 2 provides independent assurance over selected operational controls, ISO 42001 structures an AI management system, and the NIST AI framework provides practical risk guidance. Organizations can map AI governance practices across all three frameworks without treating any one of them as a universal AI certification.
A Defensible Path for AI Agents
An AI agent is a business system with a new interface and unusual failure modes. Customer trust depends less on a polished demo than on proof that identities, permissions, data boundaries, change records, and controlled actions are governed.
I recommend starting with production agents as part of a SOC 2 Type 2 assessment. Focus on agents that access restricted Microsoft 365 content or initiate external actions. This improves audit readiness by identifying data leakage and productivity-loss scenarios likely to delay a sale or cause an audit finding.
A well-built evidence trail makes the next SOC 2 Type 2 review a test of operating controls, not a scramble to explain how the agents work.
Discover more from Guide to Technology
Subscribe to get the latest posts sent to your email.