ISO 27090 AI security guidance with ISO 42001

Does ISO 27090 AI security guidance change what ISO 42001 requires?

ISO/IEC 27090:2026 is guidance, not a certifiable management system standard, and ISO/IEC 42001 certification is issued only by an accredited certification body. A customer or regulator asking for AI governance and AI security evidence is usually asking for two different things: a management system that can be audited, and technical proof that the AI system resists specific attacks. ISO 42001 supplies the first. ISO/IEC 27090:2026, edition 1, 56 pages, published 14 October 2026, is guidance on identifying, detecting and reducing AI-specific security threats across the life cycle, such as data poisoning and model theft. Organizations own their controls and their evidence, and the certification body decides whether the management system conforms.

Whether the requirements change depends on how the organization builds, hosts and exposes its AI systems. ISO 42001 does not list attack types, but several of its Annex A controls need security-relevant evidence. A.6.2.4 asks for documented verification and validation measures and the criteria for using them. A.6.2.6 asks for documented operational arrangements covering monitoring, repairs, updates and support. A.10.3 asks for a process that checks suppliers' products and services against the organization's responsible AI approach. Guidance such as 27090 can inform what those measures test, for example whether a model is probed for poisoning or extraction before release. Confirm with your certification body how it expects that scope to be documented in your statement of applicability.

Practical next steps: list every AI system that is internally built, fine-tuned, self-hosted or exposed through an API, and record which 27090 threat areas apply to each. For systems that expose a language model, plan security testing that produces repeatable reports, such as the open-source probing tool garak, whose project README describes its JSONL attempt and hit logs. Treat those test results as input to the A.6.2.4 and A.6.2.6 evidence, not as proof of compliance. When buying help, ask whether the partner prepares evidence and test records only, and confirm with the certification body which outputs it will accept.

Which ISO 42001 controls AI security threats touch

ISO/IEC 27090 describes AI-specific threats such as data poisoning and model theft, but it does not create certifiable controls of its own. The threats below land on Annex A controls that an ISO 42001 management system already requires, so the evidence for each one is kept inside that system and tested by the certification body's auditor.

Verification and validation criteria

Under A.6.2.4, the organization defines and documents the verification and validation measures for each AI system and states the criteria that decide when those measures are used. For AI security, this is where adversarial testing, robustness checks and tests for poisoned or drifted training data get written down as required steps, not left to individual engineers. Check that the criteria name the threats being tested and that a failed test blocks release. The organization owns the criteria, a partner can help build the test suite, and the auditor samples test records to confirm they were run.

Operational monitoring and updates

Under A.6.2.6, the organization documents what the AI system needs to keep running, including system and performance monitoring, repairs, updates and support. For AI security, this is where drift, unexpected output patterns, abnormal query volumes that suggest model extraction, and the process for patching or retraining a compromised model are defined. Check that alert thresholds and an owner for each alert are recorded. The organization runs the monitoring, a partner can configure the telemetry and runbooks, and the auditor reviews monitoring logs and change records.

Supplier alignment for AI components

Under A.10.3, the organization sets up a process so that services, products and materials from suppliers match its approach to responsible AI development and use. For AI security, this covers pre-trained models, datasets, plug-ins and hosted inference APIs that may carry poisoned weights, undisclosed data sources or weak access controls. Check that suppliers must disclose provenance, model versions and security testing results before onboarding. The organization decides the acceptance criteria, legal and procurement teams handle contracts, and the auditor checks the supplier assessment records.

Data controls against poisoning

The data controls in A.7 cover how training, validation and tuning data is managed, acquired, checked for quality, traced to its source and prepared. Against data poisoning, these controls matter because a tampered dataset can change model behavior without any visible code change. Check that each dataset has recorded provenance, integrity checks such as hashing and access logs, and a documented rule for rejecting data that fails quality review. The organization maintains these records, a partner can implement the pipeline checks, and the auditor tests a sample of datasets back to their source.

How ISO 27001 and ISO 42001 relate to 27090 in practice

Security leads usually work from ISO/IEC 27001:2022, the certifiable information security management standard, and treat it as the base of their program. ISO/IEC 27090:2026 is guidance rather than a certification standard. It helps the security team identify and reduce AI-specific threats such as data poisoning and model theft across the life cycle, and it gives them vocabulary to add AI threats to existing risk registers. ISO/IEC 42001 applies the harmonized structure, so the security team's risk, competence and internal audit processes can be reused rather than duplicated.

