Start here

The hierarchy

Cybersecurity documentation is a stack, and each layer depends on the one above it.

Layer	Answers	Changes	Example
Policy	What does management intend?	Rarely (3–5 years)	"Access to information systems is granted on the basis of business need and revoked when that need ends."
Standard	What specifically is required?	When laws, contracts or technology change	"Remote access requires multi-factor authentication. Privileged accounts are reviewed every 90 days."
Control	What is in place to meet the standard?	With the technology	Conditional-access policy enforcing MFA; quarterly access review in the identity platform.
Procedure	Who does what, when, how?	Often (a living document)	"On the first working day of each quarter, the IAM lead exports privileged accounts, sends to owners, records approvals in the review log."
Evidence	Did it happen?	Continuously	The completed review log, with dates and approver names.

Auditors and assessors work up this stack from the bottom. They look for evidence, ask which procedure produced it, check that the procedure implements a standard, and confirm the standard is authorised by a policy. A gap anywhere is a finding.

Policies vs standards vs procedures

The three words get used interchangeably and it causes real problems. The test is simple.

• If a sentence could be signed by the board and still be true in three years, it belongs in a policy.
• If a sentence contains a number, a technology, or a "must", it belongs in a standard.
• If a sentence contains a role and a verb in sequence, it belongs in a procedure.

Our policies-and-standards products keep policy and standards as separate documents for this reason. Merging them means every technology change forces a board re-approval, and every board-level statement gets buried under technical detail nobody reads.

Why it has to be written down

Three reasons, in order of how often they bite.

1. Someone external will ask. Customers, insurers, regulators, certification bodies and assessors all ask for documentation before they ask for anything else. "We do it, we just haven't written it down" is a finding in every framework.
2. Consistency. A control that lives in one person's head is performed one way by that person and not at all when they are on holiday.
3. Defensibility. After an incident, the question is whether the organisation exercised reasonable care. Documented, followed and evidenced controls are the answer. Undocumented ones are not.

Choosing a framework

Usually you do not choose; something chooses for you. Work through these in order.

If this applies to you	You are probably aligning to	Start with
US defence supply chain, handling CUI	NIST SP 800-171 R3 / CMMC Level 2	800-171 & CMMC Programme
Customers ask for an ISO certificate, or you sell internationally	ISO/IEC 27001:2022	ISO 27001 Policies & Standards
SaaS or service provider to US enterprises	SOC 2	SOC 2 Policies & Standards
You take card payments	PCI DSS v4.0.1 (plus whatever else applies)	PCI DSS Policies & Standards
EU financial entity, or essential/important entity under NIS2	DORA / NIS2 (often on top of ISO 27001)	NIS2 & DORA Set
US federal system, FedRAMP-adjacent	NIST SP 800-53 R5	800-53 Policies & Standards
Nothing mandates a framework; you want a sensible structure	NIST CSF 2.0	CSF 2.0 Policies & Standards
Small organisation, asked for "your policies"	Cyber Essentials / common questionnaires	Core Fundamentals Set

Several apply? That is normal. Pick the most demanding one as the structure and use the mapping workbooks (included in every policies-and-standards set) to show coverage of the rest. The framework guides compare them in more detail.

Which product first

Policies and standards first, always. They define the vocabulary everything else uses. Then, in the order assessors tend to ask:

1. Risk Management Programme: every framework asks for the risk assessment behind the controls.
2. Incident Response & Business Continuity: the second-most-requested document after the policy set.
3. Procedures Library: once policies and standards are settled, procedures make them operational.
4. Then whichever programme your obligations demand: privacy, vulnerability management, supply chain, AI governance.

The bundles package these sequences.

Keeping it current

Documentation ages at different rates. Policies should hold for 3–5 years. Standards need an annual review and change when a law, contract or major technology changes. Procedures change whenever the team, tools or process change, which for most organisations is several times a year. Build the review into the document register (each set includes one) and treat a procedure that has not been touched in 18 months as probably wrong.

Every purchase includes 12 months of updates: when we revise a set for a new framework edition or regulatory change, you get the new version by email.