Does the 2022 revision add AI-specific controls?

No. The 2022 revision restructured the Annex A control set (114 to 93 controls, 14 domains to 4 themes) and added 11 new controls (threat intelligence, cloud services, ICT readiness for business continuity, physical security monitoring, configuration management, information deletion, data masking, data leakage prevention, monitoring activities, web filtering, secure coding). None of the new controls are AI-specific. ISO/IEC 42001 is the AI-specific standard.

How does 27001 relate to 42001 for AI systems?

ISO/IEC 42001 is a management system standard for artificial intelligence. It reuses the 27001 clause structure but adds AI-specific requirements around the AI management system (AIMS), AI risk assessment, AI impact assessment, and AI system lifecycle controls. Organizations pursuing joint certification map controls across both standards. The ISO 42001 vs ISO 27001 piece covers the mapping.

What is the audit evidence for identity binding in AI requests?

The audit evidence is the log record showing the calling identity on each request, cross-referenced to the identity provider's records for that identity at the same timestamp. The record must survive the auditor's specificity question: if this credential were revoked, which users would lose access. A shared service credential fails; a per-user or per-agent identity claim on the request satisfies.

Does the auditor accept the LLM provider's audit log as evidence?

No, not on its own. The provider's log shows what the provider saw at the API boundary. It shows the calling service account, not the natural person behind the calling application. It does not show the policy decision the enterprise made. The enterprise-side audit record at the AI request boundary is the evidence auditors accept for controls 5.15, 8.15, and 8.16.

How often are Annex A controls re-tested?

ISO 27001 certification runs on a three-year cycle with annual surveillance audits. The full Annex A test happens at initial certification and recertification (year three). Surveillance audits sample controls each year. AI systems added mid-cycle typically surface at the next surveillance audit and receive full scrutiny at recertification.

What is the difference between logging (8.15) and monitoring (8.16)?

Control 8.15 covers producing, storing, and protecting the log records. Control 8.16 covers analyzing the records for anomalous behavior. A pipeline that lands records in a SIEM but has no AI-specific detection rules satisfies 8.15 and fails 8.16 under audit scrutiny. Both controls apply, and the evidence for each is distinct.

ISO 27001 Annex A Controls Applied to AI Systems: Where the 2022 Revision Already Covers AI and Where It Does Not

The 2022 revision of ISO/IEC 27001 took effect in October 2022 with a transition deadline of October 31, 2025. The Annex A control set collapsed from 114 controls across 14 domains to 93 controls across four themes: organizational (5.x), people (6.x), physical (7.x), and technological (8.x). Certified organizations completed the transition in 2024 and 2025. AI systems certified against the 2022 revision now surface a specific set of Annex A controls the auditor tests hardest when AI is in scope. I want to walk through the controls that stress under AI, what the auditor asks for, and where the evidence has to come from.

The evidence chain runs through the AI request boundary, which is where most 27001-certified deployments have zero instrumentation today.

The AI in scope question

The 2022 revision does not add an AI-specific control. ISO/IEC 42001, published in December 2023, is the management system standard for artificial intelligence and complements 27001 rather than replacing it. Organizations pursuing joint 27001 + 42001 certification map controls across both standards. The ISO 42001 vs ISO 27001 piece covers the overlap.

For 27001 alone, the auditor asks whether the AI system is an information asset in scope. When the AI processes information covered by the ISMS, the answer is yes and the control set below applies.

5.15 Access control

Control 5.15 requires rules for access to information and other associated assets, based on business and information security requirements. The audit test for AI systems is straightforward: which identities are authorized to invoke which models with which data, and how is that authorization enforced.

Deployments that authenticate to LLM providers with a shared service account fail the specificity test. The credential identifies the calling application, not the natural person or agent on whose behalf the application is acting. The ai agent identity pillar covers the identity binding pattern. The auditor's evidence request is the mapping between individual identities, the model endpoints they can reach, and the data classifications they can send.

8.10 Information deletion

Control 8.10 requires information stored in information systems, devices, or in any other storage media to be deleted when no longer required. For AI, the auditor asks whether the retention windows on prompt and response logs are documented and enforced, and whether deletion actually happens.

Two failure modes surface. First, the LLM provider retains prompt data on its side under its own retention schedule, which the deployer's ISMS does not control. The provider's data processing agreement is the primary reference. Second, the enterprise's own audit log store holds prompts and responses well beyond the retention window because deletion jobs never ran or never covered the AI log path. The AI audit log retention piece covers the retention floor requirement.

8.15 Logging

Control 8.15 requires logs recording activities, exceptions, faults, and other relevant events to be produced, stored, protected, and analyzed. For AI, the audit stress is on what the log records and whether it is trustworthy.

The auditor asks four questions. Which identity initiated the request. Which model responded. Which data classification the request touched. Which policy decision applied. Application-controlled logs answer the first inconsistently and the other three not at all, because the application does not evaluate identity, classification, or policy at the point of the AI call.

The ai audit logs format spec covers the fields a defensible log must include. The AI audit log immutability piece covers the storage-layer contract auditors accept.

8.16 Monitoring activities

Control 8.16 requires networks, systems, and applications to be monitored for anomalous behavior. For AI, the auditor tests whether monitoring covers AI-specific behaviors: prompt injection attempts, unusual data extraction patterns, model outputs that trigger content classifiers, rate spikes that indicate abuse.

The distinction from control 8.15 is that 8.15 is about producing the records and 8.16 is about analyzing them. A logging pipeline that lands events in a SIEM but has no AI-specific detection rules technically satisfies 8.15 and fails 8.16 under scrutiny. The ai-observability piece covers the metrics and alerts that map to 8.16 evidence.

8.24 Use of cryptography

Control 8.24 requires cryptographic controls to be effectively used to protect confidentiality, authenticity, and integrity of information. For AI, the auditor's test lands on three points: TLS between the calling application and the AI proxy, TLS between the AI proxy and the LLM provider, and cryptographic protection of the audit log.

The audit log signing question maps to tamper-evidence. Auditors accept HMAC-chained log lines, signed batches, or Merkle-tree constructions as evidence of integrity. The ai audit log hashing patterns piece covers the cryptographic choices.

8.28 Secure coding

Control 8.28 requires secure coding principles to be applied to software development. When the AI system uses agentic frameworks (LangChain, AutoGen, Semantic Kernel), the auditor tests whether the framework's known vulnerabilities have been mitigated. Microsoft's May 7, 2026 disclosure documented prompt-to-shell escalation paths in mainstream agent frameworks and reframed agentic AI as an RCE attack surface. The ai agent framework RCE piece covers the incident.

Secure coding evidence for AI frameworks includes SBOM entries for the framework, tracked CVEs, patch cadence, and the runtime policy that constrains the framework's tool-use blast radius when a jailbreak succeeds.

DeepInspect

This is the gap DeepInspect closes. DeepInspect sits at the AI request boundary as an external enforcement layer. Every request binds to a verified identity claim before it reaches the model. Every response passes back through the same layer. The audit record includes identity, model, data classification, policy decision, and cryptographic evidence of integrity. For an ISO 27001 audit with AI in scope, that record is the evidence chain against 5.15, 8.10, 8.15, 8.16, and 8.24 in a single control point.

The proxy architecture is stateless. Provider credentials never leave the credential store. Failure defaults are fail-closed. The audit log lands in an append-only store with write access separated from the application service account.

Book a technical deep dive at deepinspect.ai.