01
No reliable AI system inventory
The organisation could not produce one definitive record of production models, experiments and third-party or foundation models embedded through vendor APIs.
Case studies · ISO/IEC 42001August 2026
ISO 42001 certification under pressure.
A mid-market SaaS provider had eight weeks to turn a repurposed ISO 27001 framework into an AI management system an external auditor could test.
Client name withheld. Identifying details have been generalised; the findings, sequence and reported outcome reflect the supplied engagement record.
8 weeks
To external audit
0
Major nonconformities
2
Opportunities for improvement
~180
Staff
/ Engagement profile
The situation, without identifying the client.
- Client profile
- Mid-market SaaS provider, approximately 180 staff
- AI use case
- AI-powered credit-risk scoring platform for banking partners
- Engagement
- ISO 42001 gap assessment, remediation support and pre-certification audit dry run
- Time available
- Eight weeks before the external certification audit
- Reported result
- Certification on the first attempt, with zero major nonconformities
A complete-looking AIMS that could not survive sampling
Two enterprise banking clients were pressing the SaaS provider to demonstrate responsible AI governance. The business committed to an external ISO/IEC 42001 certification audit before the underlying system had been tested, leaving eight weeks to make the evidence match the promise.
The documented AIMS had largely been produced by copying the organisation's existing ISO 27001 structure and relabelling it. The familiar management-system shape was present, but the AI-specific decisions, evidence and accountability were not. It was, in the engagement team's shorthand, a security management system wearing an AI costume.
Why the existing ISMS could not do the AI-specific job
/ Inventory before policy
The ISO 27001 structure gave the team useful management-system machinery: documented scope, policies, risk review, management review and corrective action. It did not identify the AI systems that machinery was meant to govern. Until production traffic and API dependencies were traced, the stated AIMS scope described an incomplete estate. Two live integrations existed outside the record, so any risk assessment built from the record began with the wrong population.
/ Impact is not another security risk
Credit scoring can affect whether a person receives access to a financial product and on what terms. That made bias, explainability and disparate impact matters an assessment subject in their own right, not merely another row in an information-security register. The audit file needed a documented method, completed assessments, approval evidence and a clear link from each in-scope system to the people and groups it could affect.
/ Outsourcing the model did not outsource accountability
The external foundation model was inside the client's scoring pipeline, so the client still had to show how it evaluated the provider and responded when the model changed. Conventional supplier due diligence did not answer the AI-specific questions. The recovery work therefore connected the supplier questionnaire, contract terms, model-change notification and internal ownership into one traceable control path an auditor could follow.
By the end of the recovery programme, the AIMS no longer relied on a complete-looking document set. It connected every in-scope system to an owner, AI-specific risk and impact records, relevant suppliers, operating evidence and management oversight. That traceability—not the presence of a relabelled policy—was what made the system testable.
What the first gap assessment found
02
AI risks hidden inside InfoSec scoring
Model drift, training-data bias, explainability failure and disparate impact were assessed with the same likelihood and impact criteria as conventional security threats, obscuring their real significance.
03
No AI impact assessments
The credit-scoring use case had no documented impact-assessment method, completed assessment or approval record that an auditor could sample.
04
Accountability existed only by implication
The Head of Engineering was treated as responsible, but no formally assigned role held the authority for AI-risk decisions required by the management system.
05
A third-party model blind spot
A material part of the scoring pipeline relied on an external foundation-model provider without AI-specific supplier evaluation, contract terms or visibility into model-change management.
06
Management review was not reviewing AI
Minutes existed, but they did not record AI incidents, progress against AI objectives, performance information or resourcing decisions.
These gaps were not presented as negligence. They were the predictable result of a capable information-security team applying a familiar system to an AI-specific standard under severe time pressure.
The recovery programme, in the order it happened
Week 1
Triage against certification risk
Each gap was ranked by the risk that it could produce a serious certification finding and by the effort needed to close it. Limited engineering time went to the highest-risk work first.
Inventory
Trace the AI estate from source
Production traffic and API dependencies were examined with engineering instead of relying on recollection. The work surfaced two live model integrations that were absent from the documented inventory.
Risk
Separate the AI risk method
The organisation introduced AI-specific criteria covering bias, explainability, autonomy and effects on people and society rather than continuing to reuse its information-security scoring model.
Impact
Make impact assessment executable
A working assessment template and a credit-scoring example gave the client a repeatable starting point for every in-scope AI system.
Roles
Put authority in writing
An AI Governance Owner role was defined, assigned and given documented authority, closing the gap between informal responsibility and accountable governance.
Supply
Bring the external model into control
The client worked through an AI supplier-risk questionnaire and model-change notification terms so its accountability no longer ended at the provider API.
Week 7
Run the evidence rehearsal
Aegentra ran a pre-certification dry run against Annex A, sampled the evidence and interviewed the staff likely to meet the external auditor. Two evidence-presentation problems were corrected before the external audit.
Certification on the first attempt
The client achieved ISO/IEC 42001 certification on its first attempt with zero major nonconformities. Two opportunities for improvement had already been identified during the dry run, so the external audit did not introduce an unknown issue on the day.
The AI system inventory also created value outside the certification scope: leadership obtained an accurate view of the organisation's AI footprint for the first time, and board stakeholders later identified that visibility as the most useful unplanned outcome.
Production and experimental AI systems were separated in one controlled inventory.
AI-specific risks and impact assessments became traceable evidence.
Ownership and supplier-model accountability were recorded rather than assumed.
Evidence-presentation weaknesses were corrected before the external auditor sampled them.
We thought we were ready because our ISO 27001 system was solid. Aegentra showed us, kindly but clearly, that AI governance isn't a copy-paste job — and then made sure we actually closed the gaps instead of just documenting around them.
/ Continue the evidence trail
The working paths behind the case study.
Plan an independent ISO 42001 internal auditUse the ISO 42001 internal audit checklistUnderstand the Australian certification pathBuild an ISO 42001 AI management systemSee the boundaries of Aeges evidence collectionTrain an ISO 42001 Lead ImplementerTrain an ISO 42001 Lead AuditorBrowse Aegentra engagement records
/ Publication boundary
This case study reflects an Aegentra Govern engagement. Details have been generalised to protect client confidentiality. The sequence of findings, remediation approach and reported certification outcome come from the supplied engagement record. Certification was determined independently by the external certification body; the outcome is not a guarantee for another organisation. Aegentra's current independence policy is not to perform the Clause 9.2 internal audit where Aegentra implemented the AIMS.
Is the external audit date already moving faster than the AIMS?
Start with a fixed-scope ISO 42001 internal audit or gap assessment. The scope, evidence request, sampling approach and independence boundary are agreed before work begins.