You have decided to build an AI management system, either because a customer asked for ISO/IEC 42001 or because AI use has spread far enough that someone needs to own it. The standard tells you what the finished system must contain. It does not tell you what to do first.
Most teams start in the wrong place. They write an AI policy, then a long list of controls, and discover months later that nothing connects the two. The controls were chosen before anyone assessed a risk, so the Statement of Applicability has nothing to justify against.
This article gives a build order that avoids that. It assumes you know what ISO/IEC 42001 certifies and focuses on the sequence and the artifacts each step produces.
Start with the boundary and your role
Clause 4 asks you to understand your context, identify interested parties, and set the scope of the AIMS. For AI, it adds a question most ISMS work never asks: what is your role with respect to each AI system?
The roles matter because they change your obligations. An organization that trains and sells a model carries different risks from one that calls a third-party model through an API, which differs again from one whose staff use an AI writing assistant. Many organizations are more than one of these.
Produce three things before anything else:
A list of the AI systems in scope. Name, purpose, owner, and whether you develop it, provide it to others, or use it. It can be rough at first.
A scope statement. Which products, services, teams, and locations the AIMS covers, and what it excludes. Exclusions need a reason.
An interested parties register. Customers, users, the people an AI system makes decisions about, regulators, and suppliers, with what each expects of you.
The ISO/IEC 27001 clause 4 article covers context and interested parties in depth. The method transfers directly. The difference is that "people affected by the system" becomes a distinct interested party, and they often are not your customers.
Put leadership on the record
Clause 5 needs three artifacts, and auditors check all of them.
The AI policy. Short, approved by top management, and committed to meeting applicable requirements and to continual improvement. It sets the frame for AI objectives. It is not an acceptable use policy for staff, which is a separate, operational document.
Roles and responsibilities. Who owns the AIMS, who owns each AI system, who approves risk acceptance, and who can stop a system. Write names or roles, not "the AI team."
Evidence of commitment. Minutes or decisions showing management set direction, approved resources, and reviewed results. This accumulates over time. Start the record now.
A common gap: nobody is named as able to pause or withdraw an AI system. When an auditor asks who would make that call, the answer should be in a document, not in someone's head.
Build the methods before you run them
Clause 6 is where the system gets its substance. It asks for two related but distinct processes.
AI risk assessment identifies risks to the organization and its objectives, analyzes them, and evaluates them against criteria you set in advance. If you already keep a risk register, extend it rather than start a second one. The principles in building a risk register auditors accept apply unchanged.
AI system impact assessment looks the other way. It considers the potential consequences of an AI system for individuals, groups of individuals, and society. Its results feed the risk assessment, but it is a separate, documented activity.
Write both methods down before you run either. Each method document should state:
When an assessment is triggered (new system, significant change, planned interval)
Who performs it and who approves it
The criteria for likelihood, severity, and acceptability
What the output looks like and where it is kept
Then run them on two or three systems, not all of them. Fix the method based on what you learn, then roll it out. An auditor would rather see a method that was revised after use than one that was never tested.
Choose controls, then write the Statement of Applicability
Risk treatment comes next. For each risk you decide to treat, choose controls. Then compare your choices against Annex A to check you have not missed any that are necessary.
The output is the Statement of Applicability. For every Annex A control it records whether the control is included, the justification, and whether it is implemented. Excluded controls need a justification too.
The order matters. The Statement of Applicability is a consequence of risk treatment. Teams that fill it in first end up justifying controls with "best practice," which is not a reason an auditor accepts.
Clause 6 also asks for AI objectives that are measurable where practicable, with owners and timelines. Keep them few. Two or three objectives that someone actually reports on beat ten that nobody tracks.
Make it operate
Clauses 7 and 8 turn the plan into a running system. The work is mostly unglamorous and mostly about records.
Competence. Decide what competence each AIMS role needs, and keep evidence that people have it: training, qualifications, or experience.
Awareness. Staff should know the AI policy exists, how it affects their work, and how to raise a concern. Keep acknowledgment records.
Documented information. Version control, approval, and retention for every document the system relies on.
Operational control. The processes you planned actually run. For AI systems that often means design reviews, verification before release, and monitoring in production.
Change triggers. Clause 8 requires risk and impact assessments at planned intervals and when significant changes are proposed or occur. Define "significant" in writing. A new model version, a new data source, or a new category of user are reasonable starting points.
Close the loop before you book the audit
Clause 9 and clause 10 are what make it a management system rather than a set of documents.
Monitoring and measurement. Decide what you measure, how often, and who reviews it. Your AI objectives are the obvious starting point.
Internal audit. Audit the AIMS against the standard and your own procedures. The auditor must be objective, which usually means not auditing their own work.
Management review. Top management reviews the inputs the standard lists, including audit results, changes, and performance, and records decisions.
Corrective action. Each nonconformity gets a root cause, a correction, and a check that the fix worked.
Certification bodies generally expect at least one internal audit and one management review before stage 2. Plan for the system to run for a few months first, so the records show operation rather than a single burst of activity.
What people get wrong
Treating it as a security project. Security controls matter, but the impact assessment and the people affected by your systems are the part ISO/IEC 42001 adds. Skipping them leaves the core of the standard unbuilt.
Scoping too wide on day one. A narrow scope that operates well is easier to certify and easier to extend.
Building a parallel system. If you hold ISO/IEC 27001, reuse its document control, internal audit, management review, and corrective action processes. The harmonized structure exists for this.
Writing controls without owners. A control with no named owner will not produce evidence.
The ISO 42001 framework page summarizes each clause if you need a quick reference while building.
How TrustLynce helps
TrustLynce's policy management handles AI policy versioning, approval, and acknowledgment tracking. The risk register holds AI risks alongside your existing ones, with scoring and treatment plans, so the Statement of Applicability can trace back to real decisions.