1. Purpose & Authority
The Canonical Source Standards Register is the authoritative scope of normative reference for the CIAO Standard. It defines which source standards CIAO documents may engage. Amendments to CIAO content may engage only standards in this Register; proposals engaging unregistered standards are escalated as Register Addition Requests under the Change Management & Versioning Process.
The Register is an instrument of foundational governance — Class B in the Constitutional hierarchy declared in Constitution Section 7. Its authority arises from the role it plays: every entry in the Register represents the application of the patented multi-framework mapping methodology to that source standard, producing a normalized cross-mapping against the entire CIAO Standard content. A standard not yet in the Register has not yet been compiled into the CIAO mapping fabric; it cannot serve as a normative reference until that compilation is performed.
Each entry below names a source standard the CIAO Standard cites in its mappings. Each entry carries a short code used in inline references; a family classification used to group standards by tradition; the issuing authority; and the primary CAO content domain into which the standard most closely maps. Where a standard genuinely spans two CAO domains, both are listed.
Members configure their applicable source-standards portfolio at the My Source Standards page (login required). Once configured, the Dynamic Selection Engine filters the Standard’s inline references to the member’s selected portfolio. The Register’s authority over what may be referenced is independent of any individual member’s portfolio configuration; portfolio configuration is presentational, the Register’s authority is normative.
2. The Register
Twenty-six source standards are currently in the Register, organised across seven families. Additions follow the source-standard re-issue trigger pathway in the Change Management & Versioning Process.
ISO 27k (6)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| ISO/IEC 27001:2022 | ISO27001 | ISO/IEC | CAO-400 |
| ISO/IEC 27002:2022 | ISO27002 | ISO/IEC | CAO-400 |
| ISO/IEC 27005:2022 | ISO27005 | ISO/IEC | CAO-200 |
| ISO/IEC 27017:2015 | ISO27017 | ISO/IEC | CAO-400 |
| ISO/IEC 27018:2019 | ISO27018 | ISO/IEC | CAO-400, CAO-300 |
| ISO/IEC 27701:2019 | ISO27701 | ISO/IEC | CAO-300 |
ISO 9k / 22k / 31k (4)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| ISO 22301:2019 | ISO22301 | ISO | CAO-500 |
| ISO 31000:2018 | ISO31000 | ISO | CAO-200 |
| ISO 9001:2015 | ISO9001 | ISO | CAO-100 |
| ISO/IEC 38500:2024 | ISO38500 | ISO/IEC | CAO-100 |
NIST (3)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| NIST Cybersecurity Framework v2.0 | NISTCSF | NIST (US) | CAO-400 |
| NIST SP 800-37 Rev. 2 | NISTSP80037 | NIST (US) | CAO-200 |
| NIST SP 800-53 Rev. 5 | NISTSP80053 | NIST (US) | CAO-400 |
Privacy & Data Protection (5)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| CCPA / CPRA (California) | CCPA | State of California, US | CAO-300, CAO-800 |
| GDPR (EU 2016/679) | GDPR | European Union | CAO-300, CAO-800 |
| PIPEDA (Canada) | PIPEDA | Government of Canada | CAO-300, CAO-800 |
| POPIA (Act 4 of 2013) | POPIA | Republic of South Africa | CAO-300, CAO-800 |
| UK GDPR & DPA 2018 | UKGDPR | United Kingdom | CAO-300, CAO-800 |
Cyber & Sector Regulation (4)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| EU DORA (Regulation 2022/2554) | DORA | European Union | CAO-400, CAO-500 |
| EU NIS2 Directive (2022/2555) | NIS2 | European Union | CAO-400, CAO-800 |
| PCI DSS v4.0 | PCIDSS | PCI Security Standards Council | CAO-400 |
| SA Cybercrimes Act (No. 19 of 2020) | SACYBER | Republic of South Africa | CAO-400, CAO-800 |
Risk & Continuity (2)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| COSO ERM Framework (2017) | COSOERM | Committee of Sponsoring Organizations | CAO-200 |
| ISO/IEC 27031:2011 | ISO27031 | ISO/IEC | CAO-500 |
AI & Emerging (2)
| Standard | Short Code | Authority | Primary CAO Domain |
|---|---|---|---|
| EU AI Act (2024/1689) | EUAIACT | European Union | CAO-700, CAO-800 |
| ISO/IEC 42001:2023 | ISO42001 | ISO/IEC | CAO-700 |
3. Family Coverage
| Family | Count | Notes |
|---|---|---|
| ISO 27k | 6 | Information security family — ISO 27001 anchor, plus aligned profiles |
| ISO 9k / 22k / 31k | 4 | General-purpose management system standards |
| NIST | 3 | US frameworks where adopted internationally |
| Privacy & Data Protection | 5 | GDPR, POPIA, and adjacent regimes |
| Cyber & Sector Regulation | 4 | DORA, NIS2, sector-specific |
| Risk & Continuity | 2 | BCM and risk-specific |
| AI & Emerging | 2 | ISO 42001 and AI Act |
4. Maintenance and Expansion
The Register is maintained by the Secretariat under two pathways set out in the Change Management Process.
Re-issue of an existing entry. When a referenced source standard is itself revised by its issuing body, a Secretariat-initiated proposal is automatically created to assess the impact on every CIAO mapping that references the affected standard. Re-issues are handled at the next minor release with full notification to affected members.
Addition of a new entry — Register Addition Request. Proposals to amend CIAO content with reference to a source standard not yet in the Register are reclassified as Register Addition Requests. Addition follows three sequential steps: (a) the patented multi-framework mapping methodology is applied to the candidate standard to produce its normalized cross-mapping with the entire existing CIAO content; (b) the new entry is added to the Register at the next scheduled release event; (c) existing CIAO documents are progressively re-rendered to incorporate the new mappings across one or more subsequent minor releases. The expansion is eventually-consistent: the new standard enters the Register and operational use upon completion of step (b), with content re-rendering proceeding under the established release cadence rather than triggering an immediate major release. No individual submitter has standing to compel an immediate major release through a Register Addition Request.
Both pathways — re-issue and addition — produce entries in the Release Calendar change pipeline as Material changes. Additions are also recorded in the version history of this Register itself, and the affected-document re-rendering work is tracked across minor release events until the new entry’s mapping coverage is complete across the corpus.
Part of the CIAO Standard architecture — see Standard Architecture & Tier Content Depth for the canonical domain spine and tier-by-tier content ladder.