What Is a Statement of Applicability in ISO 42001? A Practical Implementation Guide

What the Statement of Applicability Is

The Statement of Applicability (SoA) is a document that lists every control in ISO 42001 and, for each one, makes three declarations: whether the control is applicable to your organisation, what the current implementation status is (met, partial, or gap), and — for any control declared not applicable — a documented justification for that exclusion.

Conceptually, the SoA bridges the gap between the standard's universal control set and your specific organisational context. ISO 42001 was written to apply across all types of AI systems, all industries, and all organisational sizes. Your company is not all types. The SoA is where you translate the general standard into a specific, documented governance position for your specific AI systems, risks, and context.

For Singapore organisations, the relevant standard is SS ISO/IEC 42001:2024, the Singapore adoption of the international standard that received SAC (Singapore Accreditation Council) certification capability from February 2025. This means Singapore businesses can now engage SAC-accredited certification bodies for ISO 42001 certification — and if you are preparing for that, your SoA needs to be auditor-ready, not just internally usable.

The SoA is not a one-time compliance exercise. It is a living document. As you implement new AI systems, retire old ones, identify new risks, or expand into new use cases, the SoA evolves. An SoA that has not been reviewed in 18 months is likely out of date — and an auditor will notice if the controls' evidence references point to systems or processes that no longer exist or have changed significantly.

Why the SoA Matters: The SoA as a Governance Artefact

The SoA's value is not just compliance. The process of building it is itself a governance exercise. Working through all 65 controls and making explicit, documented decisions about each one forces your organisation to think systematically about AI risk in ways that ad hoc governance does not.

Consider what the SoA process reveals. When you reach A.7.5 (Data provenance), you have to ask: can we trace where the data used to train or operate our AI systems came from? If your answer is "we use a third-party foundation model (GPT, Claude, Gemini) and have no insight into its training data," you have just identified a real governance gap. You cannot declare A.7.5 "met" with that answer — but now you know what you need to address.

When you reach A.5 (AI impact assessment), you have to ask: have we formally assessed the potential harms this AI system could cause — to individuals, to society, to our organisation — and documented our conclusions? If you have been using an AI-powered hiring tool without a formal impact assessment, the SoA exercise surfaces that as a gap. That is the point.

The SoA also serves a communication function. When a Singapore government agency, a procurement client, or a major enterprise partner asks for evidence of your AI governance posture — increasingly common as IMDA's AI Governance Framework becomes a reference point for enterprise procurement — your SoA is the structured answer. It shows not just what controls you have implemented, but that you have systematically assessed all controls, made documented decisions, and can account for every gap.

The 65 Controls: How They Are Structured

ISO 42001's 65 controls fall into two categories with important differences.

Clauses 4–10: The mandatory management system requirements. These are the "shall" statements that define how your AI management system is structured, governed, planned, operated, evaluated, and improved. There are 27 such requirements across the following clauses:

Clause 4 (Context of the organisation): understanding internal and external issues relevant to your AI purpose, defining the scope of the AI management system. Clause 5 (Leadership): top management commitment, AI policy, organisational roles. Clause 6 (Planning): risk assessment for AI, treatment of AI risks and opportunities, AI objectives. Clause 7 (Support): resources, competence, awareness, communication, documented information. Clause 8 (Operation): operational planning and control, AI risk assessment and treatment in practice, AI impact assessment process. Clause 9 (Performance evaluation): monitoring, internal audit, management review. Clause 10 (Improvement): nonconformities, corrective action, continual improvement.

These clause requirements cannot be declared "not applicable." Every organisation seeking ISO 42001 conformance must address all of them. They define the management system that governs your AI activities.

Annex A: The 38 technical and operational controls. These are the specific controls addressing particular AI governance domains. Unlike the clause requirements, Annex A controls can be declared "not applicable" with a documented justification. They are organised into nine control domains:

A.2 — Policies for AI (AI use policy, AI risk management policy). A.3 — Internal organisation (roles, responsibilities, AI governance committee). A.4 — Resources for AI (infrastructure, human resources, A.4.3 data resources). A.5 — Impact assessment (mandatory AI impact assessment process — this is a pivotal control). A.6 — AI system lifecycle (design, development, testing, deployment, monitoring, decommissioning). A.7 — Data for AI systems (the data governance core: A.7.2 data for development, A.7.3 data acquisition, A.7.4 data quality, A.7.5 data provenance, A.7.6 data preparation). A.8 — Information for interested parties (transparency and disclosure requirements — what you communicate about your AI systems and to whom). A.9 — Use of AI systems by the organisation (responsible use, human oversight, addressing concerns). A.10 — Third-party AI relationships (vendor due diligence, contracted AI services, supply chain AI risks).

Building Your SoA: The Process Step by Step

Building a genuinely useful SoA requires a structured process. Here is the approach VerityOS recommends for Singapore organisations:

Step 1: Establish your AI systems inventory. Before you can assess control applicability, you need to know what AI systems your organisation uses, develops, or provides. This is the AI Systems Register — a list of all AI systems with their purpose, inputs, outputs, risk classification, and the stakeholders affected. Without this inventory, applicability decisions are made in a vacuum.

Step 2: For each control, assess applicability. Work through all 65 controls systematically. For each Annex A control, determine: does this control address a risk or requirement that exists in our context? For most organisations using AI systems, most Annex A controls will be applicable. The "not applicable" determination requires a genuine reason — not just "we do not want to implement this."

Step 3: For applicable controls, assess current status. Use a clear status framework: Met (evidence exists demonstrating the control is implemented and effective), Partial (control is partially implemented — some evidence exists but gaps remain), Gap (control is not yet implemented — no current evidence). Be honest. An SoA where every control is declared "met" without evidence is an SoA that will not survive audit scrutiny.

