AI Governance and ISO 42001: Where to Start Before You Certify

Organisations are being asked whether they govern their use of AI — by customers, by regulators, by boards and increasingly in procurement questionnaires. ISO 42001 provides a management system standard for answering that, structured like ISO 27001 and addressing a materially different set of risks.

Certification is a decision for later. The governance is worth building now, because the questions have already started arriving.

What makes AI risk different

Existing security and privacy programmes cover part of the ground and miss several things entirely.

Non-determinism is the structural difference. Traditional software given the same input produces the same output, so testing means checking behaviour against a specification. A model may produce different outputs from the same input, and its behaviour is a distribution rather than a rule. That breaks the assumptions behind most assurance practice.

Data provenance matters in a new way. What a model was trained on determines what it does, and for third-party models you frequently cannot establish that.

Explainability affects whether a decision can be defended to a regulator, a customer or a court. That is a governance requirement, not a technical preference.

The management system, in outline

If you have run ISO 27001, the structure is familiar: context, leadership, planning, support, operation, performance evaluation and improvement, with a set of controls in an annex.

What differs is what you are managing:

The last two rows have no equivalent in an information security management system, and they are where most of the new work sits.

Start with the inventory

You cannot govern what you have not listed, and nearly every organisation underestimates its AI footprint. The inventory should capture more than procurement records show:

• Purchased AI features inside products you already use — the summarisation in your collaboration suite, the scoring in your recruitment tool, the assistant in your CRM
• Models your teams built, including scripts and spreadsheets doing statistical inference that nobody calls AI
• Third-party services called by your applications
• Tools staff adopted themselves, which is its own problem. See shadow AI

For each: what it decides or influences, what data goes into it, who is accountable, and what happens if it is wrong.

Impact assessment, proportionate to consequence

Not every AI system needs the same scrutiny. A summarisation feature and a system influencing clinical or employment decisions are different categories, and treating them alike either overloads the process or under-protects the serious cases.

Triage on consequence: does the system affect a person's access to care, employment, credit, housing or legal position? Systems that do need documented assessment, human oversight and a route to challenge. Systems that do not need proportionate, lighter treatment.

Relationship to other frameworks

The NIST AI Risk Management Framework is voluntary and complementary — useful structure for thinking about risk, without certification. Use it to inform your programme; use ISO 42001 if you need something certifiable.

Sector regulation increasingly touches AI directly, and health, financial services and employment are moving fastest. Build the inventory and the assessment process now and you will be positioned for whichever specific obligation arrives.

Where to start

Build the AI inventory. Ask each team what tools they use that make suggestions, predictions or decisions, and include the features embedded in software you already own. It takes a fortnight, it is the foundation of every other governance activity, and the list is always longer than expected.

GuardsArm helps organisations build AI governance and assess AI-related risk. See security strategy or book a scoping call.