ISO 27001:2022 Clause 4.3 Determining The Scope Of The Information Security Management System for AI Companies

ISO 27001 Clause 4.3 is the foundational requirement for Determining the Scope of the Information Security Management System (ISMS). For AI companies, this clause acts as the Primary Implementation Requirement to define exactly which AI models, data pipelines, and infrastructure are covered, providing the Business Benefit of a clear certification boundary that satisfies enterprise clients and regulatory bodies like the EU AI Act.

For an AI company, information security is not merely a technical function; it is the bedrock of your valuation. You are handling vast sets of sensitive training data, protecting proprietary algorithms, and processing client prompts. In this environment, achieving ISO 27001 certification transcends a simple compliance checkbox. It is a critical tool for demonstrating security maturity, building enduring client trust, and forging a significant competitive advantage.

The foundational step on the path to certification is to correctly define the “scope” of your Information Security Management System (ISMS). This initial decision dictates the boundaries of your entire security programme. This guide provides a clear, step-by-step process for defining ISO 27001 Clause 4.3 for AI companies, tailored specifically to navigate the unique challenges of the artificial intelligence industry.

The Business Case: Why This Actually Matters for AI Companies

Let’s kill the “compliance is boring” mindset. Clause 4.3 is about revenue.

The Sales Angle

When you sell to a Bank or a Fortune 500 company, their procurement team will check your ISO 27001 certificate. They will look immediately at the Scope Statement. If your scope says “Corporate IT and HR” but you are selling them an “AI Inference API,” they will reject your certificate. They need assurance on the product they are buying, not your HR department.

The Risk Angle

Defining your scope prevents “Shadow AI.” By explicitly stating that your scope includes “All Model Training Environments,” you force the organisation to bring rogue GPU clusters and personal Hugging Face accounts under management. This prevents the nightmare scenario of a developer accidentally leaking model weights to a public repository.

The “No-BS” Translation: Decoding the Requirement

The standard uses academic language. Here is what it actually means for a modern AI company running on cloud infrastructure.

ISO 27001 Term	Translation for AI Companies
“Boundaries and applicability”	Draw a line around your AWS/GCP accounts. Everything inside is your problem. Everything outside (e.g., your cleaner’s phone) is not.
“Interfaces and dependencies”	How does data get from your customer to your model? APIs, S3 buckets, and private links.
“Internal and external issues”	Your investors want you to move fast; the EU AI Act wants you to slow down. Your scope must balance this.

Regulatory Context: DORA, NIS2 and the EU AI Act

Your Scope Statement (Clause 4.3) is the foundation for the new wave of AI regulation.

• EU AI Act: This regulation applies to “High-Risk AI Systems.” Your ISO 27001 scope is the document where you formally define which of your systems fall into this category.
• DORA: If you are a critical third-party provider to financial firms, DORA requires you to map your “ICT Assets.” This mapping begins with your ISO 27001 scope.
• NIS2: As part of the supply chain, you must secure the “network and information systems” used to provide your service. Clause 4.3 is where you list those systems.

Toolkit vs. SaaS: Why Ownership is Better Than Renting

There is a trend of AI companies buying expensive SaaS platforms to “automate” scoping. This is often a mistake. You need to own your scope, not rent it.

Feature	ISO 27001 Toolkit	Online SaaS Platform
Ownership	100% Yours. You keep the files forever.	Rented. If you stop paying, you lose your certification evidence.
Cost	One-off fee. Low impact on burn rate.	Expensive monthly subscription (£10k-£20k/year).
Simplicity	Everyone knows how to use Word. No training needed.	Requires training your team on complex new software.
Freedom	No vendor lock-in. Move files anywhere.	Complete lock-in. Hard to export data if you leave.
Accuracy	You define the scope precisely.	Automated scanners often create a scope that is too broad (“boiling the ocean”).

For a fast-moving AI company, the ISO 27001 Toolkit offers the speed and control you need without the monthly tax.

Demystifying ISO 27001 Clause 4.3: What is “Scope”?

Before diving into the ‘how’ of scoping, it is essential to understand the ‘what’. The purpose of this clause is to ensure your ISMS has a clear and well-defined boundary.

This clarity is crucial as it formally establishes:

• Which parts of your AI infrastructure are included (e.g., Training vs Inference).
• The boundaries of your certification (e.g., covering the London office but excluding the remote team in Bali).

The High Stakes: Analysing the Impact of Scoping Decisions

Defining the scope is arguably the single most significant decision in the ISO 27001 journey. As we say in the industry, “Getting the Scope wrong is the single most expensive mistake you can make.”

For an AI company, the impact of an incorrect scope can be severe. If the scope fails to meet customer requirements by excluding the cloud infrastructure where your machine learning pipelines are executed, the entire certification may be worthless. Conversely, if the scope is too broad, you apply rigorous controls to non-critical areas, diverting engineering resources from innovation.

The Implementation Blueprint: A Step-by-Step Guide to Defining Your ISMS Scope

A methodical, structured approach is the key to effective scoping. Here is a comprehensive, sequential guide tailored for AI companies.

