Building the Policy Framework

Foundation's clause 5.2 covered what the standard requires of the top-level information security policy. This lesson is about actually building the full policy framework underneath it — the set of documents that turn a one-page policy statement into something specific enough for an employee or auditor to actually follow.

The three-tier hierarchy

Tier 1: Information Security Policy
        One document. Sets overall intent and commitment.
        Approved by top management (clause 5.2).
             │
             ▼
Tier 2: Topic-Specific Policies
        One per major area — access control, cryptography,
        acceptable use, backup, supplier security, incident
        management, etc. Each states WHAT must happen and WHY.
             │
             ▼
Tier 3: Procedures / Work Instructions
        Step-by-step HOW-TO documents for specific tasks —
        "how to provision a new user account," "how to respond
        to a suspected phishing email." Owned by whoever actually
        performs the task.

A common structural mistake is collapsing all three tiers into one giant document. A single 40-page "security policy" that mixes high-level intent with step-by-step technical instructions is hard to maintain (a small technical change forces a full policy re-approval by leadership) and hard to use (an employee looking for "how do I reset a password" has to wade through governance philosophy to find it).

Which topic-specific policies do you actually need?

There's no fixed universal list, but most organizations end up with policies roughly mapping to Annex A themes covered in Foundation:

The exact list should trace back to the organization's own risk assessment and SoA (Foundation, lesson 11) — not be copied wholesale from a generic checklist. An organization with no in-house software development has little need for a detailed secure development policy; one that outsources everything might instead need a much more detailed supplier security policy.

Implementable vs. aspirational statements

The most common quality failure in policy writing is aspirational language that can't actually be checked. Compare:

• ❌ Aspirational: "Passwords should be strong and changed regularly."
• ✅ Implementable: "Passwords must be a minimum of 12 characters, checked against a common-password blocklist at creation, and MFA is required for all accounts with administrative privileges."

The aspirational version gives an auditor (or an employee) nothing concrete to verify. The implementable version can be checked directly against a system configuration — exactly the kind of specific, evidence-checkable claim Foundation's SoA lesson emphasized. A good rule of thumb: if you can't imagine exactly what evidence would prove or disprove the statement, it's still aspirational.

Ownership and the review cycle

Every policy needs a named owner (usually the relevant control owner from the RACI built in lesson 1) responsible for keeping it current, and a defined review cycle — commonly annual, or triggered by a significant change (new technology adopted, a relevant law changes, a nonconformity reveals the policy was wrong). An un-reviewed policy is exactly the kind of stale documented information Foundation's clause 7.5 lesson flagged as a common finding.

The un-adapted template trap

Downloading a generic policy template and changing only the company name and logo is a very common shortcut — and a real audit risk. A template that references "our data center" for a fully cloud-hosted company, or mandates a control the organization doesn't actually use, signals to an auditor that the policy was never genuinely reviewed by anyone who understood the organization's actual environment. Every policy statement should be traceable to something real: a risk from the risk assessment, a control from the SoA, or an actual operational practice — not copied prose.