Article Summary
Every organisation that handles information needs documented security policies — not as a compliance formality, but as the mechanism that makes decision-making consistent and risk-controlled at scale. This article explains where policies come from, how they relate to each other, what separates a policy from a standard or a procedure, and the governance structures that give them teeth. It is the reference foundation for a ten-policy series covering the most critical domains in information security.
Why an Organisation Needs Policies
Every organisation makes decisions every day about how information is handled, who can access what, how systems are configured, and how incidents are managed. In the absence of documented policies, those decisions get made individually, inconsistently, and often without any reference to the organisation's risk appetite or legal obligations.
Two engineers in the same team will configure systems differently. Two managers will respond to the same security incident differently. Two vendors will be onboarded with completely different levels of scrutiny. That inconsistency is where risk lives, and it compounds quietly until something goes wrong.
They remove ambiguity from decisions that would otherwise be made differently by different people on different days. They give the organisation a documented baseline against which behaviour, systems, and third parties can all be measured.
Policies also serve a legal and regulatory function. When a regulator, an auditor, or a client asks how the organisation manages data, controls access, or handles a security incident, the answer starts with a policy. A documented, approved, reviewed, and communicated policy creates the foundation for demonstrating compliance. Without one, the organisation has nothing to point to except individual judgment calls made in the moment.
Beyond compliance, policies signal organisational maturity. An organisation that has clearly defined, consistently enforced policies communicates that it takes information security seriously. An organisation that cannot produce them communicates the opposite — and in regulated industries, in procurement processes, and in post-incident reviews, that difference matters enormously.
Where Policies Come From — The Hierarchy from Business to Policy
Information security policies do not exist in isolation. They sit at a specific layer in a hierarchy that starts with the organisation's business objectives and flows down through strategy, programme, and policy. Understanding that hierarchy is essential to writing policies that are grounded in reality rather than copied from a template that was never designed for the organisation using it.
The Policy Hierarchy
The relationship flows in one direction. Business objectives inform the strategy. The strategy informs the programme. The programme informs the policy framework. A policy that has no connection to a business objective, a strategic priority, or a programme control is a policy that exists for its own sake and will never be taken seriously by anyone who has to follow it.
A hospital's business objective is patient care, and its information security programme must reflect the risks that could disrupt that care — from ransomware encrypting clinical systems to unauthorised access to patient records. A fintech's business objective is financial transactions, and its programme must reflect the risks that could disrupt or compromise those transactions. Generic policies copied from the internet rarely survive contact with reality precisely because they were not derived from this chain.
How the Information Security Policy Sits at the Top of the Framework
Within the policy framework itself, there is also a hierarchy. The Information Security Policy — sometimes called the overarching or master information security policy — sits at the top. It expresses the organisation's overall commitment to information security, defines the scope of the framework, establishes the governance structure, assigns accountability at the senior level, and sets the principles that all subordinate policies must follow.
Every other policy in the framework is derived from the overarching Information Security Policy. The Access Control Policy derives from the principle that access to information should be restricted to authorised individuals. The Third Party Risk Management Policy derives from the principle that the organisation's information security obligations extend to parties acting on its behalf. The Incident Management Policy derives from the principle that security events must be identified, managed, and learned from systematically.
The overarching Information Security Policy should be a short document. It is not the place for procedural detail. It states intent, scope, principles, governance, and accountability. The detail lives in the subordinate policies, standards, guidelines, and procedures that sit beneath it.
The Difference Between a Policy, a Standard, a Guideline, and a Procedure
These four terms are frequently confused and frequently misused. Getting the distinction right matters because it determines how binding each document is, how often it changes, who owns it, and how it is governed.
Policy
States what the organisation requires. Mandatory, high level, approved by senior leadership. Changes infrequently because it reflects organisational intent, not implementation detail.
Standard
States how the policy requirement is met in specific, mandatory terms. May be technology-specific. Changes when technology or regulatory requirements change, without requiring the policy to change.
Guideline
Provides recommended approaches and best practices. Advisory, not mandatory. Supports the policy and standard, giving people discretion to apply judgment where the standard alone is not sufficient.
Procedure
Provides step-by-step instructions for completing a specific task in compliance with policy and standard. Operational and role-specific. Changes most frequently as systems and processes evolve.
Policies must not contain the level of detail that belongs in standards or procedures. When a policy becomes too prescriptive, it changes too often, becomes difficult to approve through governance, and conflates intent with implementation in a way that creates confusion about what is actually mandatory.
The Balance a Policy Must Strike
A policy that is too permissive fails to protect the organisation. A policy that is too restrictive fails the business. Both are real failure modes and both are common.
Over-controlled policies create friction that people work around. If the access control policy is so restrictive that developers cannot do their jobs, they will find unofficial ways to bypass it. A policy that nobody follows is worse than no policy at all because it creates the illusion of control without the substance, and it undermines the credibility of every other policy in the framework.
Under-controlled policies leave gaps that attackers, accidents, and auditors will find. A data classification policy that does not address cloud storage, personal devices, or third-party sharing in an organisation that routinely uses all three is a policy that does not reflect how the organisation actually operates.
How Often a Policy Should Change
Policies should be stable. They reflect the organisation's intent and principles, which do not change with every new technology, regulation, or threat. A policy that is rewritten every year signals it was written at the wrong level of abstraction.
The standard practice is to review policies annually and to update them when there is a material change in the organisation's risk environment, regulatory obligations, business model, or governance structure. What changes more frequently is the standards and procedures beneath the policy. When a new technology is adopted, the relevant standard is updated. The policy remains stable while the implementation layer evolves around it.
Every policy should carry a version number, a review date, an owner, and an approval authority. These are the mechanisms by which the organisation knows whether its policies are current, who is accountable for them, and when they were last examined by someone with authority to change them.
One Policy, Multiple Regulations
A common mistake organisations make is to create separate policies for each regulation they are subject to — a GDPR policy, a PCI DSS policy, an ISO 27001 policy. This approach creates duplication, contradiction, and maintenance overhead that grows with every new regulation.
The right approach is to maintain one policy per domain, written to reflect the organisation's own requirements and best practice, and then to incorporate regulatory obligations where they add specific requirements beyond the baseline. The mapping between policy requirements and regulatory obligations is maintained separately, typically in a controls matrix. This allows the organisation to demonstrate to any regulator exactly where in its policy framework their requirements are addressed.
Policy Ownership — Who Owns a Policy and What That Means
Every policy must have a named owner. Ownership is not a formality — it is accountability. The policy owner is responsible for ensuring the policy exists, reflects current requirements, is reviewed on schedule, and is communicated to those who need to follow it. A policy without a named owner belongs to nobody and will drift out of currency the moment the person who wrote it moves on.
Ownership means the policy owner understands the policy thoroughly, can explain and defend every requirement in it, monitors whether the organisation is actually complying, escalates violations, and drives the review process when the review date arrives.
Policy Reviewer, Steering Committee, and Segregation of Duties
A policy owner writing, reviewing, and approving their own policy is a governance failure. The same person who has operational responsibility for a domain cannot be the final authority on whether the policy governing that domain is adequate. That is a conflict of interest and a segregation of duties violation.
| Role | Responsibility | Who Typically Fills This |
|---|---|---|
| Policy Author | Drafts the policy with deep domain knowledge. | Policy owner or subject matter expert under their direction. |
| Policy Reviewer | Reviews for technical accuracy, regulatory completeness, feasibility, and alignment with the overarching policy. Must be independent of the author. | Legal Counsel, IT Director, Internal Audit — multiple reviewers from different functions. |
| Policy Approver | Formally approves the policy, giving it organisational standing. Authority level should match the scope and risk significance of the policy. | CISO, Chief Risk Officer, Steering Committee, or Board depending on scope. |
| Compliance Assessor | Independently assesses whether the organisation is actually complying with the policy over time. | Internal Audit function. |
Policy Versioning
Every policy carries a version number and a revision history. Versioning is the mechanism by which the organisation tracks what the policy said at any point in time, what changed, why, and who approved the change. Without it, the policy framework cannot support any regulatory or legal process that requires the organisation to demonstrate what its requirements were at a specific historical point.
Major version numbers — 1.0, 2.0 — indicate significant changes requiring full re-approval. Minor version numbers — 1.1, 1.2 — indicate clarifications or additions that do not change fundamental requirements. The revision history table records version number, date, description of change, author, and approver. This is the audit trail for the policy's lifecycle.
The Ten Policies This Series Will Cover
The following ten policies form the backbone of any information security management system. The series covers each in depth, including base requirements applicable to all organisations and industry-specific variations across fintech, healthcare, defence, energy, and consulting environments.