Certifiable base: ISO/IEC 27001:2022 is a separate certifiable standard with its own certification body process.
Guidance layer: ISO/IEC 27090:2026 adds AI threat identification, detection and reduction guidance.
Shared structure: The ISO/IEC 42001 introduction describes the harmonized structure so the security management system can be implemented consistently with it.
Testing evidence: Adversarial testing results, such as those from garak probes for language models, feed the verification evidence.
Scope boundary: Confirm with the certification body whether AI systems fall inside the ISO/IEC 27001 scope statement.

Check that your ISO/IEC 27001 risk assessment names AI-specific threats and links them to the controls you claim.

How AI security testing produces evidence for auditors

Security testing is a way to generate evidence for the verification and validation and the operation controls in ISO/IEC 42001, not a certificate and not a substitute for them. Under A.6.2.4, the organization must define and document its verification and validation measures for the AI system and the criteria for using them, and under A.6.2.6 it must document how the system is monitored, repaired, updated and supported. Testing supplies records that show those measures were carried out. An independent certification body still decides whether the evidence meets the standard, and the organization owns the decision about what the tests must prove before a release or a change goes live.

The evidence an auditor usually asks to see has four parts: a test plan that states scope and the threats covered, such as data poisoning, model theft and prompt injection as described in ISO/IEC 27090:2026; results from each run; remediation records that show who fixed each finding and when; and retest records that confirm the fix worked. For language models, garak (Apache-2.0) is one open-source option. Its garak README describes probes for hallucination, data leakage, prompt injection, misinformation, toxicity generation and jailbreaks. It writes a JSONL report of every attempt and evaluation and a separate hit log of attempts that found a vulnerability. Confirm the current probe set and report format against the project before you build a test plan around it.

Tool output alone is not sufficient evidence. Before the first run, the organization must set acceptance criteria, such as which hit-log findings block deployment, which are accepted with a documented risk decision, and who signs that decision. Without those criteria, a long report shows activity but not control. Keep the test configuration, model version and dataset with each run so a reviewer can reproduce it, and tie findings to the risk register and the statement of applicability. An implementation partner can help set up the tests and the record keeping, but the accountable owner must accept the criteria and the residual risk.

How to fold 27090 guidance into an ISO 42001 program

The sequence below turns the threat guidance in ISO/IEC 27090 into the scope, controls, test records and supplier evidence an ISO 42001 program needs, with each phase closing on a named output the organization owns and an independent auditor can test.

Scope the AI systems and their threats
Start by listing every AI system in scope of the AI management system, including systems built in-house, bought from suppliers and used under a vendor contract. For each one, record its purpose, its data sources, its model and hosting location, and the threat categories ISO/IEC 27090 describes for the life cycle, such as data poisoning and model theft. The organization's governance owner signs off the list. The step is done when every in-scope system has a documented threat entry that names an accountable owner.
Map existing ISO 27001 controls to AI threats
Compare each threat entry with the controls already in place under the organization's ISO/IEC 27001 information security management system, such as access control, logging, change management, vulnerability management and supplier security. Mark where an existing control covers the AI threat, where it covers it only partly and where nothing applies. The output is a mapping table that the security and AI teams both review. Gaps become inputs for the statement of applicability in a later step.
Define verification, validation and monitoring criteria
Under Annex A control A.6.2.4, document the verification and validation measures for each AI system and the criteria that decide when each measure is used. Under A.6.2.6, document what ongoing operation requires, including system and performance monitoring, repairs, updates and support. Security-relevant signals, such as unexpected drift in outputs or unusual query patterns, should be named as monitoring criteria with a stated response. The step closes when each system has written criteria and a named owner for each one.
Run AI security testing and record results
Test each in-scope system against the threats it was mapped to, using a defined test plan. For language models, open-source probes such as garak can test for prompt injection, data leakage, jailbreaks and related weaknesses, and produce a JSONL report of every attempt plus a hit log of successful attempts. Record the test scope, the version of each system tested, the findings and the remediation decisions. Confirm the capabilities of any tool before relying on it, since coverage varies. The step is done when each finding has a recorded disposition and a retest result.
Document supplier controls for AI components
Under Annex A control A.10.3, establish and document how AI products, models, datasets and services obtained from suppliers are checked against the organization's approach to responsible development and use. Record the security questions asked, the evidence requested (for example, supplier security attestations or test results), and how changes in a supplier's model or hosting are notified and reviewed. The organization decides which suppliers meet its bar. The step closes with a supplier register that links each AI component to its evidence.
Prepare the statement of applicability
Under clause 6.1.3, list the Annex A controls the organization needs, and for each one either justify its inclusion with a reference to the evidence above or justify its exclusion. Controls tied to the threat work, including the verification, validation, operation and supplier controls, should point to the scope, mapping, test and supplier records already produced. The statement is approved by management and reviewed when the AI systems or threats change. The step is done when every Annex A control has a recorded decision and a link to its evidence.
Hand the evidence to an independent auditor
Confirm with the certification body which evidence it will sample, and assemble the threat register, mapping table, criteria documents, test reports, supplier register and statement of applicability in one controlled location. The organization owns every decision in these records, and an implementation partner can help prepare them, but only the independent certification body assesses conformity and issues any certificate. The step is complete when the auditor has the evidence set and the organization can explain each decision in it.

