What an ISO 42001 statement of applicability must contain
Your customer questionnaire, contract or regulator now asks for ISO 42001, and the first document an assessor will request is the statement of applicability. Clause 6.1.3 of ISO/IEC 42001 requires it to list the controls your organization needs and to justify including or excluding each of the 38 Annex A controls across nine areas, from A.2 policies related to AI through A.10 third-party and customer relationships. Every Annex A control needs a line in the document, even when the answer is exclusion. A blank or partial list is the fastest way to signal that the management system has not been designed against your own AI risks.
The organization owns these decisions. Each inclusion or exclusion must trace back to your AI risk treatment and to the AI systems in scope, so the people who own those risks must sign off on the content. An implementation partner can prepare drafts, map existing evidence to each control and point out where a justification is thin, but it cannot decide what your organization accepts. Only an independent auditor or certification body tests the statement against your evidence and issues any certificate. Ask any partner to state this division of roles in the written scope before work starts.
No fixed fee applies to the statement of applicability itself. Effort depends on how many AI systems are in scope, how many Annex A controls are already partly met, and how much evidence must be gathered for each justification. Ask for a quote that lists the AI systems covered, the number of controls to be reviewed, the deliverables (draft, justification register, sign-off record) and the review rounds included, so the cost follows directly from the written scope.
Which factors decide whether each Annex A control stays in
No two organizations reach the same statement of applicability, because the answer for each Annex A control depends on what the organization builds, buys and uses. The cards below cover the factors that move those decisions and the evidence to collect for each one before a control is marked in or out.
AI systems in scope and role
Start with an inventory of every AI system in the certification scope and record the organization's role for each: provider, developer or user. A developer of a model needs life cycle and data controls that a user of a vendor tool may never touch, while a pure user leans on use and third-party controls. Collect the system register, the role decision for each entry, and the scope statement that ties them together.
Impact on people and groups
The more an AI system affects individuals, protected groups or society, the more impact assessment controls apply and the less defensible any exclusion becomes. A system that ranks job candidates or informs credit decisions usually keeps the individual and societal impact controls in scope. Collect the impact assessment records, the affected groups identified for each system, and the reasoning behind any exclusion of an impact control.
Data sources and provenance
Each data source feeding training, tuning, retrieval or evaluation shapes which data controls stay in. An organization that builds its own training sets must keep acquisition, quality and provenance controls, while one that only calls a hosted model may have a narrower data footprint. Collect the data source register, acquisition agreements, quality checks and provenance records for each source.
Reliance on third-party models
Heavy reliance on external models, APIs or data services moves supplier controls into focus and can change which life cycle controls the organization must run itself. Where a provider documents its own development practices, the organization may rely on those records but still needs to justify the boundary in writing. Collect supplier due diligence files, contractual terms covering model changes and incidents, and the responsibility split for each service.
Contractual and regulatory duties
Customer contracts, sector rules and the EU AI Act can require specific controls even when a general reading of Annex A would leave them out, so exclusions must be checked against those duties first. Where the EU AI Act applies, the organization should confirm its provider or deployer obligations against the controls it plans to exclude, and ISO/IEC 42001 alone does not settle that question. Collect the obligations register, the legal mapping memo and any customer questionnaire answers that promise a control.
Controls already running under ISO 27001
Where an ISO 27001 programme already operates access control, logging, change management or supplier security, those operating records may satisfy overlapping AI controls, but only where the AI scope is actually covered. Check that the ISO 27001 scope includes the AI systems and their data stores, because an information security control does not automatically cover AI-specific obligations such as impact assessment. Collect the ISO 27001 scope statement, the control evidence with its system boundary, and a note on each AI-specific gap that remains.
How to build the statement of applicability step by step
The sequence moves from knowing which AI systems the organization runs and what role it plays for each, through risk treatment decisions, to a control-by-control statement of applicability that management has approved and that points to where the evidence lives.
Inventory AI systems and assign roles
Start by listing every AI system in scope, including systems built in-house, bought from vendors, embedded in SaaS products and used by staff. For each one, record whether the organization acts as provider, developer or user, and who owns it internally. Confirm the list with system owners rather than relying on a procurement register alone. The output is a dated AI system inventory with a named owner and role for each entry, which becomes the scope baseline for every later step.
Complete AI risk assessment and treatment
Run the AI risk assessment required under clause 6.1.2 for each inventoried system, identifying risk sources and their consequences for the organization and interested parties. Then select a treatment option for each risk under clause 6.1.3 and record the residual risk and who accepted it. Risk criteria should be agreed before scoring starts. The output is a risk register with a treatment decision per risk, which is the input the statement of applicability must answer to. Guidance in ISO/IEC 23894 can inform this work.
Screen each Annex A control against treatment decisions
Work through all 38 Annex A controls across the nine objective areas, from A.2 policies to A.10 third-party and customer relationships. For each control, check whether a treatment decision or a system in the inventory calls for it. Use the Annex B implementation guidance to judge what the control would require in practice. Mark each control as needed or not needed for the scoped systems. The output is a working matrix that shows every control with a provisional status and the risk or system that drives it.
Write a justification for each control
For every control, write the justification for inclusion or exclusion in plain terms that an auditor can follow. An inclusion should name the treatment decision and the systems it covers. An exclusion should explain why the control does not apply to the scoped systems, not simply state that it is not needed. Avoid vague wording such as not applicable without a reason. The output is a complete justification column covering all 38 controls, with no blank entries, that a reviewer can trace back to the risk register.
Record evidence locations for included controls
For each included control, identify the document, record or system output that will show it operates, such as the AI policy, impact assessment records, design documentation or event logs. Record where each item is stored, who maintains it and how it is reviewed. Gaps found here often mean a control needs an owner or an implementation step before the statement can be relied on. The output is an evidence index linked to each included control, so an auditor can move from a control to its proof without assistance.
Obtain management approval of the statement
Present the draft statement of applicability, the risk register and the evidence index to top management for review. Management should confirm that the risk treatment decisions reflect its tolerance and that the exclusions are acceptable. Record the approval with the name, role and date of the approver, and the version of the document. Changes after approval should go back through the same review. The output is a version-controlled, approved statement of applicability that is the reference for the internal audit and any certification assessment.
Keep the statement aligned with risk treatment
Treat the statement as a living record. When a new AI system is added, a risk is re-rated, or a treatment decision changes, re-screen the affected controls and update the justifications and evidence index before the change goes live. Confirm the alignment at each internal audit and management review. The organization owns this maintenance. A consultant or implementation partner may help prepare the documents, but the controls and the approved statement remain the organization's responsibility.
Include, exclude or adapt: which justification fits each decision
This table compares the four decisions a team makes for each Annex A control: include as written, include with an adapted implementation, exclude with a risk-based reason, or add a control from another source. Read each row as a test: when the option fits, what evidence backs it, and what an auditor is likely to challenge.
| Decision | When it fits | Evidence an auditor expects | What an auditor is likely to question |
|---|---|---|---|
| Include as written | The control addresses a risk your AI risk treatment identified for a system in scope, and your AI systems match the control's assumptions. | A documented control implementation tied to a named AI system, with records showing it operates, such as an approved AI policy or a logged review. | A control marked as included but with no owner, no record and no link to a risk treatment decision. |
| Include with an adapted implementation | Your AI features differ from the generic case, for example continuous learning or limited explainability, so the control needs different safeguards. | Written rationale for the adaptation, the AI-specific safeguard used, and records showing the adapted process runs for the affected systems. | Whether the adaptation still meets the control objective, or whether it is a lighter version of the requirement with no added safeguard. |
| Exclude with a risk-based reason | Your scope contains no system or process where the control's subject matter arises, such as no data acquisition or no third-party AI supply, and the risk treatment supports that. | A justification statement referencing the scope, the system inventory and the risk assessment results, with a dated review. | Exclusions that rest on convenience, cost or a general statement that the topic does not apply. Auditors also check that the scope has not changed since the exclusion was recorded. |
| Exclude because a related control covers the need | Another included control already delivers the objective, and you can show the mapping. | A cross-reference in the statement of applicability and evidence from the covering control. | Mappings that are asserted but not demonstrated. Keep the link specific to the control objective, not just the topic name. |
| Add a control from another source | Annex A does not cover a risk you identified, for example a security or privacy risk that the AI risk assessment or a regulator requires you to address. | The added control's identifier and source recorded in the statement of applicability, with implementation evidence and the risk it treats. | Added controls with no source, no owner or no link to the risk treatment plan. Also whether the added control is actually implemented rather than listed. |
| Revisit after scope or risk changes | A new AI system, a changed role, a new supplier or a materially different use case enters scope. | Revision history of the statement of applicability, updated risk treatment records and approval by the accountable owner. | A statement of applicability that was written once and never updated, so its decisions no longer match the systems in operation. |
Justifying exclusions across the nine Annex A areas
Clauses A.2 to A.4 set the management direction, accountability and resource records that every AI system depends on. Few organizations exclude these controls outright, but the wording of an exclusion matters, because a control is often excluded only in part, for example when an organization has no separate concern-reporting channel and relies on an existing one.
- A.2.2 AI policy: Requires a documented policy that sets management direction for AI. Exclusion is hard to defend for any organization that provides or uses AI systems.
- A.2.3 Alignment with other organizational policies: Asks that the AI policy fits with existing policies such as security, privacy and risk. Check whether conflicting rules exist before excluding it.
- A.2.4 Review of the AI policy: Requires periodic review of the policy. Link it to the management review cycle, which makes exclusion difficult.
- A.3.2 AI roles and responsibilities and A.3.3 Reporting of concerns: Require named owners and a route for raising AI concerns. Exclusion usually signals a gap in accountability.
- A.4.2 to A.4.6 Resource controls: Cover the resource record, data, tooling, system and computing, and human resources. Annex B shows what each resource record should contain, so a resource can be excluded only if the AI system truly does not use it.
Confirm each exclusion against the Annex B guidance for the control and against your own resource inventory.
Clauses A.5 and A.6 cover impact assessment and the AI system life cycle, from design through monitoring and retirement. These are the areas assessors most often question when an organization excludes a control, because the exclusion usually covers a system that is already in production. An exclusion must show why the life cycle step does not apply to the specific system in scope.
- A.5.2 and A.5.3 Impact assessment process and documentation: Require a defined process and records of impact assessments. Exclusion is difficult unless the organization has no AI system with potential impact.
- A.5.4 and A.5.5 Impacts on individuals, groups and society: Ask for separate assessment of individual and group impacts and of societal impacts. Document each one, even when the result is low impact.
- A.6.1.2 and A.6.1.3 Objectives and processes for responsible design: Require documented objectives and design processes. Organizations that only buy AI may argue these do not apply, which needs evidence from the purchase and configuration records.
- A.6.2.2 to A.6.2.8 Requirements through event logs: Cover specification, design records, verification and validation, deployment, operation, technical documentation and logging. Annex B lists the evidence expected for each, so test each exclusion against it.
- A.6.2.6 and A.6.2.8 Operation and event logs: Operational monitoring and logging are rarely justified for exclusion, since assessors expect them for any system in production.
For each excluded life cycle control, confirm the Annex B guidance and the system's actual stage.
Clauses A.7 and A.8 address the data behind AI systems and the information provided to users, customers, regulators and other interested parties. These controls are often excluded when an organization treats its models as vendor products. That reasoning only holds when the organization does not collect, prepare or fine-tune data itself and does not publish any AI information to outsiders.
- A.7.2 Data for development and enhancement: Requires documented data management processes. Exclude it only if the organization never develops or enhances a model with its own data.
- A.7.3 to A.7.6 Acquisition, quality, provenance and preparation: Cover where data comes from, how quality is checked, how origin is traced and how data is prepared. Each exclusion needs a reason tied to the actual data pipeline.
- A.8.2 System documentation and information for users: Requires information for people who use the system. Most organizations that deploy AI cannot exclude it without a strong reason.
- A.8.3 and A.8.4 External reporting and incident communication: Cover adverse impact reporting and incident communication to interested parties. Check these against any contractual or regulatory notice duties before excluding them.
- A.8.5 Information for interested parties: Covers reporting obligations to external parties. Confirm the list of interested parties in your scope before deciding.
Test each exclusion against the Annex B guidance and your data flow diagram.
Clauses A.9 and A.10 apply when AI is used in daily operations and when responsibilities cross organizational boundaries. Organizations that buy AI services, or sell AI-enabled products, frequently exclude these controls on the grounds that the supplier or customer carries the duty. An exclusion is only defensible if the contracts and the operating records show where the duty actually sits.
- A.9.2 Processes for responsible use: Requires documented processes for using AI responsibly. Exclusion is hard to justify for any organization whose staff operate AI tools.
- A.9.3 Objectives for responsible use: Asks for objectives that guide use. Check whether the organization already sets measurable use objectives before excluding it.
- A.9.4 Intended use: Requires use to stay within the system's intended purpose. Exclusion may be considered only if the system has a single, contractually fixed purpose that staff cannot change.
- A.10.2 Allocating responsibilities: Requires life cycle responsibilities to be assigned between parties. Excluding it is weak when more than one party touches the system.
- A.10.3 and A.10.4 Suppliers and customers: Cover management of AI suppliers and meeting customer expectations. Test these against the supplier and customer contracts you hold.
Confirm each exclusion with the Annex B guidance and with the signed contracts that define where responsibility sits.
Adding controls from other sources without losing the Annex A baseline
When the 38 Annex A reference controls leave a gap, an organization can draw on other guidance and standards. Each added control must be recorded in the statement of applicability alongside the Annex A baseline, with its justification and owner.
Risk management guidance from ISO/IEC 23894
ISO/IEC 23894:2023 gives guidance on AI risk management and is the natural reference when your risk treatment needs more method than Annex A provides. Use it to shape how risks are identified, evaluated and treated, then record any resulting safeguard that is not an Annex A control as an added control with its justification. Check that each added control traces back to a risk in your AI risk treatment plan, so the statement of applicability and the risk register agree.
Impact assessment method from ISO/IEC 42005
ISO/IEC 42005:2025, published 28 May 2025, addresses AI system impact assessment. It helps you design the assessment process when Annex A.5 leaves method questions open, such as how to scope affected individuals and groups or how to document societal effects. Any assessment step that you add as a control belongs in the statement of applicability, with the reason it is needed and the record that proves it runs.
Governance crosswalk from the NIST AI RMF
The NIST AI RMF to ISO/IEC FDIS 42001 crosswalk maps GOVERN 1.3 and GOVERN 1.4, on risk management processes and risk tolerance, to ISO/IEC 42001 clauses 6.1.1 to 6.1.3 and 8.3 rather than to Annex A controls. This means those NIST expectations are met through management system requirements, not by adding Annex A controls. Confirm that the crosswalk's mapping is reflected in your risk process documentation before you add any control for these topics.
Shared security controls from ISO/IEC 27001
Many AI systems rely on infrastructure already governed by ISO/IEC 27001:2022 Annex A, which has 93 information security controls. Where an AI control depends on access management, logging or supplier security, reference the existing 27001 control in the statement of applicability instead of writing a duplicate. Record the link clearly, so an assessor can see which controls are shared and who owns each one.
Recording added controls in the SoA
Give each added control its own identifier, a plain statement of the control, the risk or requirement it addresses, the source it came from, its owner and the evidence that proves it operates. Keep these entries separate from the Annex A rows so the 38 reference controls remain visible. Ask your certification body how it expects added controls to be labeled before the first audit.
Keeping the Annex A baseline intact
Added controls supplement the 38 Annex A reference controls and never replace them. Each Annex A control still needs a recorded decision to include or exclude it, with a justification under clause 6.1.3. Review the baseline first, then add external controls, so that no Annex A decision is lost when the statement of applicability is revised after a risk treatment change.
Keeping the statement of applicability in line with AI risk treatment
The statement of applicability is a living record, not a document you sign once and file. Clause 6.1.3 ties it to AI risk treatment, so every control you include or exclude must still match your current risk treatment plan and risk register. When those change and the statement does not, the document stops describing the system you actually run, and that is the first thing an auditor will test. Treat the statement as an output of your risk process that is re-examined whenever that process produces a new decision.
Set up explicit triggers that reopen the statement. The usual ones are: a new AI system or model going into scope, a change in your role for an existing system (for example, moving from using a vendor model to building or fine-tuning one), a new data source or third-party model, a serious incident or near miss, a change in risk acceptance by management, and a new customer contract or regulatory requirement that touches AI use. For each trigger, name the owner who reviews the statement and the date by which they must do so. Confirm with your certification body how it expects changes to be recorded, since the expectation is set by the accredited body and your own management system, not by ISO.
Control the document like any other controlled record. Keep a version number, a change log that states what changed and why, and an approval record showing who signed off each version and when. Keep the previous versions available, because an auditor may ask what the statement said during an earlier period. Expect the auditor to sample exclusions and inclusions, check each justification against the risk register entry it cites, and then ask for the evidence that the control is operating, such as a policy, a log, or a completed impact assessment. A justification that points to a risk register entry that has since closed, or to evidence that does not exist, will be recorded as a finding. ISO/IEC 42001 has no amendment or revision in progress as of October 2026, so the change process you write and follow is what keeps this record accurate.
Where statements of applicability usually fail the audit
Most statement of applicability rework traces back to a small set of gaps: weak exclusion reasoning, contradictions with other AI governance records, and controls that exist only on paper. Each card names one failure, how to prevent it, and the record that shows the control is working.
Exclusions without a risk link
A justification such as "not applicable" tells an auditor nothing. Each excluded Annex A control should point to a specific risk or AI system context from the AI risk treatment record under clause 6.1.3, explaining why the control does not address a risk the organization has identified. Ask whether the exclusion would still hold if the AI system changed scope. The record that proves it is the risk treatment plan, with the exclusion traced to a named risk entry.
Justifications that contradict the AI policy
An exclusion can conflict with commitments the organization has already made. If the AI policy promises human review of automated decisions, excluding a control that governs human oversight in the life cycle creates a visible gap. Read the statement of applicability against the AI policy and the impact assessment side by side before each approval. The records that show alignment are the approved AI policy and the impact assessment register, with matching references.
Included controls with no operating evidence
Listing a control as implemented does not make it operate. Auditors ask for records produced by the process itself, such as completed impact assessments, data quality checks, or logged reviews with dates and named reviewers. For each included control, identify the artifact generated in normal operation and confirm it exists for the systems in scope. The operating record, not the statement, is what proves the control is in use.
A statement written once and never updated
The statement of applicability describes the management system at one point in time. New AI systems, changed suppliers, new data sources or a shift in the organization's role can all invalidate earlier justifications. Set a review trigger tied to change management and to the internal audit and management review cycle, and record the version, date and reason for each change. The version history and change log show whether the document tracks the actual AI estate.
A document owned only by a consultant
An outside adviser can draft the statement, but the organization must own its controls and approve its exclusions. A statement with no internal approver often cannot be defended when staff are asked why a control was chosen. Name an accountable owner inside the organization, have that person sign off each justification, and confirm that staff who run the controls recognize them. The approval record, with the internal owner's name and date, shows that the decisions belong to the organization.
Who writes, approves and defends the statement of applicability
Your organization owns every decision in the statement of applicability. Clause 6.1.3 requires the organization to list the Annex A controls it needs and to justify including or excluding each one, so the reasoning must come from people who understand the AI systems in scope, the risks they create and the obligations that apply to them. Leadership or a designated AI governance owner should approve the final document and the exclusions in particular.
- Decision owner: Name one accountable person who signs off the statement and can explain every exclusion in an assessment.
- Risk input: Feed the AI risk treatment decisions into each control justification so the statement matches the risk register.
- Business and technical review: Involve product, data, security and legal owners who can confirm whether a control applies to a given system.
- Approval record: Keep dated approval and version history so changes between the first and later reviews are traceable.
- Ongoing maintenance: Update the statement when AI systems, suppliers, data sources or risk treatments change, and record the reason for each change.
Before engaging anyone outside the organization, confirm that your own people can defend each inclusion and exclusion without reading from a draft prepared by someone else.
An implementation partner can prepare the working draft, map existing evidence to each Annex A control and flag gaps. This is preparation work. The partner does not decide which risks the organization accepts, which controls it excludes or how much residual risk is tolerable, because those are management decisions tied to the organization's own objectives and exposure. A partner that writes the justifications as if they were its own conclusions has moved the decision outside the organization.
- Draft preparation: Produce a structured draft that lists each Annex A control, its current status and the candidate justification for the organization to review.
- Evidence mapping: Match existing policies, procedures, impact assessments and technical records to controls, and identify where evidence does not yet exist.
- Gap flagging: Report controls where the operating practice is missing or unclear, without deciding whether the gap is acceptable.
- Configuration support: Where open-source platforms produce logs or records, help set up the systems that generate the evidence the statement refers to.
- Handover: Transfer the draft, the evidence index and the open items to your team in a form they can review, change and own.
If you buy this help, the written scope should state which outputs are drafts and which decisions remain with your team.
Only an independent auditor or accredited certification body issues an audit report or certificate. The auditor tests the statement of applicability against the operating management system and the evidence behind it. It checks whether each inclusion is supported by working controls and whether each exclusion is justified in a way that holds up against the organization's risks and scope. Certification bodies apply ISO/IEC 42006:2025, which sets additional requirements on top of ISO/IEC 17021-1 for bodies certifying AI management systems.
- Consistency testing: Check that the statement, the risk treatment decisions and the evidence describe the same system in the same way.
- Exclusion review: Test whether each excluded control is justified by the organization's context and risk, not by convenience.
- Independence: The auditor should not write the statement, because that would compromise its ability to judge the result.
- Evidence sampling: Auditors select records and observe operation to confirm the statement reflects practice.
- Certification decision: Only the certification body decides whether to issue, maintain or withdraw a certificate.
Before the audit, ask the certification body which documents it will request, how it will sample evidence and how it handles questions about exclusions.
Choosing a partner to help with the statement of applicability
A partner can help prepare the statement of applicability, but the organization owns every inclusion and exclusion decision. The checks below help procurement and the compliance lead confirm that the certification side, the scope and the handover are clear before any work starts.
Confirm certification body accreditation
ISO does not certify organizations, and accreditation of certification bodies is voluntary. Ask the certification body which accreditation body accredits it for ISO/IEC 42001, and check that accreditation directly with that body. Note that as of Global ACI-FMRA-001 version 3.3, ISO/IEC 42001 is not listed as an endorsed sub-scope of the Global ACI recognition arrangement, so do not assume recognition travels with ISO 27001 accreditation. Ask for the accreditation scope in writing.
Confirm who signs risk decisions
The statement of applicability justifies each inclusion and exclusion, and those justifications rest on the AI risk treatment decisions under clause 6.1.3. Ask the partner who drafts the justifications and who in the organization approves them. A named executive or AI governance owner should sign the final version. If the partner proposes to make exclusion decisions on the organization's behalf, treat that as a red flag.
Separate advisory and certification roles
Ask whether the firm preparing the statement of applicability will also certify the organization. Certification bodies must stay independent of the work they audit, so a firm that designs the controls should not also issue the certificate. Request a written statement of the partner's role and confirm which firm is the certification body. Where the same firm is proposed for both, ask for the conflict assessment before signing.
Agree written scope and deliverables
Most engagements are fixed-scope, so the written scope should list the AI systems covered, the Annex A controls in review, the documents to be produced and the review rounds included. Ask for the deliverables by name, such as the draft statement of applicability, the justification log and the change record. Agree in writing how changes to scope, such as a new AI system, will be priced and scheduled.
Define evidence handover
Ask how evidence leaves the engagement. The organization should receive the working files, the decision records and the source material in formats it controls, not only a final PDF. Confirm where the evidence will be stored, who holds administrator access and how it stays available for surveillance and recertification audits. Ask for a handover checklist that the compliance lead signs.
Confirm what the partner will not do
Ask the partner to state in writing that it will not issue audit reports, attestations or certificates, and will not decide controls for the organization alone. Confirm it will not guarantee certification outcomes. A credible partner prepares systems and evidence, then steps back so an independent auditor can test them. Any promise of a certificate or a fixed audit result should end the evaluation.
Common questions about excluding ISO 42001 Annex A controls
Do we have to implement all 38 Annex A controls in ISO 42001?
No. Annex A lists 38 reference controls, and the organization decides which ones it needs. Clause 6.1.3 requires a statement of applicability that lists the controls the organization needs and justifies including or excluding each Annex A control. An exclusion is therefore allowed, but it must be argued from your AI risks, your AI systems and your role for each system. Leaving a control out because it is inconvenient will not survive an assessor's review. Expect the auditor to test every exclusion against the scope of your AI management system.
What evidence does an ISO 42001 control exclusion need?
An exclusion needs a written justification that ties the control to a reason an assessor can check. Useful reasons include that the AI system is outside the scope defined under clause 4.3, that the organization does not provide AI systems to the group the control protects, or that the risk the control addresses was assessed and found not to apply. Keep the risk assessment record, the impact assessment records and the scope document that support each reason, and cross-reference them in the statement of applicability. Ask your auditor which form of justification they expect before you finalize the document.
Can our own team write the ISO 42001 statement of applicability?
Yes, the organization can write it, and it should own the content. The statement of applicability describes your AI systems, your risks and your decisions, so only your staff can make those decisions in a defensible way. An implementation partner can help structure the document, check that each Annex A control is addressed, and prepare the supporting records. What the partner cannot do is decide your exclusions on your behalf or issue any certificate. Independent certification bodies assess the document, and they do not write it for you.
How does the statement of applicability relate to the AI risk assessment and impact assessment?
The statement of applicability sits at the end of the risk treatment chain. Your AI risk assessment identifies risks and your risk treatment decides how each one is handled, and the Annex A controls you select are the treatment options you adopt. Impact assessment, covered by the controls in area A.5, looks at effects on individuals, groups and society, and its findings can add or remove controls. If you change an assessment, review the statement of applicability in the same cycle. A control excluded in one version of your risk picture can become necessary after a new system or a new use case appears.
How long does the statement of applicability take, and what drives the effort?
No duration or price is given here without a written scope, and the effort depends on the work that feeds the document. The main drivers are the number of AI systems in scope, how many of those systems you build versus only use, whether your AI risk and impact assessments already exist, and how many of the 38 controls need new evidence. Organizations with few systems and mature records usually move faster than those starting their first risk assessment. Ask any provider to break the effort into scoping, control analysis, evidence gathering and review, and to state which parts depend on your decisions.
What do we need from our internal staff for this work?
Internal staff must supply the facts that the document rests on. The most important inputs come from people who know the AI systems, including product owners, data owners, engineering leads and whoever runs risk management. Legal, privacy and compliance staff should review the justifications for exclusions that touch regulation or personal data. Someone with authority must approve the final statement of applicability and accept the residual risk it records. Plan time for these people in the written scope, because a partner cannot answer questions about your systems that only your team can answer.
Which parts of the statement of applicability can an outside partner handle?
A partner can prepare systems, controls and evidence, and it can structure the statement of applicability and check its consistency. It can also run gap analysis against the Annex A controls and help the team collect records for each control. What stays with the organization is the decision on each control, the acceptance of risk, and ownership of the AI governance process after the engagement ends. Certification itself is issued only by an independent certification body. Confirm the split of responsibilities in the written scope before work starts.
How DeployOpen prepares the statement of applicability and its evidence
DeployOpen helps organizations prepare the inputs to an ISO 42001 statement of applicability: the scope of their AI systems, the Annex A controls they need, and the evidence behind each decision. The organization keeps ownership of every control decision, and an independent certification body is the only party that issues a certificate.
How we scope
- We agree the written scope of the AI systems, platforms and teams covered before any work starts.
- We map which Annex A controls are in scope for each system, using the agreed AI risk treatment decisions as the starting point.
- We record the justification for including or excluding each Annex A control so the organization can defend it to an assessor.
How we build
- We configure the self-hosted open-source platforms in your own infrastructure to produce the records each included control needs.
- We draft the statement of applicability entries for review by your AI governance owner, who makes the final control decisions.
- We test that the chosen controls match the actual system configuration, so the document describes what runs in practice.
How we hand over
- We deliver the statement of applicability, the justification record and an evidence index that links each control to its artifacts.
- We document the review cycle and the change triggers that require the statement of applicability to be updated.
- We walk your team through the handover so the internal owner can maintain the document after the engagement ends.
How we support
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
- Ongoing support, upgrades and continuous testing are available as a retainer to keep the statement of applicability current.
- Certification decisions remain with the organization and its independent certification body, which DeployOpen does not select or replace.