Step 4: Link evidence for "met" controls. Every control declared "met" needs a specific, retrievable evidence reference. Not "we have a data quality policy" — but "Data Quality Policy v1.2, approved 2026-03-15, stored at [reference], reviewed annually." The evidence needs to be specific enough that an auditor can find and verify it without your guidance.

Step 5: Define treatment plans for "gap" controls. For each gap, document: what needs to be done, who owns it, and by when. This transforms the SoA from a snapshot of current state into an active improvement plan. Gap controls without treatment plans are a recurring finding in ISO 42001 readiness assessments.

Step 6: Document "not applicable" justifications. For any control declared not applicable, the justification must be specific to your context and plausible in light of your AI systems. "We do not use AI" is not an acceptable justification for an organisation going through an ISO 42001 certification process. "Our AI system uses only real-time sensor data and does not involve historical training datasets, making A.7.2 (data used in AI model development) not applicable" is a specific, auditable justification.

The Data Governance Controls in Depth: Annex A.7

Annex A.7 — Data for AI Systems — deserves extended attention. It is the section of ISO 42001 most directly relevant to AI data governance, and it is where many organisations have the most significant gaps.

A.7.2 — Data used in the development of AI systems. Addresses data requirements for AI training and development. Requires organisations to define and implement processes for identifying, collecting, and managing data used in AI model development. Particularly relevant if you develop or fine-tune AI models in-house.

A.7.3 — Acquisition of data for AI systems. Due diligence on how data is obtained. Is it legally acquired? Appropriately consented? Compliant with PDPA? This control is directly relevant to Singapore organisations because PDPA requirements on data collection and use have specific implications for AI training data. An organisation using third-party data sets purchased from a broker needs to document the acquisition basis under A.7.3.

A.7.4 — Quality of data for AI systems.Requires defining data quality criteria appropriate to each AI system's purpose, monitoring data quality continuously, and addressing quality issues when they arise. This is not a one-time check — it is an ongoing process with defined metrics, monitoring cadence, and escalation procedures.

A.7.5 — Data provenance for AI systems.One of the most technically challenging controls for organisations using third-party AI (foundation models, APIs). You need to understand and document where the data used by your AI systems came from, how it was collected, and how it has been transformed. For foundation model users, this means having a documented position on the foundation model provider's data practices — not full audit access, but a documented risk assessment based on publicly available information and contractual terms.

A.7.6 — Data preparation for AI systems. Addresses pre-processing, cleaning, transformation, and augmentation of data before it is used in AI systems. Requires processes to ensure that data preparation steps do not introduce biases or errors that affect AI system behaviour.

The A.7 controls collectively represent the data governance layer of ISO 42001 — and they map closely to the principles of AI data quality that we cover in depth separately. Getting A.7 right requires both documented policies and operational processes that can be evidenced.

Common SoA Mistakes to Avoid

In practice, ISO 42001 SoAs are weakened by a predictable set of recurring mistakes. Understanding them before you start building your SoA is more valuable than discovering them during an audit.

Declaring "met" without evidence attached. This is the most common weakness. A status of "met" is only as credible as the evidence behind it. If the evidence link is missing, the declaration is unsubstantiated. Auditors will probe "met" declarations specifically, asking to see the referenced evidence. "We do this" without a document, a record, or a demonstrable process is not evidence.

Declaring "not applicable" without justification. Some organisations try to reduce their compliance burden by marking challenging controls as "not applicable" without genuine reason. This is easily spotted by auditors who are familiar with the control domain. The justification must be specific to your context and consistent with your AI systems inventory. If your SoA says A.7.5 (data provenance) is not applicable, but your AI systems register lists three AI tools using external data, that inconsistency will be questioned.

Treating the SoA as a one-time exercise. The SoA is a living document. AI systems change. Risks evolve. New AI tools get deployed. The SoA needs a defined review frequency (typically annual at minimum, with interim updates when significant AI system changes occur) and a defined owner who is accountable for keeping it current.

Not involving AI system owners in the assessment. The SoA assessment for controls related to a specific AI system needs input from the team that actually runs that system. An SoA written entirely by the compliance or legal team without input from the AI product team will have blind spots in the controls that address technical AI risks. A.6 (lifecycle controls) and A.7 (data controls) in particular require operational input.

Confusing the SoA with an audit report.The SoA is management's self-assessment of the organisation's conformance position. It is not a third-party verification. The audit report is what an independent auditor produces after reviewing your SoA, your evidence, and your AI systems. Presenting your SoA to a client as if it is a certification document overstates what it is — and this misrepresentation will be noticed by sophisticated procurement teams.

What VerityOS Provides for ISO 42001 Implementation

VerityOS's AI Governance module includes a built-in SoA workspace with all 65 ISO 42001 controls pre-loaded. For each control, you can:

Set the applicability status (applicable / not applicable) with a free-text justification field for not-applicable decisions. Set the implementation status (met / partial / gap) for applicable controls. Assign a control owner from your organisation. Link evidence documents from the VerityOS vault — the same append-only, hash-chained evidence store used for sustainability reporting. Add treatment plans for gap controls, with owners and target dates. View your overall conformance percentage (met controls as a proportion of applicable controls) as a real-time readiness indicator.

The SoA can be exported as a structured PDF for sharing with certification bodies, procurement partners, or board-level governance review. All status changes are logged with a timestamp and the user who made the change — maintaining an auditable history of how the organisation's conformance position has evolved over time.

For Singapore organisations preparing for ISO 42001 certification readiness (VerityOS positions the platform as certification-ready — we do not claim it is itself certified), the SoA workspace provides the structured framework to progress systematically from initial assessment through to full implementation readiness.