# Integrated Statement of Applicability (ISO/IEC 27001 and ISO/IEC 42001): [Organization name]

> One Statement of Applicability for an organization that runs an
> information security management system (ISMS) under ISO/IEC
> 27001:2022 + Amd 1:2024 and an AI management system (AIMS) under
> ISO/IEC 42001:2023. Both standards use the harmonized structure and
> both expect, in clause 6.1.3, one record that shows auditors every
> control decision: what was chosen and on what grounds, how far each
> chosen control has got, and why the rest were left out. This template records the 93 Annex A
> controls of ISO/IEC 27001 and the 38 Annex A controls of ISO/IEC 42001
> (cited by number only) in one controlled document, with columns that
> link the overlapping controls and a single integrated risk and impact
> process. Replace every `[bracketed]` value and every row marked
> *Example*.

<!--
Guidance: How to use this template
- Use it when the ISMS and the AIMS share top management, a risk
  method, an internal audit programme and a management review, and you
  want one decision record instead of two SoAs that drift apart.
- Fill section 1 (both scopes and the AI systems in scope) and section 3
  (the integrated risk and impact process) first. The control rows are
  the output of risk treatment, not a starting checklist.
- The main pitfall is letting the 27001 rows answer for AI risks they do
  not cover. Security controls protect AI systems; they do not address
  impact on individuals and society, data quality for training, or
  responsible use. Those decisions sit in the ISO/IEC 42001 rows.
- ISO/IEC 42001 controls appear by number only. For a short paraphrase
  of each, use `compliance/iso-42001-statement-of-applicability`, and
  read the standard for the normative text.
- Related templates: `compliance/statement-of-applicability`,
  `compliance/iso-42001-statement-of-applicability`,
  `compliance/risk-methodology`, `compliance/iso-42001-ai-policy`,
  `ai-data/ai-system-inventory`, `ai-data/ai-risk-assessment`,
  `ai-data/ai-impact-assessment-42005`,
  `ai-data/iso-27090-ai-security-review`,
  `isms/control-framework-crosswalk`, `isms/integrated-management-27013`.
-->

## Document control

<!-- Guidance: The integrated SoA is approved by top management for both systems. A change to either scope, a control decision in either part or a new edition of either standard is a new version with a new approval. -->

| Field | Value |
|---|---|
| Document ID | DOC-ISMS-107 |
| Version | [1.0] |
| Status | [Draft / In review / Approved / Superseded] |
| Owner | [@isms-manager] |
| Co-owner | [@ai-governance-lead] |
| Approvers/reviewers | [@ciso], [@cto], [@internal-audit], [@ceo] |
| Last updated | YYYY-MM-DD |
| Classification | [Internal / Confidential] |
| Standard and edition | ISO/IEC 27001:2022 + Amd 1:2024; ISO/IEC 42001:2023; guidance ISO/IEC 27002:2022 |
| ISMS scope reference | DOC-ISMS-002, version [n] |
| AIMS scope reference | [AIMS scope document ID and version] |
| Risk methodology reference | DOC-ISMS-010 (with the AI-risk variant, section 11 of that document) |
| Risk treatment plan reference | DOC-ISMS-013 |
| AI system inventory reference | [AI system inventory ID] |
| Supersedes | [DOC-ISMS-011 version n and SOA-AIMS-001 version n, or none] |
| Next scheduled review | YYYY-MM-DD |

### Approvals

| Role | Name | Decision | Date |
|---|---|---|---|
| ISMS manager | [@isms-manager] | [Prepared: Part A] | YYYY-MM-DD |
| AI governance lead | [@ai-governance-lead] | [Prepared: Part B] | YYYY-MM-DD |
| Risk owner representative | [@coo] | [Approved / Approved with changes] | YYYY-MM-DD |
| Top management | [@ceo] | [Approved] | YYYY-MM-DD |

### Revision history

| Version | Date | Author | Change |
|---|---|---|---|
| 1.0 *(Example)* | YYYY-MM-DD | [@isms-manager], [@ai-governance-lead] | First integrated SoA; replaces separate ISMS and AIMS SoAs |
| 1.1 *(Example)* | YYYY-MM-DD | [@ai-governance-lead] | AIS-002 added to scope; A.7.3 changed to applicable |

## Contents

<!-- Guidance: Sections 1 to 4 set the rules, sections 5 and 6 are the two control matrices auditors walk row by row, sections 7 to 10 keep the decisions defensible, sections 11 to 15 cover size, certification, maintenance and records. -->

1. Purpose and scope
2. Shared and standard-specific clauses
3. Integrated risk and impact process
4. Decision rules and columns
5. Part A: ISO/IEC 27001:2022 Annex A (93 controls)
6. Part B: ISO/IEC 42001:2023 Annex A (38 controls)
7. Justification of exclusions
8. Overlap groups: one implementation, two standards
9. Additional controls outside both Annexes
10. Summary
11. Size tiers
12. Certification and audit considerations
13. Review and maintenance
14. Records and evidence
15. References

## 1. Purpose and scope

<!-- Guidance: State both scopes and show how they relate. Questions to answer: is the AIMS scope inside the ISMS scope, equal to it or wider? Which AI systems are in scope, and in which role (developer, provider, user)? Pitfall: an AI system in the AIMS scope that runs on infrastructure outside the ISMS scope, with no security controls recorded anywhere. -->

