Decide What the Management System Covers Before You Commit to ISO 42001

The scope gets written by whoever fills in the form

The request arrives from outside. A customer's security review asks whether your AI management system is certified. A board member reads something over a weekend and asks whether the company is covered. Procurement at a large account puts it on a renewal checklist. Each of those asks stops short of naming a system, which is the first problem, because the answer has to name one.

So the work starts, and it starts as an application to a certification body, with a stage 1 readiness review waiting a few weeks out. Somebody assembles the documents and one of them wants a scope. Writing it takes an afternoon, drafted against what can be described quickly and what already has an owner. What describes quickly is the sanctioned assistant and the one internal model project that went through architecture review.

By the time anyone senior reads that sentence it has been through three drafts, a planning conversation and a set of slides. It reads as settled, and reopening it looks like the program going backwards. The default gets chosen in a handful of ways, and each of them has a reason behind it.

• The systems that already have a named owner, because a system with an owner is a system you can write a sentence about
• The legal entity that happens to hold the customer contract, whether or not the AI systems sit inside it
• The business unit whose head asked for the certificate, drawn as the boundary because that is who is funding the work
• Whatever the existing certified management system already covers, extended sideways, because the paperwork is familiar
• Everything, because narrowing it felt like an admission

The scope statement is the sentence a customer reads

A certificate gets read by people outside the program. What reaches them is the certificate and the boundary written on it, and they are checking one thing: whether the system they are worried about sits inside it.

That reader arrives with a specific system in mind. The model behind a feature they depend on, or the scoring that decides something about their own customers. They hold the scope line against that system. Where the line describes a different part of your organization, the certificate answers a different question from the one they brought, and the questionnaire it was meant to close out arrives anyway with an extra item at the top.

So the test for a scope statement runs outside your building. Read it as somebody with a contract at stake and work out what they would still want to know.

• Whether the AI system they depend on is named, or clearly inside the boundary as described
• Whether the boundary is drawn around systems, around organizational units, or around locations, and which of those their concern falls into
• Whether the team that builds the system and the team that operates it are both inside
• What the wording leaves out, because an experienced reviewer reads a scope for its edges

A reviewer arrives holding one system in mind and lays your scope line against it. That is the whole of the test.

What the standard fixes, and what it leaves to you

ISO/IEC 42001 is a management system standard for AI, and it is certifiable, which is what gives the scope decision its consequences. It carries a set of Annex A controls, and certification requires a defined scope for the management system.

Beside the scope statement sits the Statement of Applicability. It records every control the organization has determined it needs, including any it adds beyond Annex A, with a justification for each control included and for each Annex A control excluded, and a customer's reviewer reads the two together.

That a boundary has to exist and has to be written down is settled by the standard. What sits inside it is yours to decide, and that is the part being made by default. A boundary is built from a small number of dimensions, and a scope that settles only one of them gets tested on the others.

• Which AI systems, named one by one, so the boundary can be checked against a system somebody cares about
• Which parts of the organization, by legal entity and by function, including the teams that build and the teams that operate
• Which locations, and the infrastructure the systems run on
• What you do in relation to those systems: what you build, what you operate, and what you buy and put in front of people
• Where your boundary meets work performed by other organizations, because a model reached through a supplier's service still sits inside a process you own

What has to be true of a system before it belongs inside

Widening the boundary is the reflex, because a wider boundary sounds like a stronger claim. Everything inside it then has to be governed to the standard, evidenced, and kept that way after the audit finishes. Writing a system into a scope statement gives it a line of text. Ownership has to arrive from somewhere else.

What has to be true of a system before it belongs inside the boundary is a CWS bar. The standard asks for a documented scope; the list below is how CWS decides what goes in one. It comes from AI governance program work and from SAIL 2.0, the Secure AI Lifecycle Framework CWS contributed to. Someone reasonable could set it lower, and the reasoning is written out below so you can.

• A named owner with a job title and a manager, who knows the system is inside the boundary
• A written statement of what it is used to decide or produce, and who is affected when it gets that wrong
• The data it reaches, recorded, including anything that leaves the organization
• A change process, so that swapping a model, a prompt or a threshold leaves a record
• Records that outlive the people: logs, approvals and reviews retrievable months later by somebody new to the system
• A route to suspend or withdraw it, with the authority to use that route held by a named person

A scope statement is a claim about systems you can produce on request. Anything inside it that nobody owns is a claim you cannot support.

Two ways a boundary fails, and a third that catches careful teams

Narrow first. A tight scope is straightforward to run and straightforward to evidence, so it holds. Then the certificate goes to the customer who asked for it, and they read a boundary covering the internal assistant while the system they buy from you sits outside. Widening it afterwards means a scope change, fresh evidence for everything newly inside, and a conversation with whoever signed the original.

Wide fails later and louder. A boundary drawn around the whole company, or around every AI system anybody could name in a workshop, commits teams outside the room. They find out they are inside the management system when somebody requests records from them, and the argument that follows is about authority, held in the worst possible month.

The third shape catches organizations who thought about this properly. The boundary gets drawn around an organizational unit, and the AI systems cross it. A model built by a central team, operated by a business unit, reached by a product sitting in a different entity. Two of those three are inside the line. A reviewer finds the one that is outside it quickly, and it is the piece the customer was asking about.

• Which team built the model, and whether that team sits inside the boundary
• Which entity runs the infrastructure it depends on, and whether that entity sits inside the boundary
• Whether the feature the customer uses is one of the systems named
• Whose management system covers the response when an output is wrong and a customer is affected

Settle the boundary before the application starts

All of this is straightforward once it is on an agenda. The cost sits in the sequence. A scope decided during the first week of an application is a decision made by whoever was in the room that week, and it gets defended afterwards by people who arrive later.

Before anybody drafts the application, put the boundary in front of the person who will have to stand behind it in a customer's security review. Where that is a different person from the one drafting it, get both in the room.

One dependency sits underneath all of this and it is the one that delays programs. You cannot draw a boundary around AI systems nobody has found. Where the inventory is a spreadsheet assembled in an afternoon from procurement records and memory, the scope inherits every gap in it, and those gaps surface in front of an auditor.

• The inventory the boundary is drawn from, with its confidence position stated in writing
• Which AI systems are inside, named, and which part of the organization owns each of them
• The exclusions, written as decisions with the reason recorded next to each one, which is the work the Statement of Applicability exists to carry
• The person who signs the scope, and the person who defends it in a customer's security review, named separately where they are different people
• The date the boundary gets reviewed, because a scope written for the systems you had this year will describe fewer of them next year

The scope inherits every gap in the inventory it was drawn from, silently, and the certificate carries the gap forward.