SOC 2, ISO 27001 and ISO 42001 for AI | AI-Specific Audit Points and Control Design [2026 Edition]

import ColumnDownloadCTA from '@/components/columns/ColumnDownloadCTA' import ColumnContactCTA from '@/components/columns/ColumnContactCTA'

Hello, this is Hamamoto from TIMEWELL.

This is the second installment of our enterprise AI governance series. The first installment focused on Japan's METI AI Business Operator Guideline and how to design domestic internal rules. This time, as a sequel, we cover three standards that are actually being audited globally and that increasingly appear as contractual checklist items — SOC 2 Type II, ISO/IEC 27001:2022, ISO/IEC 42001:2023 — and the US-originated NIST AI Risk Management Framework 1.0.

Frankly, as AI usage grows, internal legal and security teams are increasingly pressing the question: "Will our AI pass SOC 2?" Each time, my reaction is the same — applying AI directly to existing audit standards always distorts something. AI behaves probabilistically, outputs vary, and training data is hard to inspect. Standards designed around deterministic systems struggle to capture these issues.

This article re-reads the four standards through an AI lens and lays out, from a practitioner's viewpoint, what should be controlled and how. By the end, the goal is for you to discuss your company's AI audit requirements at a resolution your executives can engage with.

Why ISO/IEC 42001:2023 matters

In December 2023, ISO and IEC jointly published ISO/IEC 42001:2023 — the world's first certification standard for an AI Management System (AIMS). Until then, AI governance had relied on company-specific in-house criteria or voluntary guidance such as NIST AI RMF. The single greatest meaning of this standard is that it adds a yardstick that can be demonstrated externally through third-party certification.

Structurally, it follows the format of other ISO management-system standards. In addition to the main requirements, Annex A lists 38 controls across 9 categories, with Annex B providing implementation guidance for each. The 9 categories cover A.2 AI Policy, A.3 Internal Organization, A.4 Resources, A.5 Impact Assessment, A.6 AI System Lifecycle, A.7 Data, A.8 System Information, A.9 Use, and A.10 Third-Party Relationships. As with ISO 27001's Annex A, Annex A here is not a mandatory implementation list but a reference set selected by risk through the Statement of Applicability (SoA).

The certification process follows ISO 17021, with a two-stage audit: Stage 1 (document and design review, 1 to 2 days) and Stage 2 (on-site and operational evaluation, 1 to 3 weeks). The certificate is valid for three years and is renewed via annual surveillance audits. Public information from major certifying bodies such as Schellman suggests roughly 4 to 6 months for organizations that already hold ISO 27001, and 6 to 12 months when starting from scratch.

What struck me in reading this standard is how it refuses to leave "AI fairness" and "accountability" as abstract ideals. It decomposes them into auditable units — impact assessment, data provenance, lifecycle management, third-party relationships. The reason AWS and Microsoft moved early to obtain certification, and why it is being embedded into enterprise procurement requirements, is precisely this auditability. In Japan, since early 2026, I have begun seeing RFPs for AI development outsourcing and SaaS that demand "submit your ISO 42001 acquisition plan."

It is also worth noting how ISO 42001 frames the relationship between policy and accountability. The standard insists that an AI policy is not a separate artifact owned by a single team, but a top-management commitment that flows into objectives, roles, communication, and review. In organizations that already operate ISO 9001 or ISO 27001, this rhythm is familiar. In organizations that do not, the most common stumbling block at Stage 1 is precisely this: the AI policy exists, but it is not connected to objectives, KPIs, and management review at the executive level. Build that scaffold first, even before you tackle Annex A.

AI evaluation points within SOC 2 Trust Services Criteria

SOC 2 is an audit report based on the Trust Services Criteria (TSC) administered by the AICPA, evaluated against five principles: Security, Availability, Processing Integrity, Confidentiality, and Privacy. Type I evaluates design at a point in time; Type II evaluates operating effectiveness, typically over 6 to 12 months. Enterprises effectively require Type II from their counterparties.