This integrated Statement of Applicability records, for [Organization
name], the decision on every Annex A control of ISO/IEC 27001:2022 and
of ISO/IEC 42001:2023, the basis for each decision, the implementation
status, the owner and the evidence. It is the single reference for what
the organization claims to operate under both management systems.

| Item | ISMS (ISO/IEC 27001) | AIMS (ISO/IEC 42001) |
|---|---|---|
| Scope statement | DOC-ISMS-002 | [AIMS scope ID] |
| Legal entities | [entities] | [entities] |
| Locations and cloud regions | [sites, regions] | [sites, regions] |
| Services or products | [services] | [AI systems: AIS-NNN list] |
| Organization's role regarding AI | Not applicable | [Developer / provider / user / customer, per AI system] |
| Relationship of the scopes | [AIMS scope is inside / equal to / wider than the ISMS scope] | |

*Example:* Quillmere Analytics Ltd (small tier, 46 staff, B2B SaaS
analytics) is assumed here to add a machine learning forecasting feature
(AIS-001) to its platform and to use a third-party hosted model service
for it. The AIMS scope covers AIS-001 and sits inside the ISMS scope,
which already covers the platform, both cloud regions and the office.

**AI systems in scope**

| ID | AI system | Role | Lifecycle stage | Impact assessment | Risk entries |
|---|---|---|---|---|---|
| AIS-001 *(Example)* | Forecasting feature in the analytics platform | Developer and provider | Production | AIIA-001, YYYY-MM-DD | R-041, R-042 |
| [AIS-NNN] | [system] | [role] | [stage] | [AIIA-NNN] | [R-NNN] |

## 2. Shared and standard-specific clauses

<!-- Guidance: Both standards follow the harmonized structure (clauses 4 to 10), so most management system processes can be shared. Record which document serves both and where each standard adds its own requirement. What an auditor checks: that a shared document really covers the specific requirements of each standard, not only the common text. -->

| Clause | Shared process and document | ISO/IEC 27001 specific | ISO/IEC 42001 specific |
|---|---|---|---|
| 4.1 Context | One context analysis (DOC-ISMS-003) | Climate change as a possible relevant issue (Amd 1:2024) | The organization's roles regarding AI systems and the intended purpose of each system |
| 4.2 Interested parties | One register (DOC-ISMS-003) | Note that parties may have climate-related requirements (Amd 1:2024) | Parties affected by AI systems, including individuals and groups outside the organization |
| 4.3 Scope | Two scope statements, cross-referenced | ISMS boundaries and interfaces | AI systems and activities in scope |
| 4.4 Management system | One integrated process map (DOC-ISMS-004) | None beyond the shared text | None beyond the shared text |
| 5.1, 5.3 Leadership and roles | One RACI (DOC-ISMS-006), one steering committee (DOC-ISMS-007) | Information security roles | AI roles and responsibilities (the route for raising concerns is Annex A control A.3.3) |
| 5.2 Policy | Two policies or one combined policy | Information security policy (DOC-ISMS-001) | AI policy (`compliance/iso-42001-ai-policy`) |
| 6.1.2 Risk assessment | One method (DOC-ISMS-010) with two risk sources | Risks to confidentiality, integrity and availability | AI risks to the organization and to individuals, groups and society |
| 6.1.3 Risk treatment and SoA | This document and one treatment plan (DOC-ISMS-013) | Comparison with ISO/IEC 27001 Annex A | Comparison with ISO/IEC 42001 Annex A; Annex B gives implementation guidance |
| 6.1.4 AI system impact assessment | Not shared | Not in ISO/IEC 27001 | Impact assessment process for each AI system (`ai-data/ai-impact-assessment-42005`) |
| 6.2 Objectives | One objectives register (DOC-ISMS-024) with tagged objectives | Security objectives | AI objectives |
| 6.3 Planning of changes | One change plan (DOC-ISMS-025) | Changes to the ISMS | Changes to the AIMS |
| 7.1 to 7.5 Support | One competence matrix (DOC-ISMS-026), communication plan (DOC-ISMS-027) and documented information register (DOC-ISMS-028) | Security competence and awareness | AI competence, including data science and evaluation skills |
| 8.1 to 8.3 Operation | Shared operational planning and risk treatment records | Risk assessment and treatment results | AI risk assessment and treatment results |
| 8.4 AI system impact assessment | Not shared | Not in ISO/IEC 27001 | Impact assessments performed at planned intervals and on change |
| 9.1 to 9.3 Evaluation | One measurement programme (DOC-ISMS-080), one audit programme (DOC-ISMS-082), one management review (DOC-ISMS-085) | Security performance | AI performance and AIMS effectiveness |
| 10.1, 10.2 Improvement | One improvement register (DOC-ISMS-088) and one nonconformity process (DOC-ISMS-087) | None beyond the shared text | None beyond the shared text |

## 3. Integrated risk and impact process

<!-- Guidance: Use one risk method and one register for both systems, with a field that shows the risk source (security, AI or both). Keep the AI system impact assessment as a separate input, because it looks at consequences for people and society, not only for the organization. Pitfall: scoring AI harms to individuals on the organization's financial impact scale, which hides them. -->