1. Define Organisational Boundaries: Clearly identify your structure. Does the scope include the Data Science subsidiary? What about the offshore labelling team?
2. List All Products and Services: Document every AI product, from the core “Inference API” to the “Fine-tuning Service.”
3. Consult Your Customers: Review your Enterprise contracts. What did you promise the bank? If you promised to secure “data processing,” your scope must cover the entire ML pipeline.
4. Consult Your Leadership: Ensure the scope aligns with the roadmap. If you are launching a new “Private Cloud” deployment next quarter, include it now to avoid re-auditing later.
5. Consult Interested Parties: Check with regulators. Does the EU AI Act require you to include your model registry in the scope? (Hint: Yes).
6. Document In-Scope Services: Create a formal list. e.g., “The development and operation of the Generative AI Platform.”
7. Review Internal and External Issues: Cross-reference with Clause 4.1. If “Supply Chain Attack” is a key issue, your scope must include your dependencies (e.g., Hugging Face, OpenAI).
8. Confirm the List: Get the CTO to sign off. This prevents arguments later about why the “Research Sandbox” is subject to strict access control.
9. Identify Supporting Functions: Which teams support the AI product? DevOps, MLOps, HR, and Legal are usually critical.
10. Determine Scope Exclusions: Explicitly exclude things you don’t control. You cannot secure the customer’s on-premise firewall. Document this exclusion.
11. Document Scope Boundaries: Define the “Logical Perimeter.” Usually, this is your cloud organisation (AWS/GCP/Azure) and your code repositories (GitHub/GitLab).
12. Write Your Scope Statement: Summarise this into a clear, concise paragraph. This is what goes on the certificate.
13. Communicate to Stakeholders: Tell the engineers. They need to know that the “Production” project is in scope, but their “Personal Playground” might be out (if separated correctly).
14. Obtain Management Approval: You must secure formal approval from top management. The auditor will ask for this email or meeting minute.
15. Verify with Certification Body: Send your draft scope to your auditor before the audit. It saves costly misunderstandings.

Crafting the Official Scope Statement

The scope statement is the official, documented summary of your ISMS boundaries. It is the public-facing declaration that appears on your ISO 27001 certificate and is the first document an auditor will scrutinise.

Practical, Real-World Example

For an AI SaaS company, your scope statement might look like this:

“The information security management system supporting the development, operation, and maintenance of the [AI Product Name] platform, including the processing of customer training data and the serving of model inference APIs, in accordance with the Statement of Applicability version 2.1.”

The Evidence Locker: What the Auditor Needs to See

When I show up for your audit, I want to see these exact artifacts in your “Clause 4.3” folder:

• The Scope Document (PDF): A 1-2 page document signed by the CTO.
• Network Architecture Diagram: A diagram showing your VPCs, Subnets, and where the data flows. Circle the “In-Scope” area in red.
  
  
  
  [Image of Network Architecture Diagram]
  
  
• Asset Inventory Export: A list of the AWS accounts or GPU clusters that fall within the scope.
• Management Meeting Minutes: Evidence that the scope was discussed and approved.

Handling Exceptions: The “Break Glass” Protocol

Sometimes you need to operate outside the scope during an emergency (e.g., spinning up a new region to handle a traffic spike before it’s fully secured). You need a protocol for this.

The Protocol:

1. Identify Deviation: “We are using a new GPU provider not listed in the scope.”
2. Risk Assessment: CTO assesses the risk. “Low risk if no customer data is used.”
3. Temporary Approval: Approve the deviation for 30 days via a Linear ticket.
4. Remediation: Bring the new provider into scope (add controls) or decommission it before the 30 days are up.

The Process Layer: The Standard Operating Procedure (SOP)

How do you manage the scope day-to-day? Here is the SOP for an AI company.

Scope Review Cycle

1. Trigger: Annual review or Major Change (e.g., Merger, New Product Launch).
2. Review: CTO and Head of Security review the current Scope Statement against the new architecture.
3. Update: If the boundaries have changed (e.g., we added Azure), update the document.
4. Notify: Inform the Certification Body if the change is significant (they may need to adjust your audit days).

Avoiding Common Pitfalls: Top 3 Scoping Mistakes

Even with a clear process, there are common traps AI companies fall into.

1. Defining an Overly Broad Scope (Boiling the Ocean)

The Problem: You include “All Operations” in the scope. Now the auditor wants to check the CCTV in your WeWork office or the security of your Marketing team’s Instagram account.

The Solution: Laser focus. Scope only the “Development and Operation of the AI Platform.” Exclude everything else.

2. Neglecting Client Expectations

The Problem: You scope for “Consultancy Services” to make the audit easy. But your client is buying your “SaaS Platform.” The certificate you hand them is useless.

The Solution: Check your biggest contracts. Ensure the scope matches the service description in the MSA.

3. The “Shadow AI” Gap (SaaS Error)

The Problem: You used a SaaS tool to scan your AWS account, so you think your scope is perfect. But your data scientists are downloading data to their local MacBooks to run experiments. The SaaS tool didn’t see that, but the auditor will.

The Solution: Scoping is a human interview process, not just an API scan. You must account for where the data actually goes, not just where the server is.

Passing the Audit: What Your Auditor Wants to See

Ultimately, all your preparation culminates in the external audit. Here is exactly what the auditor will check:

• A Documented Scope: A physical PDF or Docx file. Not a screenshot from a SaaS portal.
• Alignment with Clause 4.1: Does the scope address the risks you identified? (e.g., if you listed “EU AI Act” as an issue, is the relevant AI system in scope?)
• Management Approval: A signature or email confirmation from the C-Suite.

Frequently Asked Questions (FAQ)

About the author