Bluntly, the current TSC has no AI-specific chapter. The AICPA Auditing Standards Board revised the SOC 1 guide in 2025 and incorporated emerging-technology and new-threat perspectives into the Points of Focus. The SOC 2 description criteria and Points of Focus are also being refreshed. Pulling together commentary from Baker Tilly, Forvis Mazars, and other Big-4-orbit firms, the trend in 2026 audit fieldwork is settling into "re-interpret AI governance within the existing five principles."

There is one big principle to internalize about how auditors give assurance over AI: "The auditor does not give assurance over AI outputs themselves; it gives assurance over the controls around AI." AI behaves probabilistically — same input, different output. Reproducible-test models built for deterministic software do not fit. Schellman and individual firms have consistently pointed out that new control primitives — hallucination-rate thresholds, confidence-calibration metrics, output verification architecture — must be defined.

In practice, you can re-read the five principles as follows to fit AI. Security extends to access control over training data and inference logs, and protection of API keys and model weights. Availability covers not only model-serving SLAs but also fallback design when inference fails. Processing Integrity introduces input validation, output validation, and human oversight points to prevent hallucinations from impacting business operations. Confidentiality verifies that internal data is not silently sent to vendors via prompts and that confidential information is not mixed into logs. Privacy covers consent, response to deletion requests, and the risk of personal data ending up in training. Linking these to existing TSC controls and adding them to Section 4 of the report has become increasingly common.

Two operational tips help the SOC 2 conversation go faster. First, decide in advance which AI systems are in scope. A fuzzy scope is the single biggest reason audit fees blow up — auditors will reasonably treat every AI-touched workflow as material unless you draw the line. Second, prepare evidence at the granularity of "control owner, evidence artifact, sample population, frequency." Auditors do not want narrative; they want sample-able records. Hallucination-rate dashboards are useful, but a screenshot is not evidence. The exported CSV with timestamps and approver IDs is.

Mapping ISO 27001 Annex A onto AI

ISO/IEC 27001:2022 remains the foundational ISMS standard for enterprises. The 2022 revision substantially restructured Annex A — from 114 controls across 14 domains to 93 controls across 4 themes. The themes are Organizational (37), People (8), Physical (14), and Technological (34). The 11 newly introduced controls include A.5.7 Threat Intelligence, A.5.23 Cloud Services, A.5.30 ICT Readiness, A.7.4 Physical Security Monitoring, A.8.9 Configuration Management, A.8.10 Information Deletion, A.8.11 Data Masking, A.8.12 Data Leakage Prevention, A.8.16 Monitoring, A.8.23 Web Filtering, and A.8.28 Secure Coding.

AI-specific controls are not yet codified in 27001:2022. Even so, when you read these 93 controls with an AI lens, they cover a great deal. For example, A.8.10 Information Deletion ties directly to the responsibility for deleting training data and responding to "forget" requests against the model. A.8.11 Data Masking helps with anonymizing personal information that ends up in prompts. A.8.16 Monitoring becomes the discipline behind collecting and analyzing inference and prompt logs. A.5.23 Cloud Services helps clarify the responsibility split when using SaaS LLMs or vector DBs. A.8.25 Secure Development extends naturally to incorporating adversarial-sample resilience tests and red-team exercises.

The early-2026 takes from major ISO commentary outlets — ISMS.online, Advisera, CSA — converge on this same direction. The shared view is: "By 2026, the standard will be ISO 27001 as the information-security foundation, with ISO 42001 layered on top as the AI governance layer." I agree, and at TIMEWELL we open with an ISO 27001 gap analysis for clients before drafting the SoA for ISO 42001.

Several specialists, including GRC Solutions, have observed that AI-specific controls may be added in the next ISO 27002 revision or via an Annex A addendum. That requires watching, but if you want to get ahead, re-read existing Annex A controls "with the AI eye" and add the corresponding clauses to your internal policies.

