The control families, in working terms
- Policies and governance. An AI policy aligned to organizational strategy, defined and staffed roles, reporting lines, and the internal accountability that makes every other control enforceable.
- Resources for AI. Documented understanding of what each AI system depends on: data resources, tooling and compute, models and algorithms, and crucially human resources, including the competence and availability of the people providing oversight.
- Impact assessment. Processes to assess consequences for individuals, groups, and society across the system lifecycle, with results feeding treatment decisions. The family that most distinguishes 42001 from every prior management standard.
- AI system lifecycle. Requirements and design documentation, verification and validation before deployment, deployment control, operation and monitoring, technical documentation, and event logging through to retirement.
- Data for AI systems. Provenance, acquisition, quality, preparation, and the governance of data across training and operation, where most real-world AI failures germinate.
- Information for interested parties. Transparency obligations: system documentation, communication of incidents, disclosure to users and affected parties appropriate to the context.
- Responsible use. Ensuring AI is used per policy and intended purpose, including when you are the deployer of someone else's system.
- Third-party relationships. Allocating responsibilities across the AI value chain: suppliers, model providers, and customers, with contracts and monitoring that match your actual dependence.
Where early audits find the gaps
Patterns already visible in first-generation ISO 42001 audits: inventories missing embedded and vendor AI; impact assessments that recite principles without naming harms or controls; lifecycle controls that stop at deployment with no drift monitoring or retirement discipline; data provenance asserted but undocumented; and third-party controls consisting of a model provider's marketing page. The controls that separate serious systems from decorative ones are monitoring in operation and the documented right to say no: evidence that assessments have ever constrained a deployment.
Reading Annex A as a builder
Treat the families as a completeness checklist against your real AI estate, not a document generator. For each system in your inventory, walk the families and ask what could fail here and what evidence would prove control. Where the honest answer is "nothing needed", your SoA says so with a justification; where it is "we should have this and do not", you have found your implementation plan in the standard's own order.