Security policy

A security policy sits at the top of a documentation hierarchy that security practitioners distinguish carefully: policies state intent and mandate ("what and why", approved by top management and relatively stable), standards make requirements concrete and mandatory ("passwords must meet these rules"), procedures give step-by-step instructions ("how"), and guidelines offer recommended but non-binding practice. Conflating these is a common failure - a "policy" full of technical specifics becomes obsolete quickly and needs board re-approval for trivial changes, while genuine mandate gets buried. In an ISO/IEC 27001 information security management system (ISMS), the top-level information security policy is required by clause 5.2, must be approved by top management, communicated and made available to interested parties, and reviewed at planned intervals; ISO/IEC 27002:2022 Control 5.1 (Policies for information security) expects it to be supported by topic-specific policies (access control, acceptable use, cryptography, incident management, and so on).

The policy set is the governance instrument that turns leadership intent into an auditable baseline. Every subordinate control, standard and audit criterion should trace back to a policy statement, which is what lets an auditor test not just whether a control exists but whether it implements a documented decision. Regulatory frameworks make top-management ownership explicit: NIS2 Article 20 places accountability for cybersecurity risk-management measures on management bodies and requires them to be trained, so the policy is no longer something IT owns alone. The document typically defines scope, roles and responsibilities (often against a RACI matrix), the risk-appetite statement it enforces, compliance obligations, enforcement and consequences for violations, and its own review cadence and owner.

Effectiveness depends on lifecycle discipline more than on wording. A policy that is written, approved and then never revisited becomes a "paper policy" - present for audit but disconnected from practice, which is arguably worse than none because it creates false assurance and, after an incident, evidence of a known-but-ignored control. Good practice ties each policy to a named owner, a review date (commonly annual or on significant change), version control, a record of employee acknowledgement, and measurable compliance so that exceptions are formally requested, risk-assessed and time-boxed rather than quietly tolerated.

Two misconceptions recur. First, that more policy is better: an over-long, unreadable policy set reduces compliance because staff cannot find or absorb it, so brevity and clarity are security properties. Second, that the policy itself provides protection; it is an administrative control that shapes behaviour and enables enforcement, but it mitigates risk only when backed by technical controls, training and monitoring that make the stated rules real. The security policy is thus the connective tissue between governance and the operational controls documented elsewhere, not a substitute for them.