The organization runs one risk process for both management systems,
using the 5 x 5 scale in DOC-ISMS-010 (score 1 to 25; Low 1 to 4, Medium
5 to 9, High 10 to 16, Critical 17 to 25 (in practice 20 and 25)). Each risk in the register (DOC-ISMS-016)
carries a source tag: **SEC** (information security), **AI** (AI risk)
or **SEC+AI** (both). AI system impact assessments feed the AI risk
assessment and are recorded separately so that consequences for
individuals and groups stay visible.

```mermaid
flowchart TD
  A["Context and interested parties (4.1, 4.2)"] --> B["Shared risk method DOC-ISMS-010"]
  A --> C["AI system impact assessment (42001 6.1.4)"]
  B --> D["Security risk assessment (27001 6.1.2)"]
  B --> E["AI risk assessment (42001 6.1.2)"]
  C --> E
  D --> F["One risk register, source tag SEC, AI or SEC+AI"]
  E --> F
  F --> G["Risk treatment (6.1.3 in both)"]
  G --> H["Part A: 27001 Annex A decisions"]
  G --> I["Part B: 42001 Annex A decisions"]
  H --> J["One treatment plan DOC-ISMS-013 and risk owner approval"]
  I --> J
  J --> K["Management review (9.3)"]
```

Acceptance follows DOC-ISMS-010 section 2.4 for both sources: Low may be
accepted by the risk owner and Medium by the risk owner and the
department head; High needs top management acceptance with a
treatment decision; Critical cannot be accepted without treatment except
by documented top management decision. For AI risks with significant
impact on individuals or groups, the AI governance lead also signs the
acceptance record (DOC-ISMS-019).

## 4. Decision rules and columns

<!-- Guidance: Define the codes once so each row stays short. Code I (impact assessment) is used only in Part B or where an AI impact assessment drove a Part A control. What an auditor checks: that every Yes traces to a code and a record, and that every No has a testable reason in section 7. -->

| Code | Basis for inclusion | Typical source |
|---|---|---|
| R | Treats an assessed risk (security or AI) | Risk register ID, for example R-041 |
| I | Responds to an AI system impact assessment finding | AIIA ID, for example AIIA-001 |
| L | Legal or regulatory requirement | Legal register DOC-ISMS-014 entry |
| C | Contractual requirement | Customer contract, DPA or supplier agreement |
| B | Business decision adopted by management | Policy decision, steering committee minute |

| Status | Meaning |
|---|---|
| Implemented | Operating, with evidence for at least one full cycle |
| Partial | Designed and partly operating; remaining work in DOC-ISMS-013 |
| Planned | Approved, not yet operating; due date in DOC-ISMS-013 |
| Not applicable | Excluded; reason in section 7 |

The column **Related ISO/IEC 42001 controls** in Part A, and **Related
ISO/IEC 27001 controls** in Part B, are pre-filled with the library's
suggested links (section 8). They show where one implementation and one
evidence set can serve both standards. They are not equivalences: check
each link against your own implementation and delete links that do not
hold.

## 5. Part A: ISO/IEC 27001:2022 Annex A (93 controls)

<!-- Guidance: One row per control in Annex A order, using the same short labels as compliance/statement-of-applicability. Do not delete rows for excluded controls. Where a control also protects an AI system (model hosting, training data stores, model registries), name that in the evidence so the AI scope is visibly covered. -->

### 5.1 A.5 Organizational controls (37)

