ISO 42001 Audit Criteria for Privacy Preserving AI

This piece walks through exactly which requirements those are, what evidence satisfies an auditor, and where architecture choices like on-device inference or federated learning actually earn credit rather than just good intentions.

ISO 42001 and what it governs

The certifiable requirements are in Clauses 4–10, following the same architecture as ISO 27001, while Clauses 1–3 cover scope, references, and terminology.

And the content is different, because the risks ISO 42001 governs don't look like information security risks at all. Algorithmic bias, model drift, decision opacity, autonomous decision-making, and impacts on fundamental rights sit at its center, distinct from ISO 27001 (protecting data and systems from unauthorized access) or GDPR (lawful processing of personal data). The standard applies to any organization developing, providing, or using AI-based products or services, regardless of industry or size.

One clarification matters before going further: ISO 42001 does not test whether an AI model is technically secure or safe in some absolute sense. It governs the management system, policies, processes, and oversight, around the AI. That distinction shapes everything an auditor actually looks at.

Privacy-preserving AI's distinct audit surface within the standard

Privacy is not the only thing ISO 42001 cares about. It treats privacy as one axis among several, alongside bias, fairness, safety, transparency, and explainability, all examined during certification. But privacy controls carry their own evidence requirements, disproportionately relevant to organizations whose architecture is already privacy-preserving.

Privacy-by-design is not optional flavor under this standard, it's baked into the data governance controls themselves. Those controls require privacy throughout the AI lifecycle, from data ingestion to model output, covering consent, minimization, access limits, encrypted storage, and deletion. An auditor isn't asking whether an organization has a privacy policy somewhere in a shared drive. Privacy decisions appear as design choices at every stage a piece of data touches.

This is where architecture starts to matter more than paperwork. An architecture that keeps user data out of provider hands entirely, via non-collection, on-device inference, or federated approaches, tells auditors a structurally different story than one that retains data centrally and layers compensating controls on top. Neither approach is disqualified by the standard. One produces evidence almost automatically, since data that never enters a system can't be misused by it, while the other must demonstrate the same assurance through logging, access controls, and retention policies.

What ISO 42001 does and doesn't replace calls for precision. It keeps its AI-specific risk scope separate from ISO 27001's security scope and GDPR's data-subject-rights scope, treating all three as complementary. An AI system that processes personal data to make automated decisions about people needs all three frameworks working together, not one standing in for the others. That interplay comes back in more detail later in this piece.

The certifiable clauses and what auditors examine in each

Clause 5, Leadership, wants a published AI policy, clear accountability, and demonstrable executive funding.

Clause 6, Planning, is dense. It requires a formal AI risk and impact assessment, measurable objectives, and a Statement of Applicability mapping every chosen control to Annex A. That subclause gets its own dedicated section below because it's the one auditors flag most often.

Clause 7, Support, wants evidence of skilled personnel, reliable data pipelines, secure tooling, training records, and documentation letting auditors retrace how a decision was reached.

Clause 8, Operation, is where risk treatment is executed and impact assessments run against production systems, not just on paper. The standard expects ongoing risk assessment throughout operation.

Clause 9, Performance Evaluation, covers monitoring the AIMS itself, internal audits, and management reviews covering audit results, incident trends, stakeholder feedback, and resource adequacy.

Clause 10, Improvement, requires nonconformities to be addressed with corrective action and continual improvement to be documented, not assumed.

What separates this audit isn't the clause structure, nearly identical to ISO 27001's. Clause 8 and subclause 6.1.4 deserve the most attention of the bunch, because that's where the next section's subject lives. Clause 4 (Context) requires the auditor to verify a defined AIMS boundary, identified interested parties, external issues like the EU AI Act, sector regulation, and stakeholder expectations, and internal issues like AI strategy and third-party model dependencies.

The AI System Impact Assessment: the requirement that most distinguishes this standard

