ISO/IEC 42001:2023 · AI Management System
Certifying an AI management system inside a financial data room
The short answer
ShareVault, a virtual data room used for M&A and financial-services transactions, passed both its ISO/IEC 42001 Stage 1 and Stage 2 certification audits with SenSiba as certification body, completing Stage 2 in December 2025. DISC InfoSec served as lead implementer for the AI management system and as independent internal auditor. The certified scope covers the ShareVault application, its supporting infrastructure, and four production AI systems — document classification, natural-language search, access-anomaly detection, and usage forecasting.
Engagement at a glance
The numbers
Every figure below is defined in the methodology note. Counts of audit findings are taken from the certification body's own reports, not from our internal assessment.
Pandesa Corporation · Los Gatos, CA
+ internal auditor
Client and context
Why a data room needed an AIMS
ShareVault is a virtual data room. Its customers store deal documents, financial records, and diligence material during transactions where a disclosure failure is not an inconvenience but a deal event. The platform had layered AI features onto that workload: automated document classification, natural-language search across a deal corpus, and machine-learned detection of unusual access patterns.
That combination creates a specific problem. The customers most attracted to AI-assisted diligence — investment banks, private equity, corporate development, outside counsel — are also the ones whose vendor questionnaires ask the hardest questions about model behaviour, training data, and human oversight. Answering those questions with a marketing page does not survive procurement. ISO 42001 was chosen because it produces the one thing a vendor questionnaire cannot argue with: an accredited third party's assessment of whether the controls actually operate.
Financial data rooms are the hard mode of AI compliance. The data is confidential by contract, material by definition, and regulated by sector. If a governance approach holds there, it holds in easier environments.
Scope
What the AIMS actually covered
Scope is the single most consequential decision in an ISO 42001 implementation. Set it too wide and you are collecting evidence for systems nobody asked about. Set it too narrow and the certificate does not cover the thing your customer is buying. The certified scope statement reads:
The AIMS that safeguards the ShareVault application, supporting infrastructure, AI systems and models, components, and the processes to develop, operate, maintain, and govern AI capabilities in accordance with the Statement of Applicability for ShareVault offices in Los Gatos, CA.
Four production AI systems fell inside that boundary, each assigned a risk tier that drove how much oversight and evidence it required:
| AI system | Function | Risk tier |
|---|---|---|
| Document Intelligence Engine | Automated document classification and indexing | Medium |
| Smart Search & Discovery | Natural-language search across deal corpora | Medium |
| Anomaly Detection System | Identification of unusual access patterns | High |
| Predictive Analytics | Usage forecasting and capacity planning | Low |
The anomaly detection system carried the highest tier because its output influences decisions about user access — the closest thing in the platform to an automated decision affecting a person. That tiering is what justified a mandatory human review checkpoint before any access action is taken on a model signal, which became one of the more scrutinised controls at Stage 2.
Control domains built out
The implementation work concentrated in five areas, each mapped to specific ISO 42001 clauses and Annex A controls:
| Domain | What was built |
|---|---|
| AI system lifecycle | Documented process for how AI capabilities are developed, tested, deployed, monitored, and retired; change control for model updates |
| Data governance for AI | Controls over training data provenance, quality, and permitted use; explicit commitment that customer deal content is not used to train models |
| Transparency and explainability | Documentation of how each AI feature reaches its output, at a depth a customer's counsel can read |
| AI risk management | AI-specific risk register covering bias, hallucination, adversarial input, model poisoning, and prompt injection — separate from, but reconciled with, the information security risk register |
| Human oversight | Defined checkpoints where human review is mandatory before an AI output drives an action, plus escalation paths for anomalous model behaviour |
Controls were additionally cross-walked to NIST SP 800-53 Rev. 5 so that a single evidence set could answer both ISO 42001 auditors and the federal-style control questionnaires that arrive from enterprise customers.
Timeline
How the engagement ran
The sequence below is the actual order of work. It matters, because the most common ISO 42001 failure is running these phases in parallel and discovering at Stage 2 that the risk assessment covers systems the inventory never captured.
-
[[VERIFY: month, year]] · Kickoff
AI system inventory and scope definition. Every AI capability in the platform identified, described, and either included in or explicitly excluded from the AIMS boundary.
Clause 4 — Context and scope -
[[VERIFY: month]] · Gap assessment
Existing ShareVault policies and procedures mapped against ISO 42001 clauses and Annex A. Substantial reuse from the existing information security program; the gaps were concentrated in AI-specific lifecycle, transparency, and oversight requirements.
Annex A — Statement of Applicability -
[[VERIFY: month]] · AIMS build-out
AI policy, AI risk assessment methodology, AI system impact assessments, human oversight procedures, and the AI-specific internal audit procedure drafted and approved by top management.
Clauses 5–8 — Leadership, planning, support, operation -
[[VERIFY: month]] · Internal audit
DISC InfoSec conducted the independent internal audit of the full AIMS scope. Findings were remediated and closure verified before the certification body was engaged.
Clause 9.2 — Internal audit -
November 2025 · Stage 1 audit — passed
SenSiba reviewed scope, policy, risk framework, and documentation for readiness. The AIMS was confirmed sufficient to proceed to Stage 2.
Documentation and readiness review -
December 2025 · Stage 2 audit — passed
Implementation and effectiveness assessment. Auditors examined operational records: how AI system performance is monitored, how AI risks are managed in practice, how data quality is maintained, and how human oversight is evidenced rather than merely described.
Clause 9 & Annex A — Operating effectiveness -
[[VERIFY: date]] · Certificate issued
ShareVault certified to ISO/IEC 42001:2023 — among the first virtual data room providers to hold the certification.
Certificate [[VERIFY: number]] -
2026 · Surveillance cycle
Ongoing. The AIMS is in its first surveillance period, with the internal audit programme extended to cover AI controls alongside the existing information security scope.
Clause 10 — Continual improvement
Outcome
What the first audit found
ShareVault passed Stage 1 and Stage 2 on the first attempt, with [[VERIFY: findings summary — e.g. "zero major nonconformities and N minor findings, all closed within the corrective action window"]].
Passing on the first attempt is not luck and it is not a comment on the auditors. It is a function of doing an honest internal audit first. An internal audit that finds nothing is not a clean bill of health; it is a failed internal audit, and it guarantees the certification body finds those items instead. The internal audit here was scoped to be adversarial on purpose — same clauses, same evidence sampling, same standard of proof the external team would apply.
The areas that drew the most Stage 2 scrutiny were predictable in hindsight and worth naming, because they are where most organisations will be tested:
- Evidence of human oversight, not policy describing it. Auditors wanted records showing a human actually reviewed model output at the defined checkpoints, with timestamps.
- Model change control. Demonstrating that a model update went through the documented lifecycle, including impact assessment, rather than shipping as a routine code change.
- Reconciliation between the AI risk register and the security risk register. Two registers is acceptable; two registers that contradict each other is a finding.
- Measurable AI objectives. Clause 5.2 requires the AI policy to provide a framework for setting AI objectives. Auditors check that those objectives exist, are measurable, and are reviewed in management review.
Retrospective
What I would do differently
Five things. All of them cost time on this engagement that they would not cost on the next one.
Freeze the AI system inventory before starting the risk assessment
We ran inventory and risk assessment with overlap, and every late-discovered AI capability forced rework across the risk register, the Statement of Applicability, and the impact assessments. The inventory should be signed off as complete — with a named owner attesting to it — before a single risk is scored. Shadow AI inside a product engineering org is real, and a feature that calls a third-party model is an AI system whether or not anyone called it one.
Do the ISO 27001 to ISO 42001 crosswalk on day one, not as a later deliverable
The crosswalk got built when a customer asked for it. Doing it first would have prevented a duplicated governance structure — a separate AI RACI running in parallel to the existing information security RACI, requiring cross-referencing to answer basic ownership questions. Auditors at surveillance want named AI owners inside the existing RACI, not a second document. One control set, one owner map, two certificates.
Write the AI-specific internal audit procedure from scratch
We adapted the existing ISMS internal audit procedure. That was faster and it was wrong. An ISMS audit procedure has no concept of sampling model outputs, testing bias monitoring cadence, or verifying that an impact assessment preceded a model change. Deriving from the ISMS version meant the AI-specific audit criteria got bolted on afterwards. Next time the AIMS audit procedure gets written against Clause 9.2 and Annex A directly.
Enforce ISO terminology from the first draft
Early policy drafts used "AI services" where ISO 42001 says "AI systems," and used purpose language where the standard expects scope language. Every one of those inconsistencies became a redline later, and any of them could have become an auditor question. Terminology discipline reads like pedantry until an auditor asks which definition governs.
Tie measurable AI objectives to the policy at the moment the policy is written
Clause 5.2(b) requires the AI policy to provide a framework for setting AI objectives. It is easy to write a policy that states principles beautifully and never connects to anything measurable. We closed that gap during preparation; it should never have been open. Write the objectives and the measurement method in the same session as the policy.
Methodology
How these figures were derived
Any number in a case study is worth exactly as much as its definition. Here are ours.
- Elapsed time is measured from engagement kickoff to the date SenSiba confirmed the Stage 2 outcome. It is calendar time, not billed effort, and includes client-side remediation periods. It is not a delivery estimate for another organisation.
- AI systems in scope counts distinct production AI systems named in the Statement of Applicability. Systems in development at the time of audit were excluded from scope and are not counted.
- Annex A control counts reflect controls marked applicable in the Statement of Applicability at the time of Stage 2, out of the 38 controls in ISO/IEC 42001:2023 Annex A. Exclusions carry documented justification.
- Nonconformity counts are taken from SenSiba's Stage 1 and Stage 2 audit reports as issued. They are the certification body's classifications, not DISC InfoSec's. Findings from our internal audit are counted separately and are not included in these figures.
- Risk tiers for AI systems are ShareVault's own classifications from its AI risk assessment methodology. They are internal tiers and do not correspond to EU AI Act risk categories.
- "Among the first virtual data room providers" reflects a review of publicly announced ISO 42001 certifications in the virtual data room category as of the certificate date. Certification registries are not exhaustive and this claim is stated as an approximation, not a first-mover assertion.
Published with ShareVault's permission. No confidential customer data, audit report text, or deal information is disclosed in this case study.
Transferability
What carries over to your organisation
An ISO 42001 implementation is not a template exercise, but the shape of the work is consistent. If you are running AI features inside a product your customers use for regulated or high-value work, the following holds regardless of sector:
- Your existing ISO 27001 or SOC 2 program is leverage, not overhead. A large share of ISO 42001's requirements sit on infrastructure you already have — access control, change management, incident response, supplier management. The genuinely new work is lifecycle, transparency, oversight, and AI-specific risk.
- Scope decides cost. Most of the difference between a manageable implementation and an expensive one is decided in the first two weeks, when the boundary is drawn.
- Evidence beats documentation. Stage 2 does not ask whether you wrote a procedure. It asks for records proving the procedure ran. Design evidence capture into the control when you build it, or you will reconstruct it under audit pressure.
- An internal audit that finds nothing has failed. The internal audit is the cheapest place to find your problems. Make it adversarial.