As I wrote in The Five Phases of Bringing AI Agents into an Organization, the ideal time to fix internal policies is during the early phases of AI adoption — phases 1 to 2. Patching them later means bolting audit requirements onto already running systems, which spikes costs.

A pattern I keep seeing: companies finish a successful proof of concept, hand the system to operations, and only then realize that no one defined retention periods for prompt logs, no one decided how to handle deletion requests against vector databases, and no one recorded who approved the model version that went live. ISO 27001's controls already cover most of these obligations in principle, but their AI translation is what teams skip. Spending a single afternoon walking the 93 controls down the page and asking "what does this mean if the system in scope is an LLM-backed assistant?" usually surfaces ten or more concrete to-dos.

ISO 42001 must-have controls: monitoring, data, incident response

From the 38 controls of Annex A, here are three areas where I find audits will reliably catch you if missing — monitoring, data management, and incident response, in that order.

Monitoring is concentrated in A.6 (AI System Lifecycle) and A.8 (AI System Information). What is required is a mechanism to continuously observe operational AI performance, bias, false-positive rate, and hallucination rate, and to trigger remediation when thresholds are exceeded. This can extend a familiar MLOps dashboard, but audits ask not just for the metrics: who approved which observation items and when, and is there a record of threshold changes? Practically speaking, change management and approval traceability draw more questions than the observed values themselves.

Data management lives in A.7 (Data). For AI, data is closer to code than to documents. Controls are needed at every stage: provenance, quality, labeling, consent, deletion, retraining. Generative AI has the additional risk of training data unintentionally leaking into output. The realistic answer is to bundle data classification, exclusion of sensitive information, substitution with synthetic data, and explicit retention periods into a single control set. NIST's Generative AI Profile (NIST AI 600-1, July 2024) covers confabulation (plausible-but-false output) and information integrity carefully, and is increasingly cited as supporting evidence for the ISO 42001 SoA.

Incident response is split across A.5 (Impact Assessment) and A.9 (Use). AI-specific incidents include erroneous business decisions due to misinformation, discriminatory output, leakage of sensitive data, and privilege escalation via prompt injection. Add "model-induced malfunction" and "data-induced output quality degradation" as classes inside an existing security incident-response process (such as one based on NIST SP 800-61). From experience, the unfinished incident-response process is the most common failing — and the area most often flagged in ISO 42001 Stage 2 audits.

We designed ZEROCK with auditability in mind from the start. Full logs of prompts and outputs, change history, approval workflows, fallback behavior, and traceability of data deletion are built into the platform — not "wired in later." Bolting these on after audit pressure arrives is genuinely painful.

Aligning with the NIST AI Risk Management Framework

The NIST AI Risk Management Framework 1.0, published by NIST on January 26, 2023, is voluntary guidance. The core consists of four functions — GOVERN, MAP, MEASURE, MANAGE — with GOVERN running across the others, and the remaining three covering risk identification, measurement, and response. NIST RMF is often confused with ISO 42001, but they differ in character: NIST is a flexible, non-mandatory framework; ISO 42001 is a certifiable management-system standard. NIST itself acknowledges this difference and publishes a crosswalk; the AIRC document "NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf" is the primary reference.

In practice, I always describe the split as "NIST is the What and Why; ISO 42001 is the How." For surfacing risks, NIST's GOVERN/MAP/MEASURE perspective is comprehensive. For driving operations and audits, mapping to Annex A of ISO 42001 produces the smoothest documentation. The Generative AI Profile added in July 2024 (NIST AI 600-1) covers GenAI-specific topics — CBRN (chemical, biological, radiological, nuclear) information, confabulation, dangerous recommendations, data privacy, information integrity, harmful bias — and works well as supporting documentation for the ISO 42001 SoA.

