Your ISMS Was Built Before Your AI Was

If your organization added AI tools, models, or data pipelines after your last ISO/IEC 27001 risk assessment, your Information Security Management System (ISMS) may no longer describe how information actually moves through your business.

AI changes where data goes, who (or what) can access it, and what can be learned from it.

A customer record pasted into a public chatbot, a training dataset copied to a new cloud region, or a model that quietly memorizes sensitive inputs can each create risks your current Statement of Applicability never considered.

The good news: ISO/IEC 27001:2022 already gives you the framework to manage these risks. The Annex A controls you rely on today still apply.

They simply need to be interpreted, scoped, and evidenced with AI in mind. This guide shows you how.

Why Traditional Annex A Controls Fall Short

Most Annex A controls were written with conventional IT assets in mind: servers, applications, databases, and the people who use them. AI pipelines break several of the assumptions those controls quietly rely on.

• Data becomes part of the asset. Once training data shapes a model, the model itself can carry traces of that data. Deleting the source file does not necessarily remove the information.
• Inputs are instructions. In AI systems, user prompts and retrieved content can change system behavior, blurring the line between data and code.
• Usage spreads faster than governance. Employees can adopt AI tools in minutes, often outside procurement, IT review, or your asset inventory.
• Suppliers multiply. A single AI feature may depend on a model provider, a hosting platform, a vector database, and open-source components, each a link in your ICT supply chain.
• Data crosses borders by default. Inference and training workloads are often routed to wherever compute is available, not where your data residency commitments say it should stay.

None of this requires abandoning your ISMS. It requires revisiting your context (Clause 4), your risk assessment and treatment (Clause 6.1), and the controls you selected in your Statement of Applicability.

The AI Vulnerabilities Your Auditor Will Ask About

Shadow AI

Shadow AI is the use of AI tools, plugins, or models without the knowledge or approval of IT and security teams.

An employee who pastes source code, contract terms, or customer data into an unapproved chatbot has transferred information outside your controlled environment, often to a provider with no supplier agreement in place.

Shadow AI undermines your asset inventory, acceptable use rules, supplier controls, and information transfer controls at the same time. If it isn’t in your inventory, it isn’t in your risk assessment.

Model Inversion

Model inversion is an attack in which an adversary queries a trained model and uses its outputs to reconstruct sensitive information from the training data.

Related techniques, such as membership inference, can reveal whether a specific individual’s record was used to train the model.

This means a model can leak confidential or personal data even when the underlying database is fully locked down.

Your access controls, data masking, and privacy controls must extend to the model and its outputs, not just the data store.

AI Risk to Annex A Control Mapping

The breakdown below maps common AI risks to the ISO/IEC 27001:2022 Annex A controls they affect, and shows how each control’s implementation should evolve.

Use it as a starting point for updating your risk assessment and Statement of Applicability; your final control selection should always follow your own risk treatment decisions.

Shadow AI

The risk: Employees use unapproved AI tools that move company data outside your controlled environment.

Annex A controls:

• 9 Inventory of information and other associated assets
• 10 Acceptable use
• 19 Information security in supplier relationships
• 3 Awareness, education and training

Traditional focus: Inventory of approved hardware, software, and data

What needs to change:

• Discover and inventory AI tools, plugins, and APIs in use
• Publish an AI acceptable use policy
• Route AI services through supplier review
• Train staff on what data may enter AI tools

Model inversion and membership inference

The risk: Attackers query a trained model to reconstruct sensitive training data or confirm whose records were used.

Annex A controls:

• 11 Data masking
• 34 Privacy and protection of PII
• 3 Information access restriction

Traditional focus: Restricting access to stored records

What needs to change:

• Treat trained models as assets that may contain sensitive data
• Minimize, de-identify, or mask PII before training
• Restrict and rate-limit model query access
• Test models for data leakage

Data leakage through prompts and outputs

The risk: Sensitive data entered into prompts, or returned in model outputs, reaches people or providers who should not see it.

Annex A controls:

• 12 Data leakage prevention
• 12 Classification of information
• 14 Information transfer

Traditional focus: Monitoring email, file transfers, and removable media

What needs to change:

• Extend DLP to AI prompts, uploads, and responses
• Define which classification levels may be used with which AI tools
• Filter outputs for sensitive content

Prompt injection

The risk: Malicious instructions hidden in user input or retrieved documents cause the AI system to ignore its rules, expose data, or take unintended actions.

Annex A controls:

• 26 Application security requirements
• 28 Secure coding
• 29 Security testing in development and acceptance

