Teams that answer to several frameworks end up testing the same access review, backup or MFA setting three or four times, because nobody has written one control library that every framework can point at. This template is a working common control framework (CCF): a starter library of 24 controls written in testable form, each with an owner, frequency and evidence, and each mapped to CIS Controls v8.1, NIST CSF 2.0, NIST SP 800-53 Rev. 5, ISO/IEC 27001:2022 Annex A and the CSA Cloud Controls Matrix (CCM) v4.1. It also sets out the governance that keeps the library current. The concepts behind it, relationship types, choosing an anchor framework and where evidence reuse breaks, are in the Control Mapping Guide; this page is the library itself. It is written for GRC leads, compliance engineers and control owners.
How to use this template
- Replace text in square brackets, such as [Organisation], [GRC lead] and [system owner], with your own terms. Frequencies and thresholds in the library are NHI Mgmt Group's recommended starting values, not requirements of any framework. Where a framework sets a value, the template says so.
- The mappings are starting points written as "intersects with" relationships. Before you rely on them in an audit, confirm each one against the official sources: NIST's informative references in the Cybersecurity and Privacy Reference Tool, the CIS Controls Navigator, the CCM v4.1 workbook and your licensed copy of ISO/IEC 27001:2022.
- Add rows for frameworks we do not map here (SOC 2, PCI DSS, NIS2, DORA) as extra columns; keep one row per control.
- Keep the library in a spreadsheet, GRC platform or OSCAL catalogue. The table layout below converts directly into any of them.
- Delete controls that do not apply and record why in section 7; do not leave them in with "N/A".
1. Purpose
1.1 This common control framework defines the single set of security controls that [Organisation] operates, tests and evidences. Each external requirement in scope is met by mapping it to one or more controls in this library, so that each control is tested once and its evidence reused.
1.2 The library supports the following obligations: [list, for example ISO/IEC 27001:2022 certification, SOC 2 Type 2, a NIST SP 800-53 Moderate customer requirement, CSA STAR, CIS Controls IG2].
2. Scope
2.1 The library applies to all systems, cloud tenants, SaaS applications and third-party services that store or process [Organisation] data, and to human, service, workload and AI agent identities.
2.2 Framework versions in scope: CIS Controls v8.1; NIST CSF 2.0; NIST SP 800-53 Rev. 5 Release 5.2.0; ISO/IEC 27001:2022; CSA CCM v4.1. When a framework releases a new version, section 6 applies.
3. Roles and responsibilities
| Role | Responsibility |
|---|---|
| [GRC lead] (library owner) | Owns the library, mappings and change log; approves new controls and mapping changes |
| Control owner | Operates the control, produces evidence on the stated frequency, reports failures |
| Second mapper | Reviews a sample of at least 10% of new mappings and every claim of full equivalence |
| Internal audit or independent tester | Tests controls once per cycle; results are reused across frameworks |
| [CISO] | Approves the library annually and accepts residual gaps |
4. Control record structure
4.1 Every control in the library must have these fields:
- CCF ID: stable identifier, such as CCF-IAM-01. IDs are never reused.
- Control statement: who does what, to which population, how often, and what evidence results. A statement that cannot be tested is not accepted.
- Owner and operator: named role.
- Frequency: continuous, per event, or a stated period.
- Evidence: the artefact a tester inspects, and where it is stored.
- Population: the systems and identity types covered, including non-human identities.
- Mappings: external requirement IDs with relationship type and, for partial matches, the gap text.
- Parameters: framework-specific values that differ, recorded as deltas, for example a stricter review period required by one framework.
5. The control library
5.1 The 24 starter controls below cover the areas every framework in scope addresses. Frequencies are our recommended defaults.
| CCF ID | Control statement | Frequency | Evidence |
|---|---|---|---|
| CCF-GOV-01 | The information security policy and supporting standards are approved by [executive] and reviewed annually | Annual | Approved policy with version history |
| CCF-GOV-02 | Security roles and responsibilities are assigned and acknowledged | Annual | RACI and acknowledgements |
| CCF-RSK-01 | Security risks are assessed, recorded in the risk register with an owner and treatment, and reviewed | Quarterly | Risk register and review minutes |
| CCF-AST-01 | An inventory of hardware, software, cloud and SaaS assets is maintained with owner, and reconciled against discovery | Continuous; reconciled monthly | Inventory export and reconciliation report |
| CCF-IAM-01 | Access is granted only on an approved request recorded in the ticketing or IGA tool | Per event | Sample of requests with approvals |
| CCF-IAM-02 | Leaver access is disabled by the end of the last working day, driven by HR records | Per event | HR leaver list reconciled with disable dates |
| CCF-IAM-03 | MFA is enforced for all workforce, remote and administrative access; phishing-resistant methods for administrators | Continuous | Identity provider policy export and coverage report |
| CCF-IAM-04 | Privileged access is restricted to named roles, uses separate admin accounts and is granted just in time where supported | Continuous | Privileged account list mapped to people |
| CCF-IAM-05 | Access, including privileged and service accounts, is reviewed by the owner and excess access removed | Quarterly (privileged, service); twice yearly (others) | Signed review with removals |
| CCF-IAM-06 | Accounts inactive for 45 days are disabled; service accounts without a valid owner are disabled after owner confirmation | Weekly job | Dormancy report and job logs |
| CCF-NHI-01 | Service accounts, API keys, tokens and certificates have an owner, purpose and expiry, and secrets are held in an approved vault | Continuous; reviewed quarterly | NHI inventory and vault coverage report |
| CCF-CFG-01 | Systems are built from approved secure configuration baselines and drift is detected | Continuous | Baseline standards and compliance scan |
| CCF-CHG-01 | Production changes are approved, tested and recorded; emergency changes are reviewed afterwards | Per event | Change records sample |
| CCF-VUL-01 | Vulnerabilities are scanned, risk-rated and fixed within set timelines; known exploited vulnerabilities first | Weekly scan; monthly review | Scan reports and SLA metrics |
| CCF-MAL-01 | Endpoint protection is deployed on all supported assets and alerts are triaged | Continuous | Coverage against inventory |
| CCF-LOG-01 | Security logs from identity, endpoint, network and cloud sources are centralised and retained for [12] months | Continuous | Log source list and retention settings |
| CCF-MON-01 | Security alerts are monitored, triaged and escalated within defined times | Continuous | Alert metrics and sample tickets |
| CCF-NET-01 | Networks are segmented, inbound access is denied by default and management interfaces are not internet-exposed | Continuous; rules reviewed twice yearly | Firewall rule review |
| CCF-CRY-01 | Data is encrypted in transit and at rest with approved algorithms; keys are managed | Continuous | Configuration and key inventory |
| CCF-DAT-01 | Data is classified, retained and disposed of according to the data handling standard | Annual review | Data inventory and disposal records |
| CCF-BCK-01 | Backups run automatically, an isolated copy is kept, and restores are tested | Daily or weekly backups; quarterly restore test | Backup reports and restore test records |
| CCF-INC-01 | An incident response plan exists, roles are named and the plan is exercised | Annual exercise | Plan, exercise report and actions |
| CCF-TPR-01 | Suppliers are inventoried, risk-tiered and assessed before contract and periodically after | Per contract; annual for critical suppliers | Supplier register and assessments |
| CCF-AWR-01 | Staff complete security awareness training, including phishing and reporting | On joining and annually | Completion records |
6. Framework mappings
6.1 The table maps each control to four of the frameworks in scope. Add the ISO/IEC 27001:2022 Annex A references from your licensed copy of the standard as an extra column; we do not list them here. CIS Safeguard values for CCF-IAM-06 (45 days) and session and dormancy periods come from the CIS Controls Assessment Specification for v8.1. CCM entries show the control ID where we confirmed it from a published mapping, otherwise the CCM domain code; confirm the control ID in the CCM v4.1 workbook.
| CCF ID | CIS v8.1 | CSF 2.0 | SP 800-53 Rev. 5 | CCM v4.1 |
|---|---|---|---|---|
| CCF-GOV-01 | Safeguards 4.1, 7.1, 8.1 (process documents) | GV.PO-01 | PL-1, and the -1 control of each family | Confirm in workbook |
| CCF-GOV-02 | 17.1 | GV.RR-02 | PM-2 | Confirm in workbook |
| CCF-RSK-01 | None | GV.RM-01, ID.RA-05 | RA-3 | Confirm in workbook |
| CCF-AST-01 | 1.1, 2.1 | ID.AM-01, ID.AM-02 | CM-8 | UEM domain |
| CCF-IAM-01 | 6.1 | PR.AA-05 | AC-2 | IAM-06 |
| CCF-IAM-02 | 6.2 | PR.AA-05 | AC-2, PS-4 | IAM domain |
| CCF-IAM-03 | 6.3, 6.4, 6.5 | PR.AA-03 | IA-2(1), IA-2(2), IA-2(8) | IAM-14 |
| CCF-IAM-04 | 5.4 | PR.AA-05 | AC-6(2), AC-6(5) | IAM-09, IAM-10 |
| CCF-IAM-05 | 5.1 | PR.AA-05 | AC-2(j), AC-6(7) | IAM-08 |
| CCF-IAM-06 | 5.3 | PR.AA-01 | AC-2(3) | IAM domain |
| CCF-NHI-01 | 5.5 | PR.AA-01 | IA-5, IA-5(7), IA-9 | IAM-15, CEK domain |
| CCF-CFG-01 | 4.1, 4.2 | PR.PS-01 | CM-2, CM-6 | Confirm in workbook |
| CCF-CHG-01 | None | PR.PS-01 | CM-3 | Confirm in workbook |
| CCF-VUL-01 | 7.1 to 7.4 | ID.RA-01, PR.PS-02 | RA-5, SI-2 | TVM domain |
| CCF-MAL-01 | 10.1, 10.2 | DE.CM-09 | SI-3 | UEM domain |
| CCF-LOG-01 | 8.2, 8.9 | PR.PS-04 | AU-2, AU-11, AU-12 | LOG domain |
| CCF-MON-01 | 13.1 | DE.CM-01, DE.AE-02 | AU-6, SI-4 | LOG domain |
| CCF-NET-01 | 4.4, 4.5, 12.2 | PR.IR-01 | SC-7 | I&S domain |
| CCF-CRY-01 | 3.6, 3.10, 3.11 | PR.DS-01, PR.DS-02 | SC-8, SC-13, SC-28 | CEK domain |
| CCF-DAT-01 | 3.1 to 3.5 | ID.AM-07 | MP-6, SI-12 | DSP domain |
| CCF-BCK-01 | 11.1 to 11.5 | PR.DS-11 | CP-9, CP-10 | BCR domain |
| CCF-INC-01 | 17.1 to 17.3 | RS.MA-01 | IR-4, IR-8 | SEF domain |
| CCF-TPR-01 | 15.1 | GV.SC-07 | SA-9, SR-6 | STA domain |
| CCF-AWR-01 | 14.1 to 14.8 | PR.AT-01 | AT-2 | HRS domain |
6.2 Where one framework sets a stricter value than the library, record it as a parameter delta on the control rather than creating a duplicate control. Example: a customer contract requiring privileged access review every 30 days becomes a delta on CCF-IAM-05 for the systems in that contract.
6.3 When a framework publishes a new version, the library owner must import the official crosswalk (for example the CIS Navigator mappings or NIST's informative references) as a draft, compare it with the current mappings, and record changes in the change log within [60] days.
7. Exclusions and gaps
7.1 Any requirement in scope that no control meets must be recorded as a gap with an owner and a target date, or accepted as a risk by [CISO].
7.2 Any library control excluded for a system must be recorded with the reason. For ISO/IEC 27001 this feeds the Statement of Applicability; see the ISO 27001 Statement of Applicability Template.
8. Testing and evidence reuse
8.1 Each control is tested once per cycle using the most demanding test approach among the frameworks that map to it, so the result satisfies all of them. Sample sizes and periods follow the strictest mapped framework.
8.2 Evidence is stored once, tagged with the CCF ID, and referenced by each framework's audit request. Automated evidence collection should be used where available; see the Audit Evidence and Continuous Controls Monitoring Guide.
8.3 Evidence reuse does not apply where a framework requires a specific assessor or method, such as an independent assessor under SP 800-53 CA-2(1) or an accredited certification body for ISO/IEC 27001.
9. Review and approval
9.1 The library is reviewed annually and after any framework version change, major incident or significant change in scope. Approved by [CISO] on [date]. Version [1.0].
Implementation guidance
- Pick an anchor and write in your own words. Most organisations anchor on the framework they are audited against most often, then write controls in their own language. Copying one framework's wording makes mapping to the others harder.
- Start with 20 to 30 controls. A library of a few dozen well-written controls covers most of the overlap between these five frameworks. Add controls only when a requirement cannot be met by an existing one plus a parameter delta.
- Put identities in every population. Access controls written for "users" leave service accounts, API keys and AI agents out of reviews and dormancy checks. The template's CCF-NHI-01 and the populations in section 4 close that gap. See the Audit Readiness for AI Agents and NHIs guide.
- Record relationship types. NIST's OLIR approach distinguishes subset, superset, equal and intersects; most of the mappings above are "intersects with". Equivalence claims need a second reviewer. See the NIST OLIR Informative References Guide.
- Measure the library. Track: share of controls with a named owner and current evidence; number of external requirements mapped to at least one control; audit requests answered from existing evidence; and controls with failed tests open for more than 30 days.
- Common failure patterns. Controls written as copies of one framework's text; mappings with no relationship type; evidence stored per audit instead of per control; and libraries that are never re-mapped after a framework update, such as the move to CSF 2.0 or CIS v8.1.
- Tooling. A spreadsheet works for one or two frameworks. Beyond that, a GRC platform or an OSCAL catalogue and profiles make version changes manageable; NIST publishes SP 800-53 in OSCAL. See the GRC Platform Buyer's Guide.
Related NHI Mgmt Group resources: Control Mapping Guide · Cybersecurity Frameworks Compared Guide · NIST SP 800-53 to ISO 27001 Mapping Guide · NIST CSF to ISO 27001 Mapping Guide · CIS Controls Guide