Security Policies: Turning Security Principles Into Rules

Imagine an office building where everyone is free to do whatever they want.

Employees can walk into any room, use any computer, take any document and change whatever they like.

There might be expensive locks and CCTV cameras, but without some basic rules, nobody really knows what people are supposed to be doing.

Now imagine the same building has clear rules:

  • Only authorised people can enter the server room.
  • Visitors must be accompanied.
  • Staff must wear their ID badges.
  • Sensitive documents must be stored securely.
  • Lost keys must be reported.
  • Security incidents must be reported immediately.

These rules provide a framework for how people are expected to behave.

Cybersecurity policies perform much the same function for an organisation’s information and technology.

A security policy defines what an organisation expects, permits and prohibits in order to protect its people, information, systems and services.

Policies turn security objectives into organisational rules.

Why Do We Need Security Policies?

Technical controls are important – Firewalls, MFA, encryption, EDR, access controls and other technologies all go a huge way to protecting an organisation.

But technology alone cannot answer questions such as:

  • Who is allowed to use company systems?
  • What should employees do with sensitive information?
  • Who is responsible for approving access?
  • What should happen when someone leaves the organisation?
  • What should employees do if they suspect a phishing attack?

These are organisational questions, and policies provide the answers.

Policies Provide Direction

Without policies, security decisions can become inconsistent.

Each person makes their own decision as to how they can work. Some people may make good decision, whilst other may not.

A policy establishes a common expectation of how everyone should work.

Policies Set Expectations

A policy answers questions such as

“What are we expected to do?”

For example:

  • “Employees must use MFA when accessing corporate systems.”
  • “Company information must only be stored on approved corporate systems.”
  • “Security incidents must be reported immediately.”

These statements establish expectations across the organisation.

Policies Establish Accountability

Policies also establish responsibility. they define who is responsible for things, services, decisions, etc.

This is important because security is not simply the responsibility of the IT department.

Everyone has a role to play.

Policies Reduce Ambiguity

Consider an employee who receives an email containing a suspicious attachment.

Without a policy they may not know what they are supposed to do with it.

With a policy that states something like “The organisation’s policy says suspicious emails must be reported to the security team and must not be opened.” The staff member knows exactly what to do.

The policy removes uncertainty.

Policies Support Risk Management

Policies are also a way of managing risk. An organisation may establish a policy requiring:

  • Data classification
  • Approved storage locations
  • Encryption
  • Access controls
  • Secure disposal
  • Staff training

These policies set out exactly how to avoid incidents, which is what managing risk is all about.

Policies Aren’t Just About Cybersecurity

Security policies will cover many different areas of an organisation.

For example:

  • People
  • Processes
  • Technology
  • Information
  • Physical security
  • Suppliers
  • Cloud services
  • Business continuity

Security is an organisational issue, not simply a technical one.

What Sort of Security Policies Should We Have?

There is no single list that is appropriate for every organisation. A small organisation may have a handful of broad policies, whereas a large organisation may have dozens or even hundreds.

The policies should reflect the organisation’s:

  • Size
  • Industry
  • Risks
  • Legal obligations
  • Technology
  • Customers
  • Business requirements

A useful starting point is to cover the major areas of security risk.

An Information Security Policy is often the overarching policy for the organisation as it establishes the organisation’s overall approach to protecting information.

It might cover:

  • Security responsibilities
  • Information protection
  • Access control
  • Incident management
  • Risk management
  • Compliance
  • Acceptable use
  • Monitoring

Think of it as the organisation’s high-level security direction.

The other policies will be drawn from the direction of this policy

Policies, Standards, Procedures and Guidelines

One of the most important distinctions is that these terms are not necessarily interchangeable.

  • The Policy defines what we must do
  • Standards define what specific requirements apply
  • A procedure describes how we do it
  • Guidelines define what is recommended
  • Technical controls are used to enforce them all

Policy

A policy establishes a mandatory organisational requirement.

For example:

Employees must use MFA when accessing corporate systems.

It establishes what is required.

Standard

A standard makes the policy more specific.

For example:

Corporate systems must use phishing-resistant MFA where technically supported.

It establishes a defined technical or operational requirement.

Procedure

A procedure explains how to perform something.

For example:

To enrol a new employee in MFA, the service desk must verify the employee’s identity, register the approved authenticator and confirm successful authentication.

It provides the steps.

Guideline

A guideline provides advice rather than necessarily imposing a mandatory requirement.

For example:

Employees should avoid accessing sensitive information over untrusted public Wi-Fi.

Guidelines can help people make good decisions where a rigid rule isn’t appropriate.

Why This Distinction Matters

Consider the following statement:

“All staff must use strong passwords.”

