Security Policy Development

Professor Sele: A security policy is the written expression of an organisation's commitment to security — who is responsible, what standards apply, and what procedures govern key activities. This module teaches you to develop policies that are actually used, rather than filed and forgotten.

Section 1 — What Is a Security Policy?

A security policy is a formal document that defines an organisation's approach to managing security risks. It establishes: the organisation's security objectives and principles; who is responsible for security at each level of the organisation; the standards that security operations must meet; the key procedures that govern security activities; and how compliance with the policy will be monitored and enforced.

A policy is not a procedure — it defines what must be achieved and why. Procedures define how it is done step by step. Both are necessary; they serve different purposes and audiences.

Section 2 — The Policy Development Process

Define the scope (what does the policy cover — physical security, personnel security, information security, or all three?). Identify the audience (who will implement this policy and what do they need to know?). Consult stakeholders (those who will implement the policy must have input — they identify practical constraints that desk-based writers miss). Draft (write in clear, unambiguous language — no jargon, no passive voice, no ambiguity). Review (legal review for compliance with applicable law; operational review for implementability). Approve (policies must be approved at the appropriate organisational level — typically by senior management or the board). Communicate (all staff affected by the policy must be briefed on its contents). Schedule review (establish when the policy will next be reviewed — typically annually and after every major incident).

Section 3 — Policy Writing Standards

An effective security policy document includes: Purpose — why does this policy exist? Scope — who and what does it apply to? Policy statements — the core principles and requirements, written as clear obligations (e.g. "All visitors must be verified against a pre-approved list before entry is granted"). Roles and responsibilities — who is accountable for what? Key procedures — reference to the detailed SOPs that implement the policy. Compliance and enforcement — what are the consequences of non-compliance? Review date and approval authority.

Section 4 — Common Policy Failures

Policies that are too long and complex to read. Policies written without operational input — implementable on paper but not in practice. Policies that have never been tested against real scenarios. Policies that are not communicated to the people who must implement them. Policies that are not reviewed after major incidents or operational changes.

Key Points

•A security policy defines what must be achieved and why — procedures define how
•Policy development: Scope → Audience → Consult → Draft → Review → Approve → Communicate → Schedule review
•Policies must be written in clear, unambiguous language and communicated to all affected staff
•Common failures: too complex, no operational input, not communicated, not reviewed
•Policies approved at the appropriate organisational level carry authority — those approved below that level do not

Field Note · Professor Sele

"I reviewed an access control policy for a government client that was 34 pages long, written in legal language, and had never been shared with the guards who were supposed to implement it. Their actual practice bore almost no relation to the written policy — they had developed their own informal procedures over time. I rewrote the policy in 6 pages, plain language, with a one-page summary for guard briefings. Compliance went from unmeasured and poor to monitored and high within 60 days. A policy that isn't read isn't a policy — it's a document."

Knowledge Check

An effective security policy must: