6.3 Integrated AIMS–ISMS Thinking for Auditors
Key Takeaways
- ISO/IEC 42001 and ISO/IEC 27001 share the Harmonized Structure, enabling combined audit programs and shared forums—without making requirements identical.
- Security of training data and AI-specific data quality are complementary: CIA protects assets; AIMS addresses fitness for learning, bias, lineage, and lifecycle evaluation.
- SoA overlaps are common, but each SoA must still justify applicability for its own control set; “we have 27001” does not exclude AI impact-assessment controls.
- Classify findings as 42001, 27001, or both based on failed criteria—avoid unjustified double-counting and avoid missing AI-only gaps when only an ISMS exists.
- A strong ISMS without an AIMS still leaves AI gaps: impact assessment, AI objectives, fairness/drift monitoring, and AI policy may be absent despite excellent security metrics.
6.3 Integrated AIMS–ISMS Thinking for Auditors
Auditor focus: Many auditees present one management office and one internal audit function for both ISO/IEC 27001 and ISO/IEC 42001. Reuse shared evidence where criteria overlap—and still find AI-specific gaps security never covered.
Organizations deploying AI almost always process information assets. That creates natural integration between an AIMS (ISO/IEC 42001) and an ISMS (ISO/IEC 27001). Auditors who understand both prevent double-counting without analysis and missing AI gaps because “security looked fine.”
Shared Annex SL / Harmonized Structure
Both standards use the ISO Harmonized Structure for Clauses 4–10. Practical map:
| Shared element | Integration opportunity | AI-specific residual test |
|---|---|---|
| 4 Context | One interested-party workshop | AI regulators, affected persons, model providers, societal impacts |
| 5 Leadership / policy | Combined digital governance | Explicit AI policy and AI roles—not only security policy |
| 6 Planning | Unified risk framework | AI risk, impact assessment, AI objectives—not only CIA risk |
| 7 Support | Shared competence & document platforms | AI literacy, validation skills, AI documented information |
| 8 Operation | Change management / supplier processes | Lifecycle gates, human oversight, use controls |
| 9 Evaluation | Combined internal audit & management review calendars | AI metrics, AI audit criteria, AI review inputs |
| 10 Improvement | Single CAPA tool | Causes/CAs for model, data, and AI governance failure modes |
Rule: Shared structure ≠ shared conformity. An ISMS context file that never mentions foundation-model dependency or AI regulation does not satisfy AIMS Clause 4.1.
Complementary Controls: Training-Data Security vs AI Data Quality
Security controls protect confidentiality, integrity, and availability. AI management controls address whether data and systems are fit for AI purposes—quality, bias, representativeness, lineage, intended use, ongoing evaluation.
| Concern | Primarily ISMS (27001) | Primarily AIMS (42001) | Often both |
|---|---|---|---|
| Unauthorized access to training corpus | Access control, encryption | — | Personal-data leak with fairness impact |
| Tampering with labels / feature stores | Integrity, logging, change control | Data quality, lineage, poisoning as AI risk | Poisoning that degrades model behavior |
| Backup of model artifacts | Availability, backup | Versioning for reproducibility | Ransomware on ML platform |
| Biased under-representation in dataset | Rarely pure CIA | Data for AI, fairness, impact assessment | Discriminatory outcomes + privacy harm |
| Prompt injection / model abuse | AppSec, secure development | Use controls, human oversight, third parties | Jailbreaks causing data exfiltration |
| Vendor LLM outage | Supplier security / continuity | Third-party AI & operational control | Dual business impact |
Scenario — training data breach: Attackers exfiltrate a customer dataset used for training. 27001: access control, logging, supplier security, confidentiality incident. 42001: AI data governance, lifecycle/third-party controls; reassess impact; revalidate if training integrity is uncertain. Coordinate CA so security and AI data/lifecycle fixes complete—without pasting identical text into two reports as unrelated “majors.”
Combined Audit Programs
| Approach | Description | Caution |
|---|---|---|
| Separate | Distinct AIMS and ISMS audits | Higher cost; clearer criteria |
| Combined | Parallel audits with coordination | Reserve time for AI deep dives |
| Integrated | Single program, dual criteria | Team competence for AI and security; tag criteria in working papers |
A 27001-only auditor without model monitoring or impact-assessment skills needs AI-competent support. Do not let network tests consume the window while AI inventory, impact assessments, and drift monitoring go unsampled.
SoA Overlaps
- 27001 SoA: Annex A security controls for the ISMS.
- 42001 SoA: Annex A AI controls linked to AI risk/context.
Overlaps appear where security supports AI trustworthiness (secure development, endpoint access, supplier security) and AI controls depend on secure, quality data. Read both SoAs. Exclusions must be justified per standard—excluding AI impact-assessment controls because “we have ISO 27001” is invalid. Do not mark AIMS Annex A implemented solely because a 27001 control is green.
Exam Scenarios: 42001, 27001, or Both?
Classify by failed criteria, not vibes.
A — Missing encryption at rest for a personal-data feature store
Primarily 27001 (cryptography / asset protection / risk treatment). Add 42001 only if AI data/operational requirements clearly required the same protection and evidence is missing. Lead with the standard whose requirement text failed.
B — No impact assessment for a high-risk hiring model; strong HR-app security
Primarily 42001 (impact assessment, AI risk, lifecycle/use controls). Not fixed by 27001 certification. Raise 27001 only for a separate security NC (e.g., excessive access to candidate data).
C — Model API keys in a public repo (inference + training extracts)
Often both: secret management / secure development (27001) and AI access, data, and operational control (42001). CA should vault/rotate secrets and strengthen AI access governance and abuse monitoring.
D — Excellent SIEM; zero model quality or drift monitoring
42001 9.1 / operational monitoring gap. Not a 27001 finding merely because “monitoring” exists—different measurand. Trap: accepting SOC dashboards as AIMS performance evaluation.
E — Integrated management review covers only security KPIs
42001 9.3 (and possibly leadership) if AIMS inputs/outputs are missing. ISMS 9.3 may be fine—do not invent a balancing 27001 NC.
Double-Counting vs Missing AI Gaps
| Failure mode | Looks like | Better practice |
|---|---|---|
| Double-counting | Two majors with identical text on “risk assessment” without distinguishing CIA vs AI impact | Dual-criteria finding or two findings with distinct requirement quotes and evidence |
| Missing AI gaps | Closing after firewall/IAM samples only | Mandatory AI sample list: inventory, impact assessments, model monitoring, AI policy, third-party models |
| Evidence substitution | “27001 certified, so 42001 Stage 1 unnecessary” | Still test AIMS scope, policy, risk/impact design, AI SoA |
| CAPA collision | Security closes ticket; data science never updates lifecycle gate | One CA record, multi-owner actions mapped to each standard |
| Only-ISMS claiming AI coverage | Shadow AI managed only by acceptable-use policy | Residual AIMS gaps: no AI objectives, impact process, or AI audit criteria |
When only ISMS is in scope: do not invent 42001 NCs; you may note observations where unmanaged AI harms information security. When 42001 is in scope: never accept “ISMS covers it” without AI-specific objective evidence.
Working-paper tags: ISMS-only, AIMS-only, Both. Example: security incident metrics (ISMS); model drift metrics (AIMS); joint LLM-vendor review (Both).
Exam Takeaways
- HLS enables integration; it does not collapse AI into CIA.
- Training-data security and AI data quality are complements, not substitutes.
- Combined programs need dual competence and dual criteria.
- SoA overlaps still need per-standard justification.
- Classify by which requirement failed.
- Strong ISMS + weak AIMS often shows in Clauses 9–10.
When clients say “we already showed this under 27001,” reply: Show the AI criteria and AI evidence.
An organization has a mature ISO/IEC 27001 ISMS with strong encryption and access control over training data, but no AI system impact assessments, AI objectives, or production drift monitoring for high-risk models. For an ISO/IEC 42001 audit, what is the correct conclusion?
API keys for a production model were committed to a public repository, enabling unauthorized inference and download of training extracts. How should findings typically be classified?
Why is “we monitor everything in the SIEM” usually insufficient evidence for ISO/IEC 42001 Clause 9.1 in an integrated AIMS–ISMS environment?
In an integrated audit, the team writes two major nonconformities with nearly identical text—one against 27001 risk assessment and one against 42001 risk assessment—based on a single missing spreadsheet row, without distinguishing CIA vs AI impact criteria. What is the main problem?