Index
This is substantial content — I'll give you the full picture for each policy: the governing clauses, Annex A controls operationalised, required content, and the cross-framework obligations each policy simultaneously satisfies. Start by establishing a consistent Confluence page template across all twelve (header block with version, owner, classification, review date, next review, and approval signature), then apply the content below.
Standard Confluence page template (apply to all 12)
Every policy page should open with a properties macro or a styled table containing: Document ID (e.g. POL-001), Version, Owner (role, not name), Approved by, Classification (Internal), Effective date, Next review date, and Related controls (links to the Control Mapping sheet). This metadata block is what an auditor looks at first.
1. Information Security Policy
Purpose: The master statement of intent — the single document that ISO 27001 clause 5.1 mandates top management sign.
Governing clauses: 5.1 (top management commitment), 5.2 (roles and responsibilities), 6.2 (information security objectives)
Annex A controls operationalised: 5.1, 5.2, 5.4, 5.36
Key content to include:
The policy must open with an unambiguous statement from the CEO or equivalent confirming that information security is a business priority and that the organisation is committed to the requirements of ISO 27001. This is the only policy that legally requires a named executive signature — without it, the management system has no foundation.
Define the scope: which legal entities, sites, systems, and services are in scope. Be precise. If your Confluence ISMS space covers only the UK entity, say so. Scope ambiguity is the most common reason audits fail at stage one.
State the five to seven information security objectives the organisation will measure annually (clause 6.2 requires these to be measurable). Examples: 99.9% uptime for critical systems, zero critical unpatched vulnerabilities beyond 14 days, 100% staff security training completion. These objectives must be monitored — link to your audit and evidence section.
Commit to providing adequate resources (clause 7.1) and to continual improvement (clause 10.1).
Cross-framework obligations satisfied: NIST 800-171 3.12.4 (documented requirements); DEFSTAN 05-138 §Governance P1; forms the governance wrapper that gives CMMC Level 1 self-attestation its legal backing.
2. Acceptable Use Policy
Purpose: Defines what employees, contractors, and third parties may and may not do with the organisation's information assets and systems.
Governing clauses: 7.5 (documented information), 8.1 (operational control)
Annex A controls operationalised: 5.10 (acceptable use), 5.15 (access control — policy level), 5.37 (documented operating procedures), 6.2 (terms of employment), 6.6 (NDAs)
Key content to include:
Open with a scope statement that explicitly covers all devices (corporate and personally-owned where BYOD is permitted), all networks (corporate, home, public), all data (regardless of classification), and all staff including contractors and agency workers.
Permitted uses should be stated positively: corporate systems are provided for business purposes; reasonable personal use during non-working hours is permitted provided it does not compromise security.
Prohibited activities must be explicit and non-exhaustive (use "including but not limited to"): installing unlicensed software, connecting unapproved devices to the corporate network, sharing credentials, circumventing security controls, accessing or downloading content that is illegal or offensive, using corporate accounts for personal social media, and connecting to corporate systems via unsecured public Wi-Fi without an approved VPN.
Include a monitoring and privacy notice — this is a legal requirement under UK GDPR Article 88 and the Employment Practices Code. State that the organisation monitors network traffic, email, and device activity for security purposes, and that users have no expectation of privacy on corporate systems.
Require that all staff sign the AUP at onboarding and annually thereafter. The signed record is evidence for CMMC Level 1 attestation.
Cross-framework obligations satisfied: CMMC Level 1 AC.L1-3.1.1, AC.L1-3.1.2 (authorised use); Cyber Essentials User Access Control domain; NIST 800-171 3.1.1, 3.1.2; DEFSTAN 05-138 §Access P1.
3. Access Control Policy
Purpose: Establishes how access to information, systems, and facilities is granted, managed, reviewed, and revoked.
Governing clauses: 6.1.2 (risk treatment — access as a control), 8.1 (operational control)
Annex A controls operationalised: 5.15, 5.16, 5.17, 5.18, 5.3 (segregation), 8.2 (privileged access), 8.3 (information access restriction), 8.5 (secure authentication)
Key content to include:
State the governing principle: access shall be granted on the basis of least privilege and need-to-know. No user shall have more access than is required to perform their role.
Identity management requirements: Every individual must have a unique user account. Shared accounts are prohibited except for designated service accounts, which must be individually registered and approved. Generic or departmental accounts must be removed.
Provisioning and de-provisioning: Access requests must be formally approved by the data owner and line manager before access is granted. On termination or role change, access must be revoked within one working day (same day for involuntary leavers). This timeline is the most commonly failed control in CMMC and DEFSTAN assessments — be explicit.
Authentication standards: Define minimum password complexity (length ≥12 characters, no reuse of last 12), session timeout (≤15 minutes idle), and account lockout (after five failed attempts). Multi-factor authentication is mandatory for: all remote access, all privileged (admin) accounts, and all cloud services storing CUI or personal data.
Privileged access management: Administrator accounts must be separate from day-to-day accounts. Privileged sessions should be recorded where technically feasible. Break-glass emergency accounts must be documented, sealed, and subject to audit on each use.
Access review: All access rights must be formally reviewed quarterly for privileged accounts and annually for all other accounts. The review record is a mandatory evidence item for ISO 27001 Annex A 5.18, NIST 3.1.x, and CMMC Level 1.
Cross-framework obligations satisfied: CMMC Level 1 AC.L1-3.1.1, AC.L1-3.1.2, IA.L1-3.5.1, IA.L1-3.5.2; Cyber Essentials User Access Control domain (fully); NIST 800-171 3.1.1–3.1.6, 3.5.1–3.5.11; DEFSTAN 05-138 §Access P1.
4. Data Classification Policy
Purpose: Establishes how the organisation classifies, labels, and handles its information assets according to their sensitivity and value.
Governing clauses: 6.1.2 (risk treatment), 8.1 (operational control)
Annex A controls operationalised: 5.9 (asset inventory), 5.12 (classification), 5.13 (labelling), 5.14 (information transfer)
Key content to include:
Define the classification scheme. A four-tier scheme aligns best with both UK government classifications and the NIST CUI requirements: Public (approved for external release), Internal (business use only), Confidential (restricted to named individuals or teams), and Restricted (equivalent to CUI/Official-Sensitive — subject to the most stringent controls). If you handle actual UK government classified information, align to the Government Security Classification (GSC) scheme: Official, Official-Sensitive, Secret, Top Secret.
For each classification level, define the handling requirements across: storage (encryption requirements), transmission (permitted channels, encryption in transit), printing (permitted printers, handling of hard copies), disposal (shredding standard, digital sanitisation), and sharing (with whom, under what conditions).
CUI identification is specifically important for NIST 800-171 and CMMC compliance. Define which of your information categories constitute Controlled Unclassified Information — typically: export-controlled technical data, proprietary defence programme information, personally identifiable information in a government context. These categories must be handled under the Restricted classification tier at minimum.
The classification policy should include a decision flowchart for employees to self-classify new documents. This is what makes the policy usable rather than decorative.
Cross-framework obligations satisfied: CMMC Level 1 AC.L1-3.1.22 (CUI on public systems); NIST 800-171 3.8.1, 3.8.2; DEFSTAN 05-138 §Data Handling P2; underpins all CUI obligations across the CMMC programme.
5. Incident Management Policy
Purpose: Defines how the organisation identifies, reports, classifies, responds to, and learns from information security incidents.
Governing clauses: 6.1 (risks and opportunities), 10.1 (continual improvement — incidents as improvement drivers)
Annex A controls operationalised: 5.24, 5.25, 5.26, 5.27, 5.28, 6.8
Key content to include:
Define what constitutes an information security incident versus a security event: an event is any observable occurrence (a failed login, a suspicious email); an incident is an event that has actually compromised or threatens to compromise confidentiality, integrity, or availability. This distinction matters because NIST and CMMC require incident reporting (for confirmed incidents) but not event reporting.
Reporting obligations: All staff must report suspected incidents immediately via a documented channel (dedicated email, helpdesk ticket, or direct call to the security team). The no-blame culture statement belongs here — employees should be encouraged to report without fear of disciplinary action for good-faith reports.
Severity classification: Define at least three levels — Critical (active breach, data exfiltration in progress, ransomware), Significant (confirmed unauthorised access, lost device containing sensitive data, third-party breach affecting your data), and Minor (policy violation, suspicious but unconfirmed activity, accidental data sharing). Each level must have a defined response time, escalation path, and notification obligation.
External reporting obligations must be explicit: UK GDPR Article 33 requires notification to the ICO within 72 hours of discovering a personal data breach. DEFSTAN 05-138 and MOD contracts typically require notification to the MOD Cyber Incident Response team. NCSC's CISP is the recommended channel for significant incidents. CMMC incidents involving CUI may trigger DFARS 252.204-7012 72-hour reporting to DoD.
Post-incident review: Every Critical and Significant incident must have a documented post-incident review within five working days. The lessons-learned output must feed into the corrective action register (clause 10.1).
Cross-framework obligations satisfied: NIST 800-171 3.6.1, 3.6.2, 3.6.3 (fully); DEFSTAN 05-138 §Incident Mgmt P1; CMMC Level 1 has no specific IR practice, but incident response capability underpins the system integrity practices SI.L1-3.14.x; UK GDPR Article 33.
6. Business Continuity Policy
Purpose: Establishes the organisation's approach to maintaining critical operations and recovering information systems following a disruptive incident.
Governing clauses: 8.1 (operational planning), 6.1 (risk treatment)
Annex A controls operationalised: 5.29 (information security during disruption), 5.30 (ICT readiness for business continuity), 8.13 (backup), 8.14 (redundancy)
Key content to include:
Define the governing metrics that drive all BCM decisions: Recovery Time Objective (RTO) — the maximum tolerable downtime for each critical system — and Recovery Point Objective (RPO) — the maximum acceptable data loss measured in time. These must be defined for each critical system and approved by the board. Without board-approved RTOs, business continuity has no accountability.
The policy should mandate a Business Impact Analysis (BIA) conducted at least annually, identifying which processes and systems are critical to survival, what the financial and reputational impact of extended downtime is, and what the minimum viable operating capability is during recovery.
Backup requirements: The 3-2-1 rule must be stated — at least three copies of data, on two different media types, with one copy stored offsite (or in a geographically separated cloud region). Backups must be encrypted. Restoration must be tested quarterly — untested backups are not backups.
Activation criteria: The policy must define who has the authority to declare a business continuity event and activate the BCP. This is typically the CISO or a named senior manager. Ambiguity here costs hours during a real incident.
Testing requirements: Full BCP test at least annually; tabletop exercise at least six-monthly; DR failover test at least annually with documented results. Test records are mandatory evidence for ISO 27001 clause 9.1.
Cross-framework obligations satisfied: NIST 800-171 3.6.3 (IR contingency); DEFSTAN 05-138 §Incident Mgmt P2; provides the resilience capability that CMMC Level 2 assesses under IR.L2-3.6.3.
7. Supplier Security Policy
Purpose: Ensures that information security risks introduced through supplier and third-party relationships are identified, managed, and contractually addressed.
Governing clauses: 8.1 (operational control — supplier as operational risk)
Annex A controls operationalised: 5.19, 5.20, 5.21, 5.22, 5.23 (cloud services), 6.6 (NDAs)
Key content to include:
The policy must require a supplier register — a formally maintained record of all third parties with access to the organisation's information, systems, or premises. Each supplier entry should record: classification tier (critical, important, standard), data categories they access, contractual security obligations, last assurance review date.
Risk tiering: Suppliers must be classified by risk before engagement. A critical supplier (one with access to Restricted/CUI data, or who provides a service that if disrupted would cause a Critical BCI event) requires full security assessment, contractual security schedule, and annual review. A standard supplier (access to Internal data only, no system access) requires an NDA and self-assessment questionnaire.
Mandatory contract clauses: The policy must list the security obligations that must appear in every supplier contract: right to audit, incident notification obligation (aligned to your own 72-hour window), data handling and subprocessor restrictions, security standards the supplier must maintain (ISO 27001, Cyber Essentials, or equivalent), and obligations on secure deletion at contract end.
Cloud services: DEFSTAN 05-138 and NIST 800-171 both have specific requirements around cloud. For any cloud service handling Restricted/CUI data, the policy must require: UK or EU data residency confirmation, SOC 2 Type II report review, data processing agreement, and confirmation that the CSP holds Cyber Essentials Plus or equivalent.
Supply chain security (Annex A 5.21) is increasingly audited — the policy must address how the organisation assesses not just its direct suppliers but those suppliers' key subcontractors, particularly for ICT and software.
Cross-framework obligations satisfied: NIST 800-171 3.12.1, 3.12.4 (security assessment and requirements); DEFSTAN 05-138 §Supply Chain P1 and P2; ISO 27001 clause 8.1 operational control; UK GDPR Article 28 (processor agreements).
8. Risk Management Policy
Purpose: Defines the organisation's methodology for identifying, assessing, treating, and monitoring information security risks.
Governing clauses: 6.1.1 (actions to address risks and opportunities), 6.1.2 (information security risk assessment), 6.1.3 (information security risk treatment), 8.2 (risk assessment — operational), 8.3 (risk treatment — operational), 9.3 (management review input)
Annex A controls operationalised: 5.7 (threat intelligence as risk input), 5.35 (independent review), 5.36 (compliance review)
Key content to include:
The methodology section must define: the risk assessment approach (asset-based or scenario-based — for most SMEs, scenario-based is more practical), the likelihood scale (typically 1–5), the impact scale (1–5), the risk scoring matrix (likelihood × impact), and the risk appetite statement.
Risk appetite must be explicitly stated and board-approved. Example: "The organisation accepts residual risks scoring 1–4 (low). Risks scoring 5–9 (medium) require documented treatment plans. Risks scoring 10–25 (high/critical) require immediate treatment and board notification." Without a documented risk appetite, risk treatment decisions have no governance anchor.
Risk register requirements: The policy must mandate a live risk register containing for each risk: unique ID, description, affected asset(s), threat source, existing controls, inherent score, treatment decision (accept/mitigate/transfer/avoid), treatment actions with owner and due date, residual score, and review date. This register is reviewed at every management review meeting (clause 9.3).
Assessment cadence: Full risk assessment annually; triggered reassessment for significant changes (new system, new contract, major incident, threat intelligence change).
Cross-framework obligations satisfied: NIST 800-171 3.11.1, 3.11.2, 3.11.3 (risk assessment family — fully); DEFSTAN 05-138 §Risk Mgmt P1 and P2; forms the governance foundation that CMMC Level 2 System Security Plan (SSP) is built on.
9. Asset Management Policy
Purpose: Ensures all information assets are identified, owned, and protected appropriately throughout their lifecycle.
Governing clauses: 8.1 (operational control)
Annex A controls operationalised: 5.9 (inventory), 5.10 (acceptable use), 5.11 (return of assets)
Key content to include:
Define what constitutes an information asset: hardware (servers, laptops, mobile devices, network equipment), software (applications, operating systems, licensed tools), data (databases, file stores, cloud storage), services (SaaS, cloud platforms), and people in roles (as asset owners). The policy should require that every asset has a documented owner — a named role, not a team.
Asset register requirements: The register must capture: asset ID, description, location (physical or logical), owner, classification, and disposal date. For hardware, additionally capture: serial number, purchase date, warranty expiry, encryption status, and data sanitisation record at end-of-life. NIST 800-171 3.4.1 explicitly requires a system component inventory, and CMMC assessors check this directly.
Lifecycle requirements: Assets must be assessed before procurement (does this asset introduce risk?), registered on arrival, maintained through their operating life (patching, configuration management), and formally decommissioned (data sanitisation certified, asset register updated). There must be no shadow IT — all systems must be formally registered before being connected to the corporate network.
Software asset management is increasingly scrutinised: unlicensed software represents both a legal and security risk. The policy should require an approved software list and prohibit the installation of software not on that list — this directly satisfies Cyber Essentials' Secure Configuration domain.
Cross-framework obligations satisfied: NIST 800-171 3.4.1 (system component inventory); Cyber Essentials Secure Configuration domain; DEFSTAN 05-138 §Config Mgmt P1; CMMC Level 1 indirectly (all L1 practices assume you know what systems you have).
10. HR Security Policy
Purpose: Ensures that employees, contractors, and third parties understand their security responsibilities and that access is appropriately managed throughout the employment lifecycle.
Governing clauses: 7.2 (competence), 7.3 (awareness)
Annex A controls operationalised: 6.1 (screening), 6.2 (terms of employment), 6.3 (awareness and training), 6.4 (disciplinary process), 6.5 (responsibilities after termination), 6.6 (NDAs)
Key content to include:
Pre-employment: The policy must define the minimum screening standard for each role category. For roles with access to Restricted or CUI data, a minimum of BPSS (Baseline Personnel Security Standard) is required for UK government and defence work. The policy should state that employment offers for these roles are conditional on satisfactory screening completion.
Onboarding obligations: On day one, every new starter must complete: security awareness induction, sign the AUP, sign the NDA/confidentiality agreement, and have their access provisioned against a formal access request. The security team must be notified of every new starter before their start date.
Ongoing training: Annual mandatory security awareness training is required for all staff. This satisfies NIST 800-171 3.2.1 and 3.2.2. Role-specific training (e.g. secure coding for developers, phishing identification for finance) should be identified via the risk assessment. Training completion records are mandatory audit evidence.
Disciplinary framework: The policy must state that violations of information security policies may result in disciplinary action up to and including dismissal, and that criminal violations will be reported to law enforcement. The disciplinary process must be proportionate and aligned to the organisation's wider HR disciplinary policy.
Leavers: The leaver process is one of the most frequently failed controls. The policy must mandate: access revocation on the last working day (or immediately for involuntary leavers), asset return checklist, final reminder of ongoing confidentiality obligations, and update to the asset register and access review log. A leaver checklist embedded in your Confluence ISMS space, linked from this policy, is the most effective way to operationalise this.
Cross-framework obligations satisfied: NIST 800-171 3.2.1, 3.2.2 (awareness and training), 3.9.1, 3.9.2 (personnel security — fully); DEFSTAN 05-138 §Personnel P1; Cyber Essentials User Access Control domain (the leaver process component).
11. Cryptography Policy
Purpose: Defines the organisation's requirements for the use of cryptographic controls to protect the confidentiality, integrity, and authenticity of information.
Governing clauses: 8.1 (operational control)
Annex A controls operationalised: 8.24 (use of cryptography)
Key content to include:
State the approved cryptographic algorithms and key lengths. At minimum: AES-256 for symmetric encryption, RSA-2048 or ECDSA-256 for asymmetric, SHA-256 minimum for hashing, TLS 1.2 minimum for data in transit (TLS 1.3 preferred). Explicitly prohibit deprecated algorithms: MD5, SHA-1, DES, 3DES, RC4, SSL 2.0/3.0, TLS 1.0/1.1. This list is what your technical staff need to configure systems correctly and what an assessor will check during a NIST 800-171 or CMMC audit.
For NIST 800-171 and CMMC: FIPS 140-2 or FIPS 140-3 validated cryptographic modules are required for protecting CUI. If your systems operate within a US government contract scope, commercial-grade encryption alone is not sufficient — the modules themselves must be FIPS-validated. This distinction is often missed.
Key management requirements: The policy must cover key generation (approved tools only), storage (HSM or encrypted keystore — never in code), rotation schedule (at least annually for long-lived keys, immediately on suspected compromise), and revocation procedure. Key custodians must be named by role.
Encryption at rest requirements: Define which data stores require encryption at rest — at minimum: all laptops and mobile devices (full-disk encryption), all servers holding Confidential or Restricted data, all cloud storage holding the same, and all backup media.
Digital certificates: Define the approved Certificate Authorities, certificate validity periods (maximum 12 months from October 2026 per CA/Browser Forum), and the process for certificate renewal and revocation. Certificate expiry is a disproportionately common cause of outages and audit findings.
Cross-framework obligations satisfied: NIST 800-171 3.13.8, 3.13.10, 3.13.16 (encryption in transit and at rest — fully); DEFSTAN 05-138 §Boundary P2; partially satisfies Cyber Essentials Firewalls domain (encrypted management plane requirement).
12. Physical Security Policy
Purpose: Protects information processing facilities, equipment, and the physical environment from unauthorised access, damage, and interference.
Governing clauses: 8.1 (operational control)
Annex A controls operationalised: 7.1–7.14 (all physical controls), 5.9 (asset inventory — physical assets)
Key content to include:
Secure zones: Define the physical security perimeters your organisation operates — at minimum a reception/visitor zone, a general staff zone, and a secure zone for servers and sensitive processing. Each zone must have documented entry controls. Server rooms must require two-factor physical authentication (e.g. access card plus PIN) and must be restricted to named individuals only.
Visitor management: All visitors must sign in at reception with photo ID verified. A member of staff must escort them throughout their visit. Visitors must never be left unattended in any area beyond the reception zone. This directly satisfies CMMC Level 1 PE.L1-3.10.3.
Physical access records: Access logs must be maintained for all secure areas, retaining records for a minimum of 90 days. CCTV coverage of all entry points must be maintained with footage retained for 30 days minimum (longer for areas processing CUI or classified data). These records satisfy CMMC Level 1 PE.L1-3.10.4.
Clear desk and clear screen: All workstations must have an automatic screen lock after five minutes of inactivity. Sensitive documents must not be left unattended on desks. Physical documents classified as Confidential or above must be locked away when unattended. Whiteboards in meeting rooms must be cleared after use.
Equipment security: Laptop hard drives must be encrypted (policy cross-reference to the Cryptography Policy). Equipment taken offsite must be approved and recorded. Equipment must never be left unattended in vehicles. Portable storage media (USB drives) must be encrypted and must appear on the asset register — if your organisation does not need removable media, prohibit it outright (this is best practice for CMMC and DEFSTAN compliance and eliminates an entire threat category).
Disposal: All equipment must be formally decommissioned through the approved secure disposal process. Hard drives must be overwritten to DoD 5220.22-M standard or physically destroyed. A destruction certificate must be obtained and retained for any equipment holding Confidential or Restricted data.
Cross-framework obligations satisfied: CMMC Level 1 PE.L1-3.10.1, PE.L1-3.10.3, PE.L1-3.10.4, PE.L1-3.10.5, MP.L1-3.8.3 (all five physical/media CMMC L1 practices — fully); DEFSTAN 05-138 §Physical P1; Cyber Essentials Secure Configuration domain (clear screen); NIST 800-171 3.10.1–3.10.6, 3.8.3.
Confluence authoring guidance
Each of these twelve policies should live as its own page under the 01 · Policies section of your ISMS space, with the Scroll Content Manager configured so that all staff see the policy statements and their personal obligations, management see an additional governance context block (risk rationale, audit evidence requirements), and the security team see the full technical implementation detail and control references.
Label every policy page with its document ID and the controlling ISO 27001 clause number (e.g. pol-005, iso-5.24, iso-5.26) so the cross-framework control mapping table in your Reference Library can link directly to each policy. Schedule a Confluence page review reminder at 11 months from the effective date so no policy drifts past its annual review obligation — this is a mandatory ISO 27001 clause 7.5.3 requirement.