| Control | Short label (not official title) | Applicable | Basis | Status | Related ISO/IEC 42001 controls | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.5.1 *(Example)* | Information security policies | Yes | R, C, B | Implemented | A.2.2, A.2.3, A.2.4 | [@isms-manager] | DOC-ISMS-001 and AI policy, approved together YYYY-MM-DD |
| A.5.2 | Security roles and responsibilities | [Yes / No] | [R, I, L, C, B] | [status] | A.3.2 | [@owner] | [ref] |
| A.5.3 | Segregation of duties | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.4 | Management responsibilities for security | [Yes / No] | [R, I, L, C, B] | [status] | A.3.2 | [@owner] | [ref] |
| A.5.5 | Contact with authorities | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.6 | Contact with special interest groups | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.7 | Threat intelligence (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.8 | Security in project management | [Yes / No] | [R, I, L, C, B] | [status] | A.6.1.3 | [@owner] | [ref] |
| A.5.9 | Inventory of information and assets | [Yes / No] | [R, I, L, C, B] | [status] | A.4.2, A.4.3, A.4.4, A.4.5 | [@owner] | [ref] |
| A.5.10 | Acceptable use of information and assets | [Yes / No] | [R, I, L, C, B] | [status] | A.9.4 | [@owner] | [ref] |
| A.5.11 | Return of assets | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.12 | Information classification | [Yes / No] | [R, I, L, C, B] | [status] | A.7.2 | [@owner] | [ref] |
| A.5.13 | Information labelling | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.14 | Information transfer | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.15 | Access control rules | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.16 | Identity lifecycle management | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.17 | Authentication information handling | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.18 | Access rights provisioning and review | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.19 | Security in supplier relationships | [Yes / No] | [R, I, L, C, B] | [status] | A.10.2, A.10.3 | [@owner] | [ref] |
| A.5.20 | Security in supplier agreements | [Yes / No] | [R, I, L, C, B] | [status] | A.10.2 | [@owner] | [ref] |
| A.5.21 | ICT supply chain security | [Yes / No] | [R, I, L, C, B] | [status] | A.10.3 | [@owner] | [ref] |
| A.5.22 | Supplier service monitoring and change | [Yes / No] | [R, I, L, C, B] | [status] | A.10.3 | [@owner] | [ref] |
| A.5.23 *(Example)* | Security for cloud service use (new in 2022) | Yes | R, C | Implemented | A.10.3 | [@platform-lead] | DOC-ISMS-044; model hosting service reviewed in the same supplier review |
| A.5.24 | Incident management planning | [Yes / No] | [R, I, L, C, B] | [status] | A.8.4 | [@owner] | [ref] |
| A.5.25 | Assessing security events | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.26 | Responding to security incidents | [Yes / No] | [R, I, L, C, B] | [status] | A.8.4 | [@owner] | [ref] |
| A.5.27 | Learning from incidents | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.28 | Evidence collection | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.29 | Security during disruption | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.30 | ICT readiness for business continuity (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.31 | Legal, regulatory and contractual requirements | [Yes / No] | [R, I, L, C, B] | [status] | A.8.5 | [@owner] | [ref] |
| A.5.32 | Intellectual property rights | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.33 | Protection of records | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.8 | [@owner] | [ref] |
| A.5.34 | Privacy and PII protection | [Yes / No] | [R, I, L, C, B] | [status] | A.7.3, A.7.5 | [@owner] | [ref] |
| A.5.35 | Independent review of security | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.36 | Compliance with security policies and standards | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.5.37 | Documented operating procedures | [Yes / No] | [R, I, L, C, B] | [status] | A.9.2 | [@owner] | [ref] |

### 5.2 A.6 People controls (8)

| Control | Short label (not official title) | Applicable | Basis | Status | Related ISO/IEC 42001 controls | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.6.1 | Pre-employment screening | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.2 | Security terms in employment contracts | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.3 | Awareness, education and training | [Yes / No] | [R, I, L, C, B] | [status] | A.4.6 | [@owner] | [ref] |
| A.6.4 | Disciplinary process | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.5 | Duties after leaving or changing role | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.6 | Confidentiality agreements | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.7 | Remote working | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.6.8 | Reporting security events | [Yes / No] | [R, I, L, C, B] | [status] | A.3.3, A.8.3 | [@owner] | [ref] |

### 5.3 A.7 Physical controls (14)

| Control | Short label (not official title) | Applicable | Basis | Status | Related ISO/IEC 42001 controls | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.7.1 | Physical security perimeters | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.2 | Physical entry controls | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.3 | Securing offices, rooms and facilities | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.4 | Physical security monitoring (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.5 | Protection against physical and environmental threats | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.6 | Working in secure areas | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.7 | Clear desk and clear screen | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.8 | Equipment siting and protection | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.9 | Assets used off-premises | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.10 | Storage media | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.11 | Supporting utilities | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.12 | Cabling security | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.13 | Equipment maintenance | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.7.14 | Secure disposal or re-use of equipment | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |

### 5.4 A.8 Technological controls (34)

| Control | Short label (not official title) | Applicable | Basis | Status | Related ISO/IEC 42001 controls | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.8.1 | User endpoint devices | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.2 | Privileged access rights | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.3 | Restricting access to information | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.4 | Access to source code | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.5 | Secure authentication | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.6 | Capacity management | [Yes / No] | [R, I, L, C, B] | [status] | A.4.5 | [@owner] | [ref] |
| A.8.7 | Protection against malware | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.8 | Technical vulnerability management | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.9 | Configuration management (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.10 | Information deletion (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.11 | Data masking (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | A.7.6 | [@owner] | [ref] |
| A.8.12 | Data leakage prevention (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.13 | Information backup | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.14 | Redundancy of processing facilities | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.15 | Logging | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.8 | [@owner] | [ref] |
| A.8.16 | Monitoring activities (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.6 | [@owner] | [ref] |
| A.8.17 | Clock synchronization | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.18 | Use of privileged utility programs | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.19 | Software installation on operational systems | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.20 | Network security | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.21 | Security of network services | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.22 | Network segregation | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.23 | Web filtering (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.24 | Use of cryptography | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.25 *(Example)* | Secure development life cycle | Yes | R, I | Partial | A.6.1.3, A.6.2.2 | [@head-of-engineering] | DOC-ISMS-065; ML release gate added, evaluation step due YYYY-MM-DD |
| A.8.26 | Application security requirements | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.2 | [@owner] | [ref] |
| A.8.27 | Secure architecture and engineering principles | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.3 | [@owner] | [ref] |
| A.8.28 | Secure coding (new in 2022) | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.29 | Security testing in development and acceptance | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.4 | [@owner] | [ref] |
| A.8.30 *(Example)* | Outsourced development | No | none | Not applicable | none | [@isms-manager] | DOC-ISMS-066 shows no outsourced development; see section 7 |
| A.8.31 | Separation of development, test and production | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |
| A.8.32 | Change management | [Yes / No] | [R, I, L, C, B] | [status] | A.6.2.5 | [@owner] | [ref] |
| A.8.33 | Test information | [Yes / No] | [R, I, L, C, B] | [status] | A.7.4, A.7.6 | [@owner] | [ref] |
| A.8.34 | Protecting systems during audit testing | [Yes / No] | [R, I, L, C, B] | [status] | none | [@owner] | [ref] |

## 6. Part B: ISO/IEC 42001:2023 Annex A (38 controls)

<!-- Guidance: One row per control in Annex A order, cited by number only. Area headings are short labels written for this template. Read the control text in ISO/IEC 42001 and its implementation guidance in Annex B, or the paraphrases in compliance/iso-42001-statement-of-applicability, before deciding. Name the AI systems each control applies to. -->

ISO/IEC 42001:2023 Annex A groups its controls into nine areas, A.2 to
A.10, each with one control objective (A.6 has two, A.6.1 and A.6.2).
Public summaries count 38 controls; confirm the count against the
edition you hold.

### 6.1 A.2 AI policy (3)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.2.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.1 | [AIS-NNN] | [@owner] | [ref] |
| A.2.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.1 | [AIS-NNN] | [@owner] | [ref] |
| A.2.4 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.1 | [AIS-NNN] | [@owner] | [ref] |

### 6.2 A.3 Internal organization for AI (2)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.3.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.2, A.5.4 | [AIS-NNN] | [@owner] | [ref] |
| A.3.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.6.8 | [AIS-NNN] | [@owner] | [ref] |

### 6.3 A.4 Resources for AI systems (5)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.4.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.9 | [AIS-NNN] | [@owner] | [ref] |
| A.4.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.9 | [AIS-NNN] | [@owner] | [ref] |
| A.4.4 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.9 | [AIS-NNN] | [@owner] | [ref] |
| A.4.5 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.9, A.8.6 | [AIS-NNN] | [@owner] | [ref] |
| A.4.6 | [Yes / No] | [R, I, L, C, B] | [status] | A.6.3 | [AIS-NNN] | [@owner] | [ref] |

### 6.4 A.5 AI system impact assessment (4)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.5.2 *(Example)* | Yes | I, L | Implemented | none (AI-specific) | AIS-001 | [@ai-governance-lead] | AIIA-001 for the forecasting feature, approved YYYY-MM-DD |
| A.5.3 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.5.4 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.5.5 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |

### 6.5 A.6 AI system life cycle (9)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.6.1.2 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.6.1.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.8, A.8.25 | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.25, A.8.26 | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.27 | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.4 *(Example)* | Yes | R, C | Partial | A.8.29 | AIS-001 | [@ml-lead] | Evaluation report template; drift thresholds due YYYY-MM-DD |
| A.6.2.5 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.32 | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.6 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.16 | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.7 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.6.2.8 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.33, A.8.15 | [AIS-NNN] | [@owner] | [ref] |

### 6.6 A.7 Data for AI systems (5)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.7.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.12 | [AIS-NNN] | [@owner] | [ref] |
| A.7.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.34 | [AIS-NNN] | [@owner] | [ref] |
| A.7.4 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.33 | [AIS-NNN] | [@owner] | [ref] |
| A.7.5 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.34 | [AIS-NNN] | [@owner] | [ref] |
| A.7.6 | [Yes / No] | [R, I, L, C, B] | [status] | A.8.11, A.8.33 | [AIS-NNN] | [@owner] | [ref] |

### 6.7 A.8 Information for interested parties (4)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.8.2 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.8.3 | [Yes / No] | [R, I, L, C, B] | [status] | A.6.8 | [AIS-NNN] | [@owner] | [ref] |
| A.8.4 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.24, A.5.26 | [AIS-NNN] | [@owner] | [ref] |
| A.8.5 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.31 | [AIS-NNN] | [@owner] | [ref] |

### 6.8 A.9 Use of AI systems (3)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.9.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.37 | [AIS-NNN] | [@owner] | [ref] |
| A.9.3 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |
| A.9.4 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.10 | [AIS-NNN] | [@owner] | [ref] |

### 6.9 A.10 Third-party and customer relationships (3)

| Control | Applicable | Basis | Status | Related ISO/IEC 27001 controls | AI systems | Owner | Evidence |
|---|---|---|---|---|---|---|---|
| A.10.2 | [Yes / No] | [R, I, L, C, B] | [status] | A.5.19, A.5.20 | [AIS-NNN] | [@owner] | [ref] |
| A.10.3 *(Example)* | Yes | R | Implemented | A.5.19, A.5.21, A.5.22, A.5.23 | AIS-001 | [@procurement-lead] | Supplier register entry for the model hosting service, joint review with A.5.19 to A.5.23 |
| A.10.4 | [Yes / No] | [R, I, L, C, B] | [status] | none (AI-specific) | [AIS-NNN] | [@owner] | [ref] |

## 7. Justification of exclusions

<!-- Guidance: Every No in Part A or Part B appears here with a reason based on scope, absence of the activity, absence of the risk or the organization's AI role. "Too expensive" is a risk acceptance, not an exclusion. -->

| Standard | Control | Reason for exclusion | Evidence that the activity or risk is absent | Trigger to reassess | Approved by |
|---|---|---|---|---|---|
| ISO/IEC 27001 | A.8.30 *(Example)* | No development is outsourced; all code, including the AIS-001 model pipeline, is written by employees | Supplier register DOC-ISMS-066 shows no development suppliers | First contract for external code or model development | [@ceo] |
| [Standard] | [control] | [reason] | [record] | [event] | [@approver] |

Role-based exclusions in Part B need particular care. An organization
that only uses AI systems supplied by others may justify excluding some
life cycle controls, but it must still show how it checks that supplied
systems meet its responsible AI approach (A.10.3) and how it uses them
as intended (A.9.4).

## 8. Overlap groups: one implementation, two standards

<!-- Guidance: Group the controls that one process can satisfy for both standards, name one owner per group, and record one evidence set. What an auditor checks: that the shared process covers the AI-specific content, not only the security content. -->

| Group | ISO/IEC 27001 controls | ISO/IEC 42001 controls | Shared implementation | What the AI side adds |
|---|---|---|---|---|
| OG-01 Policy | A.5.1 | A.2.2, A.2.3, A.2.4 | One policy framework (DOC-ISMS-005) with an AI policy and a common review cycle | Alignment of other policies with AI objectives; event-driven AI policy review |
| OG-02 Roles | A.5.2, A.5.4 | A.3.2 | One RACI (DOC-ISMS-006) | AI-specific roles such as model owner and evaluation lead |
| OG-03 Reporting concerns | A.6.8 | A.3.3, A.8.3 | One reporting channel (DOC-ISMS-023) | Concerns about AI behaviour and adverse impacts, also from external parties |
| OG-04 Inventory and resources | A.5.9, A.8.6 | A.4.2, A.4.3, A.4.4, A.4.5 | One asset inventory (DOC-ISMS-012) with AI resource fields | Data, tooling, computing resources per AI life cycle stage |
| OG-05 Competence | A.6.3 | A.4.6 | One competence matrix (DOC-ISMS-026) | Data science, evaluation and responsible AI skills |
| OG-06 Secure and responsible development | A.5.8, A.8.25, A.8.26, A.8.27, A.8.29, A.8.32 | A.6.1.3, A.6.2.2, A.6.2.3, A.6.2.4, A.6.2.5 | One development life cycle (DOC-ISMS-065) with ML stages | Requirements, verification and validation criteria, release criteria for AI behaviour |
| OG-07 Logging and monitoring | A.5.33, A.8.15, A.8.16 | A.6.2.6, A.6.2.8 | One logging standard and monitoring procedure (DOC-ISMS-064) | Model performance and drift monitoring; event logs for AI system use |
| OG-08 Data | A.5.12, A.5.34, A.8.11, A.8.33 | A.7.2, A.7.3, A.7.4, A.7.5, A.7.6 | One classification scheme and data handling rules (DOC-ISMS-042, DOC-ISMS-062) | Data quality, provenance, acquisition and preparation for training |
| OG-09 Incidents and reporting | A.5.24, A.5.26, A.5.31 | A.8.4, A.8.5 | One incident response plan (DOC-ISMS-020) and legal register (DOC-ISMS-014) | Communicating AI incidents to users; deciding what to report to interested parties |
| OG-10 Suppliers | A.5.19, A.5.20, A.5.21, A.5.22, A.5.23 | A.10.2, A.10.3 | One supplier register (DOC-ISMS-066) and assessment (DOC-ISMS-067) | Allocation of AI life cycle responsibilities; fit of supplied models and data with the AI policy |
| OG-11 Procedures and use | A.5.10, A.5.37 | A.9.2, A.9.4 | Acceptable use (DOC-ISMS-040) and operating procedures (DOC-ISMS-049) | Responsible and intended use of AI systems |

ISO/IEC 42001 controls with no ISO/IEC 27001 counterpart in this table
(A.5.2 to A.5.5, A.6.1.2, A.6.2.7, A.8.2, A.9.3 and A.10.4) need their own
process and evidence. Most of them concern impact on people, transparency
and objectives for responsible AI, which an ISMS does not address.

## 9. Additional controls outside both Annexes

<!-- Guidance: Clause 6.1.3 in both standards allows controls from any source. List controls you need that neither Annex describes at the level you require, with the source and the risk they treat. -->

| ID | Control (original wording) | Source | Basis | Treats | Status | Evidence |
|---|---|---|---|---|---|---|
| ADD-001 *(Example)* | Test each major model release against prompt injection, data extraction and model evasion before deployment | ISO/IEC 27090:2026 (AI security guidance) | R | R-042 | Planned | `ai-data/iso-27090-ai-security-review` record |
| ADD-002 *(Example)* | Keep a machine-readable inventory of models, datasets and components for each AI system | Internal standard | R, C | R-041 | Partial | AI system inventory |
| ADD-003 *(Example)* | Process personal data in training and inference under documented privacy controls and a DPIA where required | ISO/IEC 27701:2025; GDPR as an example law | L, C | R-043 | Implemented | `compliance/dpia` record |
| ADD-004 *(Example)* | Map each AI system to the NIST AI RMF functions for customers who ask for that framework | NIST AI RMF 1.0 (NIST AI 100-1) | C | none | Planned | Customer mapping file |
| [ADD-NNN] | [control] | [source] | [code] | [R-NNN] | [status] | [ref] |

## 10. Summary

<!-- Guidance: Fill the counts after both matrices are complete. Part A totals must add up to 93 and Part B totals to 38; a mismatch means a missing or duplicated row. -->

**Part A, ISO/IEC 27001 Annex A** *(Example, Quillmere Analytics Ltd; same figures as the example in compliance/statement-of-applicability)*

| Theme | Controls | Applicable | Not applicable | Implemented | Partial | Planned |
|---|---|---|---|---|---|---|
| A.5 Organizational | 37 | 37 | 0 | 30 | 5 | 2 |
| A.6 People | 8 | 8 | 0 | 8 | 0 | 0 |
| A.7 Physical | 14 | 14 | 0 | 12 | 2 | 0 |
| A.8 Technological | 34 | 33 | 1 | 26 | 5 | 2 |
| **Total** | **93** | **92** | **1** | **76** | **12** | **4** |

**Part B, ISO/IEC 42001 Annex A** *(Example, Quillmere Analytics Ltd)*

| Area | Controls | Applicable | Not applicable | Implemented | Partial | Planned |
|---|---|---|---|---|---|---|
| A.2 AI policy | 3 | 3 | 0 | 3 | 0 | 0 |
| A.3 Internal organization | 2 | 2 | 0 | 2 | 0 | 0 |
| A.4 Resources | 5 | 5 | 0 | 3 | 2 | 0 |
| A.5 Impact assessment | 4 | 4 | 0 | 2 | 1 | 1 |
| A.6 Life cycle | 9 | 9 | 0 | 4 | 3 | 2 |
| A.7 Data | 5 | 5 | 0 | 2 | 2 | 1 |
| A.8 Information for interested parties | 4 | 4 | 0 | 1 | 2 | 1 |
| A.9 Use | 3 | 3 | 0 | 2 | 1 | 0 |
| A.10 Third parties and customers | 3 | 3 | 0 | 1 | 1 | 1 |
| **Total** | **38** | **38** | **0** | **20** | **12** | **6** |

In the example, the integrated SoA records 131 control decisions (93 +
38), of which 130 are applicable and 1 is excluded. Eleven overlap groups
(section 8) cover 30 Part A controls and 29 Part B controls, so one
evidence set serves both standards for those rows.

## 11. Size tiers

<!-- Guidance: The integrated approach pays off more as the organization grows, but even a small team benefits from one decision record. These tiers are the library's working tiers, not official definitions. -->

| Aspect | Small: Quillmere Analytics Ltd (46 staff) | Medium: Quillmere Health Systems (320 staff) | Large: Quillmere Group (2,400 staff, 6 sites in 4 countries) |
|---|---|---|---|
| AI systems in scope *(Example)* | One forecasting feature (AIS-001), assumed for this example | Assumed: a scheduling optimisation model in the clinical scheduling product, plus staff use of a generative AI assistant | Assumed: predictive maintenance models in 3 plants (OT data) and a customer service assistant at the service centre |
| Owners | ISMS manager (0.5 FTE, Head of Engineering Operations) owns Part A; the ML lead owns Part B | ISMS manager owns Part A; an AI governance lead owns Part B; 3-person security team supports both | CISO office (14 people) owns Part A; a group AI governance function owns Part B; site leads own local evidence |
| Document form | One Markdown file, this template | This template plus the risk register and AIIA records | This template as the group master, with site annexes for site-specific evidence |
| Risk process | One register, source tag column | One register, monthly risk review for SEC and AI | Group register with site views; OT safety impacts considered in AI impact assessments |
| Integration with other systems | None beyond ISMS and AIMS | ISMS, AIMS, PIMS (ISO/IEC 27701 planned the year after 27001) | Integrated management system with ISO 9001 and ISO 22301 already certified; see `isms/integrated-management-27013` |

## 12. Certification and audit considerations

<!-- Guidance: Be honest about what the integrated SoA does and does not change. Certification decisions belong to the accredited certification body. What an auditor checks: that each standard's required SoA content is identifiable in the combined document. -->

- **Two standards, two certificates.** ISO/IEC 27001 and ISO/IEC 42001
  are certified separately, even when audited together. A certification
  body auditing an AIMS works to ISO/IEC 42006:2025 in addition to
  ISO/IEC 17021-1:2015; for the ISMS it applies ISO/IEC 27006-1:2024.
  Check that the body is accredited for each standard by an
  accreditation body that signs the Global ACI MRA (formerly IAF MLA);
  the IAF CertSearch database can help (check that it still operates).
- **One document, two requirements.** Each standard requires its own
  Statement of Applicability. A combined document can meet both when the
  content each standard requires is clearly identifiable, as Parts A and
  B are here. Confirm with your certification body before Stage 1 that
  it accepts a combined SoA, and be ready to cite the version of this
  document on each certificate.
- **Integrated or combined audits.** Certification bodies may audit
  several management systems together; IAF MD 11:2023, now re-issued by
  Global ACI as Global ACI-TECH-3-008, covers the application of ISO/IEC
  17021-1 to audits of integrated management systems (check the current
  issue on global-aci.org). Audit time for each standard is set by
  the certification body; integration may reduce it, but there is no
  fixed reduction.
- **No promise of certification.** Using this template does not
  guarantee any audit outcome.

## 13. Review and maintenance

<!-- Guidance: Tie reviews to events in both systems, not only to the calendar. A new AI system is the most common trigger that is missed. -->

Review the integrated SoA at least once a year, as an input to
management review (DOC-ISMS-085), and also when:

- either scope changes, or an AI system is added, retired or changes
  role (for example from user to provider);
- an AI system impact assessment or the risk assessment is updated, or
  a significant security or AI incident occurs;
- a new legal, regulatory or contractual requirement applies, such as
  AI-specific legislation in a market where the organization operates;
- a control status changes between Planned, Partial and Implemented;
- a new edition or amendment of ISO/IEC 27001 or ISO/IEC 42001 is
  published.

Keep superseded versions as documented information. When moving from
two separate SoAs to this document, keep the old SoAs and record the
transition in the revision history.

## 14. Records and evidence

<!-- Guidance: List the records that prove the integrated SoA operates and link each to the control evidence matrix (isms/control-evidence-matrix). Keep one evidence record per overlap group, tagged with both standards. -->

| Record | Owner | Location | Retention *(Example)* |
|---|---|---|---|
| Approved integrated SoA versions | [@isms-manager] | Document management system, DOC-ISMS-107 | Current plus superseded versions for the certificate cycle plus 3 years |
| Risk register with source tags | Risk owners | DOC-ISMS-016 | 3 years after closure of each risk |
| AI system impact assessments | [@ai-governance-lead] | AIIA records | Life of the AI system plus 3 years |
| Risk treatment plan and acceptance records | [@isms-manager] | DOC-ISMS-013, DOC-ISMS-019 | 3 years |
| Control evidence tagged by standard | Control owners | `isms/control-evidence-matrix` (DOC-ISMS-033) | Certificate cycle plus 1 year |
| Management review minutes covering both systems | [@ceo] | DOC-ISMS-085 | 3 years |
| Certification body confirmation of combined SoA | [@isms-manager] | Certification file | Certificate cycle |

## 15. References

<!-- Guidance: Cite editions exactly. Read the official texts before relying on any short label or link in this template. -->

| Reference | Edition and status | Use |
|---|---|---|
| ISO/IEC 27001:2022 + Amd 1:2024 | Current (https://www.iso.org/standard/82875.html, Amd 1: https://www.iso.org/standard/88435.html) | Clause 6.1.3 and Annex A numbers |
| ISO/IEC 27002:2022 | Current (https://www.iso.org/standard/75652.html) | Security control guidance |
| ISO/IEC 42001:2023 | Current (https://www.iso.org/standard/81230.html) | Clauses 6.1.2 to 6.1.4, 8.2 to 8.4, Annex A numbers, Annex B guidance |
| ISO/IEC 42006:2025 | Current (https://www.iso.org/standard/44546.html) | Requirements for bodies certifying AI management systems |
| ISO/IEC 27006-1:2024 | Current (https://www.iso.org/standard/82908.html) | Requirements for bodies certifying ISMS |
| ISO/IEC 17021-1:2015 | Current (https://www.iso.org/standard/61651.html) | Certification body requirements |
| ISO/IEC 27090:2026 | Current (https://www.iso.org/standard/56581.html) | AI security guidance for additional controls |
| ISO/IEC 27701:2025 | Current (https://www.iso.org/standard/85819.html) | Privacy controls for personal data in AI systems |
| ISO/IEC 42005:2025 and ISO/IEC 23894:2023 | Cited without link | AI system impact assessment and AI risk management guidance |
| NIST AI RMF 1.0, NIST AI 100-1 | 26 January 2023, revision announced (https://doi.org/10.6028/NIST.AI.100-1) | Optional customer mapping |
| IAF MD 11:2023, re-issued as Global ACI-TECH-3-008 | Issued September 2023; Global ACI v1.0 in force 2026-08-28; check the current issue on global-aci.org | Audits of integrated management systems |
| Related templates | `compliance/statement-of-applicability`, `compliance/iso-42001-statement-of-applicability`, `compliance/risk-methodology`, `compliance/iso-42001-ai-policy`, `ai-data/ai-system-inventory`, `ai-data/ai-risk-assessment`, `ai-data/ai-impact-assessment-42005`, `ai-data/iso-27090-ai-security-review`, `compliance/dpia`, `isms/control-framework-crosswalk`, `isms/integrated-management-27013`, `isms/control-evidence-matrix` | Linked documents |

## Standard and licence note

Structure aligned with ISO/IEC 27001:2022 + Amd 1:2024 and ISO/IEC
42001:2023 (clause 6.1.3 and the Annex A numbering of both standards).
The ISO/IEC 27001 short labels are original descriptions shared with
`compliance/statement-of-applicability`; ISO/IEC 42001 controls are cited
by number only. The decision codes, overlap groups, links between the
two Annexes, examples and guidance are original work and reproduce no
text, tables or definitions from ISO or IEC standards. ISO and IEC
standards are copyrighted and sold by ISO, IEC and national standards
bodies: read the official texts (https://www.iso.org/standard/82875.html
and https://www.iso.org/standard/81230.html). Check the current editions
and amendments of both standards, and your certification body's rules,
before use. This is a documentation format, not certification or legal
advice. Template licence: MIT.