Who owns each part of AI security evidence

ISO/IEC 27090 guidance and the ISO/IEC 42001 controls generate security evidence that several parties produce. Each party has a distinct role, and none of them can substitute for another when an assessor asks who made a decision or who tested a claim.

The organization

The organization owns its AI controls, its risk decisions and its statement of applability under clause 6.1.3 of ISO/IEC 42001, including the justification for each Annex A control it includes or excludes. Security threats such as data poisoning and model theft are business risks, so accepting, reducing or transferring them is a management decision that must be documented and signed by someone accountable. Check that the named owner can explain why each exclusion is acceptable.

The implementation partner

An implementation partner such as DeployOpen prepares the systems, controls and evidence that the organization relies on, and runs security testing within the written scope of an engagement. This includes configuring logging for model inputs and outputs, building test harnesses and recording results. The partner does not decide what risk is acceptable and does not issue reports or certificates. Confirm in the statement of work exactly which artifacts the partner delivers and who keeps them afterward.

The internal security team

The internal security team operates monitoring, alert triage and incident response for AI systems after go-live, which covers the ongoing operation activities described in A.6.2.6. Its records of alerts, investigations and corrective actions are often the strongest evidence that controls work in practice. Ask whether the team has runbooks for model misuse, data leakage and suspected poisoning, and whether those runbooks have been exercised against a realistic test rather than only written down.

The independent auditor or certification body

An independent certification body or auditor tests the AI management system against ISO/IEC 42001 and decides whether a certificate can be issued. Certification bodies are external to the organization and to its implementation partner, and accreditation of those bodies is voluntary. ISO/IEC 42006:2025 sets additional requirements for bodies certifying AI management systems. Ask the prospective body how it will sample AI security evidence and whether its accreditation covers this scope.

Questions buyers ask about ISO 27090 and ISO 42001

Is ISO 27090 certifiable?

No. ISO/IEC 27090:2026 is a guidance standard on identifying, detecting and reducing security threats to AI systems, such as data poisoning and model theft, across the life cycle. It sets out what to consider, not requirements an auditor can certify against. The certificate that matters for AI governance is ISO/IEC 42001, which is certified by an accredited external certification body, not by ISO itself. Before relying on 27090 in a customer or contract conversation, confirm with the certification body and your customer how they expect it to be referenced, since guidance standards are often cited as a basis for controls rather than assessed directly.

Do we need ISO 27090 to get ISO 42001 certified?

No. ISO/IEC 42001 is the certifiable management system standard, and it does not require ISO/IEC 27090 as a precondition. Its Annex A controls are reference objectives that you select through a statement of applicability, and several of them, including the verification and validation control A.6.2.4 and the operation and monitoring control A.6.2.6, touch the same ground as AI security work. Using 27090 as a reference for how you identify and treat AI-specific threats can make those controls easier to evidence, but whether it fits your management system is a decision for your organization and your certification body.

Does security testing count as audit evidence?

Testing produces evidence, but the auditor decides whether it satisfies a control. A test report can support verification and validation under A.6.2.4, monitoring and repair records under A.6.2.6, and supplier assessment under A.10.3 when it shows what was tested, against which criteria, by whom and what happened next. Tools such as garak, an Apache-2.0 probe framework for language models, write JSONL reports of every attempt and a hit log of vulnerabilities found, which can be retained as raw material. Confirm with your auditor which test scope, frequency and retention they will accept.

What does the work need from our team?

Your team owns the AI systems, the risk decisions, the acceptance of residual risk and the final statement of applicability. An implementation partner can prepare test plans, run security testing, configure logging and monitoring, and organize evidence, but it cannot decide what your organization accepts. Expect named owners for each AI system, access to model and data pipeline documentation, engineers who can answer questions about training and deployment, and someone accountable for the management review. The amount of time depends on the number of systems in scope, so ask for the effort assumptions in any written scope.