Other national frameworks — the EU AI Act, the UK AI Assurance Roadmap, Singapore's AI Verify — overlap conceptually with NIST AI RMF and ISO 42001. Rather than chasing them all, the most cost-effective sequence is: build the company's risk frame on NIST AI RMF, make it auditable through ISO 42001, then translate into reports for the EU AI Act or SOC 2 as needed.

A further development worth tracking in 2026: the question of who performs AI assurance. The November 2025 issue of the Journal of Accountancy ran a feature, "CPAs as AI System Evaluators," arguing that SOC 2 auditors are becoming the de-facto evaluators of AI. Accountants, security specialists, and data scientists now intersect on this work. The key to certification readiness is staffing the CISO, data lead, and legal counsel each with a defined role.

One nuance often missed by Japanese readers: the EU AI Act's high-risk system obligations and ISO 42001's Annex A overlap meaningfully but are not identical. The EU AI Act emphasizes ex-ante conformity assessment for specific high-risk categories (employment, credit, critical infrastructure, law enforcement), with documentation, post-market monitoring, and human oversight obligations specified by use case. ISO 42001 is generic and risk-driven — it does not pre-classify use cases. If your business serves the EU market, treat the AI Act's high-risk list as the trigger that tightens your SoA inside ISO 42001, not as a separate parallel project. That avoids duplicate documentation work that I have seen consume entire compliance teams.

Wrap-up: How to design AI that survives audits

A quick recap of the four standards.

• ISO/IEC 42001:2023 is the world's first AIMS certification standard. Its 38 Annex A controls across 9 categories decompose AI governance into auditable units.
• SOC 2 Type II has no AI-specific chapter yet, but in 2026 the mainstream practice re-reads the five principles for AI. AICPA already updated its Points of Focus in 2025.
• ISO/IEC 27001:2022 remains the information-security foundation with 93 controls across 4 themes. AI-specific controls are not yet codified, but the A.8 controls apply cleanly to AI operations.
• The NIST AI RMF 1.0 has four functions — GOVERN, MAP, MEASURE, MANAGE. The official crosswalk to ISO 42001 is published, and a two-stage operating model is the realistic answer.

If I had to compress the practical priority into one phrase: "Start from logging and change management." No one today can fully control AI output. What you can do today is keep input/output logs, training-data provenance, model change history, and human oversight points in audit-ready form from the start. With those in place, you are close to having explanations ready the moment SOC 2 or ISO 42001 asks.

In the third installment, we will get into how to translate these controls into implementation — concrete steps using ZEROCK's design and audit-log functions as the backdrop. If your internal discussion is stuck on "who owns AI governance," start by re-drawing the responsibilities of the CISO, data owner, legal counsel, and executive level. Without that clarity, the conversation about standards spins forever.

References

[^1]: ISO. "ISO/IEC 42001:2023 — AI management systems." https://www.iso.org/standard/42001 [^2]: NIST. "NIST AI RMF to ISO/IEC FDIS 42001 Crosswalk." https://airc.nist.gov/docs/NIST_AI_RMF_to_ISO_IEC_42001_Crosswalk.pdf [^3]: AICPA & CIMA. "SOC 2 — SOC for Service Organizations: Trust Services Criteria." https://www.aicpa-cima.com/topic/audit-assurance/audit-and-assurance-greater-than-soc-2 [^4]: Schellman. "What to Expect in the ISO 42001 Certification Process." https://www.schellman.com/blog/iso-certifications/iso-42001-certification-processs [^5]: NIST. "Generative AI Profile (NIST AI 600-1)." https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.600-1.pdf [^6]: Baker Tilly. "Evolving SOC 2 reports for AI controls." https://www.bakertilly.com/insights/ai-controls-for-soc-2-reports [^7]: Microsoft Learn. "ISO/IEC 42001:2023 Artificial Intelligence Management System Standards." https://learn.microsoft.com/en-us/compliance/regulatory/offering-iso-42001