ISO 42001 for SMEs: Step-by-Step Implementation

What an AI management system is

An AIMS — Artificial Intelligence Management System — connects policy, objectives, processes, people, data, technology, suppliers, evaluation and improvement within an AI management system aligned with ISO/IEC 42001. It doesn't certify that every output is correct, nor does it replace the law: it demonstrates that the organization governs AI through an auditable system.

ISO/IEC 42001 follows the same high-level structure as other management-system standards, which makes it easier to integrate with ISO 9001, ISO/IEC 27001 or ISO 14001.

Who it makes sense for

It can add value when the SME:

• develops AI products or components;
• integrates third-party models into its services;
• uses AI in business-critical processes;
• needs to respond to client or tender requirements;
• needs to coordinate the AI Act, GDPR, security and quality;
• wants independent certification.

Certification shouldn't be pursued for marketing alone. There must first be a business case and the capacity to maintain the system.

Step 1. Define the scope

The scope identifies entities, locations, products, processes and roles. "All of the company's AI" can be unmanageable; "development and operation of the client-facing documentation assistant in Spain" is verifiable.

Critical dependencies shouldn't be excluded: data, platform, suppliers, security or support. Interfaces with areas outside the scope are documented.

Key questions to narrow the scope:

1. Do we develop, provide or use AI?
2. Which systems create the greatest impact?
3. Which clients and individuals are affected?
4. What contractual and legal obligations exist?
5. Which team can sustain the system?

Step 2. Context and interested parties

Internal and external issues are analysed: strategy, regulation, maturity, dependence on suppliers, competencies, data availability, cybersecurity and social expectations.

Interested parties can include clients, users, staff, affected individuals, regulators, suppliers, shareholders and society. Relevant requirements are recorded, along with how they are reviewed.

Not every expectation becomes an obligation, but the selection must be justified.

Step 3. Inventory of AI systems

The inventory is the backbone. Each record contains:

• name, owner and version;
• purpose and decisions;
• the organization's role;
• users and affected individuals;
• models, data and tools;
• supplier and sub-suppliers;
• environment and locations;
• autonomy and oversight;
• legal and risk classification;
• metrics, incidents and status.

"Shadow AI" is also recorded: personal accounts, embedded features and unapproved automations.

Step 4. Policy and governance

The policy must be specific: principles, prohibited uses, approval criteria, responsibilities and a commitment to improvement. Declaring "ethical AI" isn't enough.

An indicative RACI structure:

An SME can use a small committee, but must avoid decisions with no clear owner.

Step 5. Risks and opportunities

The method covers harms and opportunities for the organization, individuals and society. It should consider:

• incorrect outputs;
• discrimination and accessibility;
• lack of transparency;
• privacy and intellectual property;
• security and malicious use;
• dependence and continuity;
• labour and human impact;
• costs and resource consumption;
• expected and unrealised benefit.

Each risk has a cause, event, impact, likelihood, control, owner and residual risk. Acceptance thresholds are approved before assessment begins.

Step 6. Impact assessment

The impact assessment analyses the system's effects and foreseeable uses on individuals, groups and society. It's coordinated with a GDPR DPIA, an AI Act FRIA, security or sustainability assessments to avoid duplication.

It should include indirectly affected individuals, reasonably foreseeable unintended uses, failures, benefits, the distribution of impacts and complaint channels.

ISO/IEC 42005 provides specific guidance and can be integrated into the AIMS.

Step 7. Lifecycle

The system must control:

1. conception and requirements;
2. acquisition or design;
3. data and development;
4. validation;
5. deployment;
6. monitoring;
7. changes;
8. retirement.

Each gate has criteria. For example, a system doesn't move to production without testing, an owner, documentation, oversight, an incident process and a rollback plan.

Data and quality

Data governance covers provenance, lawfulness, quality, representativeness, labelling, access, retention and limitations. For RAG systems this includes documents and indexes; for third-party models, inputs, outputs and telemetry.