Start with the failure mode, because it's instructive. The most common Stage 2 failure is a generic risk register covering financial or reputational risk while ignoring impact on individuals and society. That kind of document will not satisfy an auditor.

What does a satisfying AISIA actually cover? It must address whether the AI affects someone's legal position or life opportunities, physical or psychological well-being, human rights, or societal-level effects like shifts in employment or public trust. It also has to reckon with intended use against foreseeable misuse, weigh positive and negative impacts honestly, and think through predictable failure modes given the demographic groups involved and the system's complexity.

The AISIA is also where the Data Protection Impact Assessment required under GDPR and the AI-specific assessment under Clause 8.4 actually meet. Together they support purpose limitation, data minimization, explainability, and data subject rights, making the AISIA where GDPR-adjacent obligations fold into AI-specific requirements. For teams wanting a deeper reference, ISO/IEC 42005:2025 exists specifically to provide guidance on how to conduct these assessments.

The AISIA is exactly where a non-collection or minimal-processing design earns real credit. If data never enters a system, certain impact pathways are demonstrably closed, verifiable directly rather than by trusting a compensating control. That's a meaningfully different audit conversation than explaining why an access control layered on top of a large retained dataset is sufficient. Clauses 6.1.4 and 8.4 together require a documented process assessing potential consequences for individuals, groups, and societies across the AI system's full lifecycle.

The 38 Annex A controls that carry the most weight for privacy

Annex A holds 38 controls spread across nine areas, labeled A.2 through A.10, and every one of them is normative. Each control must be implemented and evidenced, or formally excluded in the Statement of Applicability with a documented reason. There's no quiet skipping.

A.2, the AI Policy area, checks that existing policies (information security, privacy, ethics) already address AI explicitly, with gaps closed by AI-specific language rather than left implied. A.5 ties most directly to the impact assessment work above; within it, A.5.2 requires a structured process evaluating AI system impact across the full lifecycle, weighing purpose, complexity, and data sensitivity.

The data governance requirements run through the whole lifecycle: consent logs, encryption, access limits, deletion procedures. Auditors are looking for these as controls actually embedded in daily operation, evidenced through system logs and records, not documentation assembled the week before an audit.

A.10, covering supply chain and third-party relationships, deserves particular attention for anyone building on top of external model providers or inference infrastructure. Auditors examine supplier controls under Clause 8.3, going further than ISO 27001's equivalent Annex A.15 control by requiring model providers, data suppliers, and infrastructure partners to align with the organization's own responsible AI commitments. An organization can't simply outsource its AI risk to a vendor and call the obligation discharged.

A centralized inventory of every model in use, its training data sources, and its intended purpose is mandatory going into certification. Organizations that can't produce this inventory on request are, in a practical sense, not ready for Stage 2 yet.

Three supporting annexes, none certifiable, are also useful: Annex B gives implementation guidance for Annex A controls, Annex C catalogs AI-related objectives and risk sources, and Annex D offers interpretive examples.

How privacy-enhancing techniques are treated under the audit lens

ISO 42001 doesn't name specific privacy-enhancing technologies anywhere in its text. It mandates controls that, in practice, are satisfied by a handful of well-established techniques organizations already use.

Differential privacy is one: adding calibrated noise to training data so sensitive information can't be extracted back out of a trained model. Multi-party computation is also used, sometimes alongside differential privacy or federated learning, where an organization must satisfy both the standard's risk minimization bar and applicable data regulation.

Federated learning is the one that deserves the most unpacking, because it's also the one most likely to create a false sense of security. On the surface, federated learning looks like an obvious privacy win: training happens across distributed devices without raw data ever being centrally pooled, closing off impact pathways the AISIA would otherwise flag. But federated systems remain vulnerable to inference attacks that can extract sensitive information about individuals even when never directly included in any single training batch. An auditor won't accept "the data was distributed" as the end of the conversation. They'll want evidence the organization assessed inference attack risk and mitigated it, since federated architecture reduces one exposure category without eliminating others.