That’s not particularly useful as a policy requirement.

A more structured approach might be:

  • POLICY – Employees must use approved authentication mechanisms
  • STANDARD – Defines the minimum credential requirements.
  • PROCEDURE – Sets out how users create, change and recover credentials.
  • CONTROL – An approved identity platform enforces requirements.

Each layer has a different purpose.

Policies Should Be Based on Risk

Policies shouldn’t simply be copied from another organisation. The organisation should first understand its own risks.

This produces policies that address actual organisational needs, not generic issues.

Legal and Regulatory Requirements

Policies are often driven by legal and regulatory requirements. Depending on the organisation, these may include:

  • UK GDPR
  • Data Protection Act 2018
  • NIS2
  • PCI DSS
  • Sector-specific regulation
  • Contractual requirements

These requirements may influence what policies an organisation needs.

However:

Compliance is not the same thing as security.

Meeting a regulatory requirement doesn’t automatically mean that an organisation is secure.

Security Frameworks

Organisations don’t have to invent their security policies from scratch. There are numerous frameworks and sources of guidance that can help which have been built, and refined over many years by many organisations.

Some of the most commonly used include:

  • NIST Cybersecurity Framework
  • NIST Special Publications
  • ISO/IEC 27001
  • ISO/IEC 27002
  • CIS Controls
  • COBIT
  • UK National Cyber Security Centre guidance

These provide structures, principles and recommended practices that can inform policy development.

NIST Cybersecurity Framework

The NIST Cybersecurity Framework (CSF) provides a widely used way of organising cybersecurity activities.

Its current core functions are:

Policies can be created to support these areas.

For example:

PROTECT
  │
  ├── Access Control Policy
  ├── Authentication Policy
  ├── Data Security Policy
  └── Security Awareness Policy

ISO/IEC 27001

ISO/IEC 27001 provides requirements for establishing, implementing, maintaining and continually improving an Information Security Management System (ISMS).

It encourages organisations to take a structured, risk-based approach to information security. Policies form an important part of that management system.

ISO/IEC 27002

ISO/IEC 27002 provides guidance around information security controls.

It can help organisations understand the types of security controls that may be appropriate and therefore help inform the policies supporting those controls.

CIS Controls

The CIS Controls provide a prioritised set of cybersecurity safeguards. They can be particularly useful for organisations that want practical guidance on what security activities to implement.

UK NCSC Guidance

For organisations in the UK, guidance from the National Cyber Security Centre (NCSC) can also be extremely useful.

The NCSC provides guidance covering areas such as:

  • Passwords
  • MFA
  • Network security
  • Cloud security
  • Incident management
  • Device security
  • Supply-chain security
  • Zero Trust

This can provide practical guidance when developing organisational policies.

Frameworks Don’t Automatically Give You a Policy Though

This is an important point. An organisation shouldn’t simply copy a framework and call it a policy.

The framework provides the guidance, but the organisation needs to decide how that guidance applies to its own environment.

Who Writes Security Policies?

Security policies are often developed by security professionals, but they shouldn’t be written by the security team in isolation. Depending on the policy, contributors may include:

  • Security
  • IT
  • HR
  • Legal
  • Compliance
  • Senior management
  • Data protection specialists
  • Business owners
  • Physical security
  • Procurement

Different policies affect different parts of the organisation, so experts from those different parts must be involved in building those policies.

Senior Management Approval

Policies also need organisational authority.

A security team can write a policy that states “Everyone must use MFA.”

But who gives that requirement its authority?

Without appropriate authority, policies may simply become suggestions.

Every policy should also have an owner who is responsible for ensuring the policy doesn’t become outdated.

Technology and threats change. A policy written five years ago may no longer be appropriate.

Policies should therefore be reviewed periodically and whenever significant changes occur.

Policies Shouldn’t Be Too Long

A policy nobody reads isn’t particularly useful.

Policies should be:

  • Clear
  • Concise
  • Relevant
  • Understandable
  • Accessible

A policy aimed at developers may contain requirements around:

  • Secure coding
  • Code review
  • Dependency management
  • Secrets
  • APIs

A policy aimed at general employees may instead focus on:

  • Passwords
  • MFA
  • Phishing
  • Data handling
  • Device security

The language and level of detail should reflect the audience.

Communicating Policies

Creating a policy isn’t enough. People need to know that it exists, else what is its point?

Organisations might communicate policies through:

  • Intranet
  • Email
  • Training
  • Onboarding
  • Security awareness campaigns
  • Employee handbooks

Policy Acknowledgement

For important policies, organisations may require employees to acknowledge that they have read and understood them.

This can also provide evidence that the organisation communicated the requirement, which may be a component of compliance.

How Are Policies Enforced?

