%201.svg)
HIPAA Compliance Checklist for 2025
Your AI policy is signed, your approved tools list is current, and Annex A hands you 38 controls to decide on.
That list can’t tell you which controls apply when your AI is Copilot and ChatGPT Enterprise bought as SaaS. It also can’t prove an exclusion when the auditor asks how you know nobody trains models in-house.
And the list is usually short. Plex counted 30 sanctioned AI tools, then discovery found 73 shadow AI tools running across the business.
Most ISO 42001 Statements of Applicability drafts fail on exactly this. The rows get written from the standard, while the evidence sits in an AI inventory IT hasn’t built yet.
Build the SoA from that inventory, and every row has proof behind it. This guide covers the fields auditors check, five worked rows from an IT-led AI stack, the template to use, and how the SoA shapes audit cost and timeline.
What an ISO 42001 Statement of Applicability Has to Prove to Your Auditor
An ISO 42001 Statement of Applicability proves that every Annex A control was weighed against your AI risks, with a written reason for each inclusion and exclusion. ISO/IEC 42001:2023 requires it under clause 6.1.3 as the output of AI risk treatment.
The clause asks for less than most templates suggest:
Searches for an "ISO 42001 Statement of Applicability 2022" usually mean ISO 27001:2022, since ISO 42001 was published in 2023. For the clause-by-clause picture, see our full ISO 42001 requirements breakdown.
Already run an ISO 27001 SoA? The mechanics carry over, so start with how we build the ISO 27001 version and adjust the judgment calls below.
Built or Bought? The Question That Decides Most of Your SoA Rows
Whether you build AI or buy it decides most rows in an ISO 42001 SoA. The standard separates AI providers, producers, and users, and an IT team rolling out Copilot and Claude sits on the user side.
Development controls become candidates for exclusion, and the controls covering how your people use vendor AI carry the weight.
Decide role per system, because one team fine-tuning a model flips its A.6 and A.7 rows back to applicable.
ISO 42001 Statement of Applicability Example: Five Rows From an IT-Led AI Stack
This ISO 42001 Statement of Applicability example uses a mid-size company that deploys vendor AI and builds nothing in-house. Each justification names a system, a role and the evidence behind it.
The A.6.1.2 exclusion works because the inventory proves the claim. An exclusion is only as strong as your discovery.
For the A.10.3 row, our AI vendor security questionnaire covers the training data and sub-processor questions auditors expect answered. For a public reference, see SAP's published ISO 42001 SoA.
ISO 42001 Statement of Applicability Template: The Columns That Hold Up at Stage 1
A usable ISO 42001 Statement of Applicability template has eight columns: control ID, control name, decision, justification, linked risk, implementation status, evidence reference and owner. Version, date, and approver sit in a header block.
Build it in a spreadsheet and export each approved version as an ISO 42001 Statement of Applicability PDF for the certification body.
Here's the order that produces defensible rows:
- Inventory every AI system in scope: Include sanctioned tools, shadow AI, AI features inside existing SaaS, and agents with their connections.
- Record your role per system: Mark each as built, fine-tuned, or bought, because that drives most exclusions.
- Run the risk and impact assessments: Controls come out of these, with Annex A as the completeness check.
- Decide each of the 38 rows: Write the justification before the status.
- Assign owners and approve: Top management signs off, and the version number goes on your ISO 42001 Statement of Applicability PDF.
- Set review triggers: A new AI tool, a role change, or a new AI vendor reopens the affected rows.
Building the rest of your AIMS too? The ISO 42001 implementation checklist shows where the SoA sits before Stage 1.
What Your SoA Decides About Cost, Timeline and Your Certification Body
Your ISO 42001 Statement of Applicability and scope statement set the size of the audit, which drives cost and timeline. Certification bodies quote on scope and the number of AI systems inside it.
Cost
- Audit days scale with the scope your SoA describes.
- Readiness work often costs more than the audit when the inventory is built by hand.
- Rework after Stage 1 is the hidden cost, since weak justifications send rows back.
Timeline
- Stage 1 is a documentation review where the auditor reads your SoA and scope.
- Stage 2 samples the applicable rows and tests the evidence behind each one.
- Surveillance audits run each year of the three-year certificate cycle and check whether the SoA kept pace.
Choosing a certification body
- Accreditation: pick a body accredited for ISO 42001 by a recognized accreditor such as ANAB.
- AI audit competence: ISO/IEC 42006:2025 sets extra competence rules for bodies certifying AI management systems, so ask whether they audit to it.
- Deployer experience: ask how many companies using vendor AI they've certified.
Our guide to AI governance audit readiness covers what to have ready before Stage 2.
Why IT-Led SoAs Go Stale Between Audits
IT-led SoAs go stale because AI enters the company faster than anyone updates the document. An exclusion true in January becomes a misstatement by April.
Three things add in-scope systems without a ticket:
- Shadow AI: a tool bought on a card processes company data before IT knows it exists.
- AI inside existing SaaS: a support desk or CRM ships a model-backed feature, and your A.10 supplier row now describes a different service.
- Agents and connections: agents get wired into Slack, Drive or code repos with API tokens and no recorded owner. See our guide to AI agent discovery.
IBM's 2025 Cost of a Data Breach Report found 63% of breached organizations lacked AI governance policies, and 97% of those with an AI-related incident lacked proper AI access controls. Among organizations with a policy, only 34% audited regularly for unsanctioned AI.
A spreadsheet updated before each audit describes last quarter's AI estate, so your ISO 42001 Statement of Applicability needs continuous discovery behind its A.4 and A.9 rows.
How CloudEagle.ai Keeps Your SoA Evidence Current
An SoA goes stale when its evidence lives in spreadsheets that someone updates before each audit. CloudEagle.ai gives IT one place to discover, govern and review every AI tool and agent, so the rows in your ISO 42001 Statement of Applicability point to live records.
Every AI tool in your inventory, including the ones IT never approved
Your A.4.2 row claims the inventory is complete, but it only lists tools behind SSO. Browser sign-ups and IDE plugins never show up, so the auditor’s first sample can break the row.
How CloudEagle.ai solves it:
- Correlates seven discovery sources, including SSO, finance, browser and expense data, into one AI inventory.
- Maps each tool to a data-sensitivity tier and a GenAI risk score.
Your inventory matches what’s actually running, so exclusions like “no in-house development” hold up.
How Plex built an audit-ready AI inventory
- Challenge: Plex tracked 30 approved AI tools while others spread through browsers and personal accounts.
- What CloudEagle.ai did: discovered AI apps across SaaS, browsers and IDE plugins that SSO never saw.
- Result: 73 shadow AI tools surfaced, 22 retired, and a full inventory ready for internal audit in 14 days.
“CloudEagle found 73 shadow AI tools; that was the moment our AI governance program moved from a slide deck to a defensible control set the board could actually review.”
Scott Olechowski, Co-Founder and Chief Product Officer, Plex
A named owner on every AI tool and agent
Auditors ask who answers for each AI system, and for agents that teams set up themselves, nobody can say.
How CloudEagle.ai solves it:
- Discovers AI agents along with their owners and permissions.
- Brings API tokens and service accounts under the same governance as human users.
Every A.3.2 row names someone the auditor can talk to. Our post on AI governance ownership covers how to assign those decision rights.
Proof that employees use AI the way your policy says
A.9 asks whether real usage matches your policy. A signed policy document can’t show that, and auditors know it.
How CloudEagle.ai solves it:
- Enforces your AI usage policy template in the browser, redirecting users to approved tools or blocking sensitive data.
- Runs continuous access reviews on sanctioned AI apps and logs every decision.
Your A.9.2 evidence becomes enforcement logs and review records the auditor can sample.
Vendor evidence auditors can check in one place
A.10.3 decisions rest on vendor contracts, but DPAs sit with legal and questionnaires sit in email threads.
How CloudEagle.ai solves it:
- Centralizes each AI vendor with its DPA status, data tier, contract, and renewal date.
- Sends vendor questionnaires automatically and tracks responses.
Every supplier row points to one record. Plex used this view to block or renegotiate 18 AI tools handling regulated data without a signed DPA.
Your SoA Is Only as Defensible as Your AI Inventory
An ISO 42001 Statement of Applicability passes Stage 1 when every row traces back to a system you can show the auditor. For IT teams deploying vendor AI, three things decide that:
- A complete inventory: sanctioned tools, shadow AI, AI features inside SaaS and agents, all in one place.
- A role per system: so every development-control exclusion has proof behind it.
- Event-based reviews: new tools and vendors reopen the right rows between audits.
Get those right, and the SoA stops being a pre-audit scramble.
FAQs
Is ISO 42001 mandatory?
No law requires it. ISO 42001 is voluntary, though customers increasingly ask for it. See how it compares to NIST and the EU AI Act.
What is an ISO statement of applicability?
It's the document listing each control in a standard's Annex A, whether it applies to you and why. Auditors build their audit plan from it.
What does ISO 42001 require?
An AI management system covering clauses 4 to 10, AI risk and impact assessments, and an SoA justifying every control decision.
Can you provide an example of a Statement of Applicability (SoA) in ISO 27001?
An ISO 27001 SoA lists all 93 Annex A controls with a decision, justification, and implementation status for each, in the same format as ISO 42001.
Your ISO 42001 Statement of Applicability is only as accurate as your AI inventory. Book a demo to see how CloudEagle.ai keeps every SoA row backed by live evidence.
Walk Into Stage 1 Audit-Ready
.avif)
.avif)
.avif)
.png)
.png)
.png)
.avif)
.avif)
.avif)