The broader principle: when architecture structurally prevents certain data from entering a system, via non-collection or on-device processing, the AISIA can document those impact pathways as closed outright. That's a stronger audit posture than building compensating controls on top of a system that's data-rich by default. Differential privacy, adding calibrated noise to prevent sensitive data extraction from models, is examined as a documented risk treatment mapped in the SoA, not merely a technical footnote.

The audit process: Stage 1, Stage 2, surveillance, and the accreditation question

Certification runs in two stages.

Two failure patterns occur repeatedly at Stage 2. The first is a missing or inadequate AISIA, the generic risk register problem already described. The second is subtler: excellent written policy with no records showing it's actually followed. An unoperationalized policy generates no evidence trail, and auditors can't certify a system that exists only on paper.

Cost typically runs from $20,000 to $60,000, with a timeline of four to nine months, shorter for organizations that already hold ISO 27001. Certification is valid 3 years, with surveillance audits in years 2 and 3 focused on Clauses 8–10 and a sample of Annex A controls, and full recertification in year 4. This means organizations must maintain operational evidence continuously.

One decision matters more now than it did when the standard first launched: which certification body does the auditing. ISO/IEC 42006:2025, published July 2025, sets requirements for bodies auditing against ISO 42001, so a body's accreditation status is now worth checking. BSI's global digital director has warned that many actors are entering the AI audit market, and without ISO 42006 as a filter, buyers risk paying for rigor they don't actually get. Verifying that a certification body has itself been assessed against ISO 42006 is a substantive safeguard, not a bureaucratic formality. This practical step is what makes the certificate on the wall mean what it's supposed to mean. Stage 1, lasting 1–2 days, involves the auditor reviewing AIMS design, policies, documentation, readiness, and is not an operational assessment. Stage 2, lasting 1–3 weeks, assesses operational effectiveness through staff interviews, process observation, and evidence collection across clauses and Annex A controls, and is where non-conformities are identified.

ISO 42001's position relative to ISO 27001, GDPR, and the EU AI Act

Each of these frameworks is protecting something different, and none of them is redundant with the others. GDPR governs lawful processing of personal data and the rights of the people that data describes. ISO 42001 governs AI-specific risks: bias, drift, explainability, autonomous decision-making, and societal-scale impact.

An automated credit decision system makes the division concrete. GDPR governs how the personal data feeding that model gets processed and what rights the person on the other end of the decision retains. ISO 42001 manages whether the output discriminates against protected groups or produces an unexplainable decision. None of the three does the other's job.

Timing gives this some urgency. Certification doesn't substitute for legal compliance with the Act, but builds the structured governance layer that makes demonstrating compliance far more tractable to regulators. The standard's thematic center, data governance and quality, transparency and human oversight, and ethical practice, mirrors the Act's own goals.

SOC 2 sometimes gets raised in the same breath as ISO 42001, but the two aren't interchangeable. SOC 2 is a CPA-assessed attestation, not a certification, covering security, availability, processing integrity, confidentiality, and privacy, with no AI-specific governance requirement. An organization holding SOC 2 has demonstrated something real about its operational controls. It has not demonstrated how it governs bias, drift, or societal impact of an AI system in production, precisely the ground ISO 42001 was built to cover. Organizations already holding ISO 27001 get shorter timelines since control frameworks overlap (A.5.1 (Policies) aligns with ISO 42001 5.2 (AI Policy), and A.8.2 (Information Classification) supports 6.1.2 (AI Risk Assessment) for training data sensitivity), but treating them as one initiative risks missing AI-specific gaps. The EU AI Act's December 2027 deadline for high-risk systems (Annex III) makes ISO 42001 timely, since it addresses Articles 9–15 (risk management, data governance, technical documentation, record-keeping, transparency, human oversight, accuracy/robustness/cybersecurity) as a governance layer demonstrating systematic compliance, though certification doesn't substitute for legal compliance.