Can an implementation partner certify us?

No. Only an accredited certification body can issue an ISO/IEC 42001 certificate, and ISO itself does not certify organizations. ISO/IEC 42006:2025 sets additional requirements for bodies certifying AI management systems, on top of ISO/IEC 17021-1. Accreditation of those bodies is voluntary, and as of the Global ACI-FMRA-001 version 3.3 status document, ISO/IEC 42001 is not listed as an endorsed sub-scope of the Global ACI recognition arrangement. Ask any certification body whether its accreditation covers ISO/IEC 42001 before you sign. A partner that prepares your evidence must remain independent of the body that audits it.

How does it relate to our ISO 27001 scope?

ISO/IEC 42001 and ISO/IEC 27001:2022 share a harmonized structure with the same clause numbers and common terms, so the management system clauses can be integrated. The scopes still differ. ISO 27001 covers the information security management system for the organization or a defined part of it, while ISO 42001 covers AI systems and their life cycle. Where AI systems hold or process information assets, both standards will rely on the same access control, logging and supplier records. Ask your certification body whether an integrated audit is available and how it will set boundaries between the two scopes.

What to confirm with your auditor before scoping

Before you decide how far ISO/IEC 27090 guidance shapes your AI security evidence, confirm how your certification body will judge that evidence. Certification bodies certifying AI management systems work under ISO/IEC 42006:2025, which sets requirements on top of ISO/IEC 17021-1, and those requirements govern how an auditor plans, samples and reports. ISO/IEC 27090 is guidance, not a certifiable standard, so an auditor will test your AI security controls against the ISO/IEC 42001 requirements and Annex A controls you have declared in your statement of applicability, not against 27090 directly. Ask the certification body in writing which evidence it will accept for threats such as data poisoning and model theft, and whether it expects that evidence to come from a 27090-informed threat assessment.

Accreditation scope is the second point to check. As of Global ACI-FMRA-001 version 3.3, ISO/IEC 42001 is not listed as an endorsed sub-scope under the Global ACI recognition arrangement, which ISO/IEC 27001 with ISO/IEC 27006-1 does have. Ask the certification body whether its accreditation covers ISO/IEC 42001 for your scope and which accreditation body issued it, then confirm that the accreditation statement names the standard you are being audited against. If you also hold or plan ISO/IEC 27001 certification, ask how the body audits an integrated management system, since the Global ACI guidance on integrated audits under ISO/IEC 17021-1 may shape how security evidence is shared between the two audits.

Finally, confirm the scope boundary for the security testing that produces your evidence. Ask whether the auditor will accept testing performed by an independent party, which tools and test reports must be retained, and how verification and validation records under A.6.2.4 and monitoring records under A.6.2.6 will be sampled. Get these answers before you commit to a test plan, because a test whose results the auditor will not accept as evidence is effort that does not count toward certification. Record the answers in your scoping document with the date and the name of the person who gave them.

How DeployOpen prepares AI security evidence for an ISO 42001 audit

DeployOpen works on ISO 27090 AI security guidance alongside ISO 42001 as an implementation partner. We prepare the systems, security testing and documented evidence that your organization's controls depend on, while the organization owns those controls and an independent certification body issues any certificate.

How we scope

Engagements are fixed-scope, with the AI systems, life cycle stages and Annex A controls agreed in writing before work starts.
The written scope names which AI security threats, such as data poisoning and model theft, are in and out of testing.
Scope records which A.6.2.4 verification and validation and A.6.2.6 operation controls the work prepares evidence for.

How we build

We deploy and harden self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks.
We configure monitoring, logging and update procedures so the operating evidence for A.6.2.6 can be produced on request.
We run AI security testing with tools such as garak against language models in scope, and record the results against the agreed criteria.

How we hand over

You receive written deliverables covering configurations, test plans, test results, and the evidence mapped to each in-scope control.
Documentation explains what each artifact shows, so your staff can answer assessor questions without relying on us.
Your internal owners approve the statement of applicability and keep accountability for AI governance decisions.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer, agreed separately from the initial scope.
Retainers can cover re-running AI security tests after model, data or supplier changes, and refreshing evidence before audits.
Confirm with your certification body which evidence formats and sampling it expects before finalizing the handover package.

ISO 27090 AI security guidance alongside ISO 42001