ISO 42001 for start-ups and small AI teams: a right-sized AIMS that a twelve-person company can run

What does ISO/IEC 42001 ask of a small AI team?

Exactly the clauses it asks of a multinational, applied to a far smaller footprint. Clause 1 states that the standard is meant for any organisation, regardless of size, type and nature, that provides or uses products or services built on AI systems. A ten-person start-up shipping a feature on a generative AI model is covered as fully as a bank scoring loan applicants.

What changes with size is how much you write down and how many people carry the work. ISO/IEC 42001 follows the harmonised structure shared with ISO 9001 and ISO/IEC 27001, including the note under clause 7.5.1 that the extent of documented information depends on the size of the organisation, the complexity of its processes and the competence of its people. Three things cannot be skipped, however small you are: the AI risk assessment (6.1.2), the AI risk treatment with its Statement of Applicability across the 38 Annex A controls (6.1.3), and an AI system impact assessment for each system in scope (6.1.4). The requirements guide covers every clause; this page sizes them.

Start with the inventory, not the policy

Begin with a one-page list, not the AI policy: each AI system you develop, provide or use, what it does, who owns it, which model or service sits underneath and whose data flows through it. Note your role for each, developer, provider or user, because it decides which Annex A controls weigh most.

That list sets the clause 4.3 scope statement, the number of impact assessments and the suppliers that fall under A.10. For most start-ups it holds a handful of entries: the product feature customers pay for, perhaps a fine-tuned model, and the assistants staff use for code or writing. Deciding which of these belong inside the certificate is covered in ISO/IEC 42001 scope: which AI systems and roles are in, and the mistakes that cost you.

What a start-up can keep light

One register for risks and treatments

Clause 6.1.2 asks for a method that produces consistent, valid and comparable results, not a heavyweight tool. One register row per risk, carrying the system, consequences for the organisation, individuals and society, likelihood, owner, controls and accepted residual risk, covers both assessment and treatment plan. Clause 6.1.3 requires designated management to approve that plan and the residual risks; in a start-up that is usually the founders, and their dated approval is the record.

Impact assessments sized to the system

An internal coding assistant needs a short assessment; a feature that ranks job candidates needs a thorough one. Each covers deployment, intended use and foreseeable misuse, and feeds the risk assessment. The impact assessment guide, with ISO/IEC 42005, shows the method.

A Statement of Applicability that explains itself

All 38 controls appear, each with a decision, a reason and a pointer to evidence.

Records your tools already make

Pull requests, evaluation runs, release notes, prompt history and support tickets are life-cycle and event records. Point to them; do not copy them into new forms.

Worked example: a twelve-person start-up with one AI product

Picture a software company of twelve people. Its product is a customer-service assistant built on a third-party model through an API, grounded in each customer's own knowledge base. Staff also use a general chat assistant and a coding assistant. Enterprise buyers are asking about AI governance. The company is illustrative.

The documents are modest; operating them takes the time: evaluations every release, the register updated when the provider changes a model version, and reassessments after significant change under clauses 8.2 and 8.4.

How many people it takes

A small AIMS needs an AIMS lead with authority, founders who make decisions, and owners for each system in scope. One person can hold several roles, with a firm limit: the harmonised structure asks for internal audits that are objective and impartial, so nobody audits their own work. A trained colleague from another area, or an external auditor for the AIMS lead's own areas, solves this. The certification body cannot fill that gap, because ISO/IEC 17021-1 treats internal audits it carries out for its certified clients as a threat to impartiality.

A.3.3 also asks for a way to report concerns about AI systems. A named channel with a reviewer is enough, if people know it exists. Competence is covered in ISO/IEC 42001 training: who needs what, and the competence evidence.

The calendar does not shrink in proportion to headcount. Controls must operate before an auditor can test them, so the typical four to eight months still applies; see ISO/IEC 42001 timeline: how long certification takes, stage by stage.

Where small AIMS projects go wrong

• Buying a template set. Generic templates assume model risk committees and data science departments, and every page commits you to something the auditor will test.
• Leaning on the model provider. Its documentation describes its model; your prompts, grounding data and guardrails are yours to assess.
• Forgetting the tools staff use. Assistants used internally are AI systems you use. Leaving them off the inventory without a stated reason is a gap the auditor finds in the first interview.
• One person owning everything. If that person leaves, surveillance meets a stale register. Spread ownership across system owners.
• Treating the impact assessment as a one-off. Agree in advance which changes to models, prompts and features trigger a reassessment.

What the certification audit looks like for a small scope

The route is the same as for any organisation: a certification body accredited to ISO/IEC 17021-1 with the AIMS requirements of ISO/IEC 42006 runs Stage 1, its readiness review, and then Stage 2, followed by annual surveillance and recertification in the third year. Check that the body is accredited for ISO/IEC 42001 specifically; see Choosing an ISO/IEC 42001 certification body: accreditation and ISO/IEC 42006.

With a small scope, auditors typically interview most of the team, trace a risk through the Statement of Applicability to a live control and read every impact assessment rather than a sample.

ISO/IEC 42001 for start-ups: questions buyers ask