The SME must document what it doesn't know. Missing information from a supplier is itself a risk that may require restrictions.

Suppliers

Due diligence reviews:

• documentation and intended purpose;
• security, privacy and locations;
• use of data for training;
• sub-suppliers;
• metrics and limitations;
• version changes;
• incidents;
• export and exit.

The contract must assign responsibilities and notification duties. Accountability can't be outsourced.

Objectives and metrics

Objectives must measure outcomes, not just activity. Examples:

• 100% of systems inventoried and assigned an owner;
• zero critical actions taken without authorisation;
• a reduction in unsourced responses;
• maximum time to revoke credentials;
• percentage of changes causing regressions;
• incidents closed within SLA.

Every metric needs a definition, a source, a frequency, a threshold and an action.

Competence and literacy

Training varies by role. Management needs risk and accountability; development needs evaluation and security; users need limits and verification; procurement needs due diligence; the DPO and legal team need impact and rights.

Evidence must demonstrate competence, not just attendance: exercises, tests, observation or decision reviews.

Minimum viable documentation

An SME can maintain:

• scope and context;
• policy and objectives;
• inventory;
• risk and impact methodology;
• approval, change and incident procedures;
• supplier evaluation;
• metrics and records;
• internal audit;
• management review;
• corrective actions.

Duplicate documents aren't created where controls already exist in ISO 9001 or 27001; they're referenced and integrated instead.

Internal audit

The audit must check real evidence:

• Are there systems outside the inventory?
• Does the classification match actual use?
• Do the controls reduce risk?
• Are changes tested?
• Can oversight actually stop the system?
• Do incidents generate learning?
• Does management make decisions based on results?

The auditor must be objective and must not audit their own work.

Management review

Management reviews context, objectives, audits, incidents, performance, changes, resources and opportunities. The output must contain decisions: priorities, risk acceptance, resources and changes.

Certification

Certification typically includes stage 1 — documentation and scope readiness — and stage 2 — implementation and effectiveness — followed by surveillance. The certification body must be competent and operate under the applicable accreditation scheme.

Certification isn't announced before it's obtained, nor extended to products outside the scope.

The 120-day plan

Days 1-30

Scope, context and inventory. Policy, roles and methodology. Gap analysis against requirements.

Days 31-60

Priority risks and impacts. Suppliers and lifecycle. Controls and metrics.

Days 61-90

Implementation, training and records. Testing and incidents. Tracking objectives.

Days 91-120

Internal audit. Corrective actions. Management review. Certification preparation.

The timeline depends on scope and maturity; it isn't a guarantee.

Common mistakes

1. Certifying a scope that doesn't represent the business.
2. Inventorying only in-house models.
3. Copying a generic policy.
4. Separating compliance from the technical team.
5. Measuring activity instead of outcomes.
6. Not controlling supplier changes.
7. Duplicating ISO 27001 and 9001.
8. Leaving the impact assessment until the end.
9. Auditing without sufficient evidence.
10. Treating the certificate as the end of the process.

Checklist

• Verifiable scope.
• Complete inventory with owners.
• Policy, roles and escalation.
• Risk and impact per system.
• Lifecycle and control gates.
• Governed data and suppliers.
• Metrics with thresholds.
• Competence by role.
• Tested incidents, changes and retirement.
• Internal audit and management review.

Frequently asked questions

Is ISO 42001 mandatory?

It's a voluntary standard, unless a contract or sector requires it. It doesn't replace legal obligations.

Does it only apply to developers?

No. The standard states that it applies to organizations that develop, provide or use AI.

Does it certify a product?

It certifies the management system within a defined scope, not that every output of the product is correct.

Can it be integrated with ISO 27001?

Yes. They share a structure and governance, risk, audit and improvement controls, even though their subject matter differs.

Summum Calidad can support the scope definition, implementation, internal audit and certification preparation for ISO/IEC 42001, coordinated where needed with the AI impact assessment (ISO/IEC 42005), without ever replacing the certification body.