How to Write an Information Security Policy

An information security policy is the apex document in your security governance hierarchy. It establishes the organisation's commitment to information security, defines the scope and objectives of the security programme, assigns roles and responsibilities, and provides the mandate for all subordinate policies, standards, procedures, and guidelines. The policy should be concise — typically 10-15 pages — and written for a management audience, not a technical one. It sets direction and boundaries; the technical implementation details belong in subordinate standards and procedures.

A well-structured information security policy contains the following components: a purpose statement explaining why the policy exists and what it aims to achieve; a scope definition clarifying which entities, systems, data, and personnel are covered; a statement of management commitment demonstrating that the management body has endorsed the policy; information security objectives aligned with business objectives; roles and responsibilities for information security governance; a risk management approach describing how security risks are identified, assessed, and treated; a policy compliance section covering monitoring, exceptions, and consequences for non-compliance; a definitions section clarifying key terms; and a document control section covering version history, review schedule, and approval records.

The policy hierarchy matters. The information security policy sits at Level 1. Level 2 comprises topic-specific policies (access control policy, data classification policy, incident response policy, acceptable use policy, etc.). Level 3 contains standards that prescribe specific technical requirements (encryption standards, password standards, hardening baselines). Level 4 contains procedures and guidelines that describe how to implement the standards operationally. This layered structure ensures that the apex policy can remain stable (reviewed annually) while lower-level documents are updated more frequently as technology and threats evolve. Each level should reference its parent, creating a traceable chain from operational procedure to board-approved policy.

DORA Article 9 requires financial entities to establish and implement ICT security policies, procedures, protocols, and tools that are proportionate to the entity's ICT risk exposure. For financial entities subject to both DORA and NIS2, the DORA requirements are more prescriptive and should be treated as the primary compliance target — a policy that satisfies DORA will generally satisfy NIS2, but not necessarily the reverse.

DORA Article 9(1) requires that the ICT security policies define the rules for protecting the confidentiality, integrity, availability, and authenticity of data and ICT assets. Article 9(2) requires that these policies be based on the ICT risk management framework established under Article 6. Article 9(3) requires that the policies be reviewed at least once a year, or after significant ICT-related incidents, and that lessons learned from testing (Article 24-27), participation in threat-led penetration testing (TLPT under Article 26), and actual incidents be incorporated into policy updates. Article 9(4) enumerates specific areas that the ICT security policies must address, including network security management (a), safeguards against intrusion and data misuse (b), access control and authentication (c), ICT change management (d), and patching and updating (e).

The DORA Regulatory Technical Standards on ICT risk management (RTS under Article 15) provide further detail on the expected policy content. Financial entities should structure their ICT security policy documentation to map directly to the RTS requirements, creating a traceable link between each RTS article and the corresponding policy provisions. This mapping serves dual purposes: it ensures completeness during drafting and provides a ready-made compliance matrix for supervisory examinations. The European Supervisory Authorities (ESAs) — EBA, ESMA, and EIOPA — have signalled that ICT security policy documentation will be a focus area in their initial DORA supervisory activities.

The most common failure in information security policy drafting is producing a document that satisfies auditors but is ignored by the organisation. A policy that no one reads, understands, or follows provides zero security value regardless of how comprehensively it addresses regulatory requirements. Write for your audience: the information security policy should be understandable by non-technical management body members, line managers, and general employees. Use plain language, avoid jargon where possible, and where technical terms are necessary, define them in a glossary section.

Structure the policy for readability and navigability. Use numbered sections with descriptive headings. Keep paragraphs short (3-5 sentences). Use tables for role-responsibility matrices. Include a one-page executive summary at the front of the document that a board member can read in three minutes. Cross-reference subordinate policies by name and document number so that readers can find the detailed guidance they need. Many organisations produce both a full policy document (for governance and audit purposes) and a condensed policy summary (for communication and training purposes) — this dual-format approach improves both compliance and awareness.

Avoid common drafting pitfalls. Do not copy-paste framework language verbatim into your policy — regulators and auditors can tell the difference between adopted language and understood language. Do not make the policy so aspirational that it describes a security programme you do not have — a policy that claims 24/7 SOC monitoring when you have no SOC creates a compliance gap, not a compliance document. Do not include technology-specific details that will become outdated — the policy should reference capabilities (e.g., 'multi-factor authentication for all remote access') rather than products (e.g., 'RSA SecurID tokens for VPN access'). And do not skip the exception management section: every policy needs a formal process for requesting, approving, documenting, and time-bounding exceptions, because real-world operations inevitably require them.