Traditional focus: Input validation for conventional applications

What needs to change:

• Treat all prompts and retrieved content as untrusted input
• Limit what actions AI agents can take
• Include adversarial prompt testing before release

Training data poisoning

The risk: Tampered or low-quality data introduced into training or fine-tuning sets skews model behavior.

Annex A controls:

• 25 Secure development life cycle
• 32 Change management
• 33 Test information

Traditional focus: Protecting source code and test data

What needs to change:

• Verify the source and integrity of training and fine-tuning data
• Version-control datasets
• Require approval for changes to data and models

AI supply chain compromise

The risk: Third-party models, open-source weights, and libraries introduce vulnerabilities you didn’t build and may not be able to inspect.

Annex A controls:

• 21 Managing information security in the ICT supply chain
• 20 Addressing information security within supplier agreements
• 8 Management of technical vulnerabilities

Traditional focus: Vetting software vendors and patching

What needs to change:

• Assess third-party model providers and open-source models
• Add AI-specific terms (data use, retention, training on your data) to contracts
• Track vulnerabilities in AI frameworks and libraries

Model theft and extraction

The risk: Attackers copy a proprietary model, or approximate it through repeated queries, exposing valuable intellectual property.

Annex A controls:

• 2 Privileged access rights
• 5 Secure authentication
• 24 Use of cryptography

Traditional focus: Protecting systems and credentials

What needs to change:

• Protect model weights as high-value assets
• Encrypt models at rest and in transit
• Monitor for unusual query volumes that suggest extraction

Undetected AI misuse

The risk: Without AI-specific logging and monitoring, misuse of AI tools, prompts, or agents can go unnoticed.

Annex A controls:

• 15 Logging
• 16 Monitoring activities
• 7 Threat intelligence

Traditional focus: Logging system and user activity

What needs to change:

• Log AI prompts, outputs, and agent actions where lawful
• Monitor for anomalous AI behavior
• Follow emerging AI threat intelligence

Uncontrolled cross-border processing

The risk: AI training, inference, and logging run in regions that may conflict with your data residency and transfer obligations.

Annex A controls:

• 23 Information security for use of cloud services
• 31 Legal, statutory, regulatory and contractual requirements
• 34 Privacy and protection of PII

Traditional focus: Selecting cloud providers and regions

What needs to change:

• Confirm where training, inference, and logging occur
• Align AI data flows with residency and transfer obligations in every jurisdiction you operate in

Organizations that need to govern AI more broadly, including fairness, transparency, and accountability, can pair ISO/IEC 27001 with ISO/IEC 42001, the international standard for AI management systems.

One Mapping, Any Jurisdiction

ISO/IEC 27001 is an international standard, and that makes this mapping portable.

Whether your AI workloads run in a single cloud region or span providers across North America, Europe, and Asia-Pacific, the same Annex A controls apply.

That consistency matters for international compliance teams. Cross-border cloud architectures often involve data collected in one country, models trained in another, and inference served globally.

Each hop is an information transfer, a supplier relationship, and potentially a new set of legal obligations.

By anchoring AI risk to Annex A, your team can:

• Apply one control framework across every region, rather than maintaining separate approaches for each market
• Map local privacy and data protection requirements into a single, auditable set of controls through 5.31 and 5.34
• Demonstrate to customers, partners, and regulators worldwide that AI risk is managed within an accredited, internationally recognized management system
• Scale AI adoption into new markets without rebuilding your security program each time

Your AI-Ready ISMS Checklist

• Update your context and interested parties (Clauses 4.1 and 4.2) to reflect how your organization develops, provides, or uses AI
• Discover and add AI tools, models, datasets, and APIs to your asset inventory
• Rerun your risk assessment with AI-specific threats, including Shadow AI and model inversion
• Revisit your Statement of Applicability and document how selected controls apply to AI
• Publish an AI acceptable use policy and train employees on it
• Review AI suppliers and update contracts with data use and retention terms
• Map where AI training, inference, and logs are processed across regions
• Include AI systems in your internal audit program and management review

Certify with Confidence

Perry Johnson Registrars, Inc. (PJR) provides accredited ISO/IEC 27001 certification for organizations around the world.

Our auditors understand how modern cloud and AI environments affect your ISMS, and our certification gives your customers independent assurance that your information security, including your AI pipeline, is managed to an internationally recognized standard.

PJR also offers ISO/IEC 42001 certification for organizations ready to demonstrate responsible AI governance alongside information security.