This is one of the most important questions.

A policy that says “Users must use MFA.” doesn’t actually turn MFA on.

Something needs to enforce the requirement.

Policies are therefore closely connected to security controls.

Technical Enforcement

Technology can automatically enforce many policies.

For example the password police is regularly enforced by technology that checks to see if the user supplied password meets the agreed upon policy for length, complexity, age, reuse, etc.

The user doesn’t get to choose whether the requirement applies – the system does.

Physical Enforcement

Policies aren’t only enforced using technology though – Physical controls can also enforce them.

For example a policy which states “Only authorised personnel may enter the server room.”

Can be enforced with:

  • Door locks
  • Access cards
  • Biometrics
  • Security guards
  • CCTV

Administrative Enforcement

Some policies are also enforced through organisational processes.

For example the policy which states “Employees must complete security awareness training.”

Is most commonly enforced via HR and management.

HR may create a series of security training sessions, and then management can ensure their staff attend the sessions.

Contracts Can Enforce Policies

A business is not only subject to its own policies – Supplier policies can be enforced through contracts.

For example A policy that states “A supplier must notify the organisation within a defined period if it suffers a security incident.” can be included in contractual terms.

Monitoring and Auditing

Just because a policy exists does not mean that it is necessarily effective. The organisation needs to know whether people and systems are actually following it.

This is where logging, monitoring and auditing become important.

Policy Violations

Suppose a policy states “Employees must not install unauthorised software.”

An endpoint management system could be used to detect any unauthorised applications on a users device. The organisation can then investigate why that application was installed and take appropriate actions.

Policy Exceptions

Sometimes a policy requirement cannot be followed.

For example a legacy application may not be able to support MFA.

Simply saying “The policy says MFA is mandatory.” doesn’t solve the problem. The organisation may need a formal exception process.

Compensating Controls

A policy exception may require a compensating control.

For example if a legacy system cannot support MFA, the organisation might instead:

  • Isolate the system
  • Restrict network access
  • Require access through a privileged access system
  • Increase monitoring
  • Restrict administrator access

What Makes a Good Security Policy?

A good policy should be:

  • Clear – People should understand what it means.
  • Specific – It should establish meaningful requirements.
  • Practical – It should be possible to comply with.
  • Risk-based – It should address genuine risks.
  • Enforceable – There should be a way to determine whether people are complying.
  • Measurable – Where possible, compliance should be measurable.
  • Owned – Someone should be responsible for maintaining it.
  • Reviewed – It should be regularly reassessed.

Measuring Policy Compliance

Compliance can be measured using metrics.

For example:

  • Percentage of devices encrypted
  • Percentage of staff completing training
  • Percentage of systems patched within policy
  • Number of policy exceptions
  • Number of unauthorised applications
  • Number of overdue access reviews

Policies and Security Culture

Policies are important, but security shouldn’t become a stick to beat people with

Good policies explain why the requirement exists.

For example:

“MFA is required because passwords can be stolen. MFA provides an additional barrier if a password is compromised.”

Understanding the reason makes compliance more likely.

Enforcement of the policy should be proportionate – Not every policy violation should result in the same response.

For example:

  • A minor infraction such as an accidental mistake could involve retraining or guidance
  • A serious infraction such as a repeated violation of policy should involve management action such as a verbal warning
  • A critical infraction such as deliberate abuse of a system should involve a formal investigation and potential disciplinary action

The objective should be to improve security, not simply punish people.

In Summary

Security policies define what an organisation expects people, processes and technology to do in order to protect its information and systems.

They provide:

  • Direction
  • Consistency
  • Accountability
  • Risk management
  • Clear expectations
  • A basis for security controls
  • A way to demonstrate compliance

Common policies include:

  • Information Security
  • Acceptable Use
  • Passwords
  • Access Control
  • MFA
  • Data Protection
  • Data Classification
  • Encryption
  • Remote Access
  • BYOD
  • Incident Response
  • Backup and Recovery
  • Patch Management
  • Logging and Monitoring
  • Security Awareness
  • Supplier Security
  • Cloud Security
  • Physical Security
  • Privileged Access

Policies can be informed by frameworks and guidance such as:

  • NIST Cybersecurity Framework
  • NIST Special Publications
  • ISO/IEC 27001
  • ISO/IEC 27002
  • CIS Controls
  • COBIT
  • NCSC guidance
  • Relevant legislation and regulation

The important lesson is that a policy document sitting on an intranet does not make an organisation secure.

A policy only becomes meaningful when it is:

understood → implemented → enforced → monitored → reviewed.

And that is why policies sit at the heart of a mature security programme.

A policy says what should happen. A control makes it happen. Monitoring tells us whether it actually happened.