Security Policy Document Template

Supplies a policy structure that is short enough to be read and specific enough to be auditable.

Available soon

Format: Word
Size: 66 KB
Length: 21 pages
Version: 1.0
Updated: 28 Sep 2026

What's inside

Part 1 — How to write a policy with this template
Part 2 — The policy template
Part 3 — Worked example: an access control policy
Related documents
Adapting this template
Framework references
Definitions

Preview

The document from section 1, as you will receive it. Highlighted [[text]] is for you to replace; shaded guidance boxes are for you to delete before approval. The cover and document control pages are in the file.

Part 1 — How to write a policy with this template

A policy states what [[Organisation Name]] commits to and why. It is read by everyone it applies to, approved by executive management (the management body, or its delegate for the top policy), and tested by auditors against what people actually do. This template gives every policy the same sections in the same order, so a reader always knows where to look, and an auditor can test each requirement on its own.

The rules the template applies are in the Policy Framework Standard: in particular PF-01 (every document has one tier, stated on its first page), PF-04 (the sections, in order, and testable "must" statements) and PF-05 (the length limit). The steps from draft to publication are in the Policy Lifecycle Operating Procedure, which governs this template.

Part	What it is	What to do with it
Part 1 — this guidance	How to fill in the template well	Read it before you draft. Do not copy it into a policy.
Part 2 — the template	The identity block and the nine sections of a policy, with placeholders and guidance	Copy it into a new document for each policy; replace every [[placeholder]]; delete every guidance box.
Part 3 — a completed example	A short Access Control Policy for the example organisation (a software services company with 240 staff in two offices, an NIS2 important entity)	Use it to see the level of detail expected. Do not adopt it as it stands.

Use it for policies only

Every security document belongs to exactly one tier (PF-01). This template is for the top tier. A policy that tries to carry the settings, steps and advice of the tiers below it becomes long, goes out of date quickly and needs executive management to approve every small change. Put each kind of content in the tier made for it.

Tier	What it is for	Approved by	Reviewed at least every	Belongs here, for example
Policy	What the organisation commits to and why. Short, stable, written for everyone.	Executive management (the management body, or its delegate for the top policy)	12 months	"Every administrator account must use multi-factor authentication."
Standard	The specific, measurable requirements that make a policy real: settings, deadlines, minimums.	Head of Information Security (the document owner is consulted)	12 months	"Passwords are at least 14 characters." "Critical patches are applied within 14 calendar days."
Procedure	How a task is done, step by step, by named roles.	Head of Information Security (the process owner is consulted)	24 months	"To grant access: 1. The line manager raises a request … 2. The system owner approves …"
Guideline (not mandatory)	Recommended practice. Helpful, not mandatory; nobody is non-compliant for not following it.	Information security	24 months	"When working in a public place, sit where your screen cannot be overlooked."

A quick test for each sentence you are about to write into a policy:

If the sentence…	It belongs in	Leave in the policy
states a commitment the organisation must keep, whoever is in post	The policy	The commitment itself
gives a setting, a number or a product that could change within the year	A standard	"… to the standard set in the [[X Standard]]"
describes steps, forms, tools or who presses which button	A procedure	"… following the [[X Procedure]]"
recommends good practice nobody can be non-compliant with	A guideline	Nothing, or a pointer to it
explains background, threats or history	Training or the guideline	At most one sentence in Purpose

Guidance — delete before approval

A deadline that is central to what the policy promises can stay in the policy — "a leaver's access is disabled by the end of their last working day" is a commitment management should approve. A technical setting, such as a password length or a time-out, cannot: it changes too often and nobody outside IT can judge it.

The sections, in order

Every policy carries these nine sections, in this order (PF-04). Keep every heading even when a section is short; a heading with "None" under it tells the auditor you considered it.

#	Section	What goes in it	Typical length
1	Purpose	One paragraph: what this policy protects and why.	3–5 lines
2	Scope	Who and what it applies to, and anything excluded.	Half a page at most
3	Policy statements	Numbered 'must' statements; each one testable by an auditor.	8–20 statements
4	Roles and responsibilities	Who does what (RTS 2024/1774 Art 2(2)(d), (i)).	A short table
5	Compliance and consequences	How compliance is checked and what happens if it is not met (RTS Art 2(2)(e)).	2 short paragraphs
6	Exceptions	Deviations go through the Security Exception & Waiver Standard (P02); none by informal agreement.	2–3 lines (standard wording)
7	Related documents	The standards and procedures that implement it.	A short table
8	Definitions	Terms a reader might not know.	Only the terms needed
9	Document control	Owner, version, approver, approval date (RTS Art 2(2)(b)) and next review date.	The approval record and revision history

Why document control comes last, and also first. The full approval record and revision history sit in the last section, so that the policy text is what a reader meets first. The identity block at the top of the first page repeats the facts a reader and an auditor look for at once: the tier (PF-01), the owner (PF-02), the approver and the date of approval (PF-03; for DORA financial entities, RTS 2024/1774 Art 2(2)(b)), and the next review date (PF-06).

Writing testable "must" statements

The policy statements are the part an auditor tests (PF-04). A statement is testable when two people, looking at the same evidence, would agree whether it was met. Five habits get you there:

One requirement per statement. If a statement contains "and" between two different duties, split it. Each gets its own number, so each can be tested and reported on.
Name who must act. Start with a role or a group — "system owners", "every user", "the Head of IT" — never "it" or the passive "access will be reviewed".
Use "must" or "must not" for every requirement. "Should", "may", "where possible", "as appropriate" and "endeavour to" leave the reader free to decide; nobody can be found non-compliant with them. If something truly is optional, it belongs in a guideline.
Say what can be seen. A result an auditor can observe or count: an account, a record, a date. Replace "adequate", "appropriate", "regularly" and "promptly" with the observable thing or a frequency with its unit.
Know your evidence before you write it. For each statement, ask: what would I show an auditor to prove this is met? If there is no answer, the statement will fail its first audit.

Examples, before and after:

Not testable	Testable	Why
Access should be reviewed regularly.	System owners must review who has access to each system holding customer data at least every 6 months, and record the result.	A named role, a frequency with its unit, and a record to inspect.
Users must use strong passwords and protect their accounts.	Users must not share their passwords or other sign-in secrets with anyone, including IT staff. (Password length and complexity: in the access control standard.)	One duty per statement; the setting moves to a standard.
The organisation will endeavour to remove leavers' access promptly.	All of a leaver's access must be disabled by the end of their last working day.	"Endeavour" and "promptly" cannot fail; a date can.
Appropriate security measures must be in place for remote access.	Every sign-in from outside the office network must use multi-factor authentication.	"Appropriate" leaves the decision to the reader.
IT is responsible for ensuring backups are adequate.	The IT Operations Manager must make sure every system in the backup scope has a successful backup at least once every 24 hours. (Scope, retention and test frequency: in the backup standard.)	A named role and a result that can be checked in the backup logs.

Guidance — delete before approval

Number statements with a short prefix for the policy and a running number: ACP-1, ACP-2 … for an Access Control Policy. Never renumber at a revision: a statement that is removed keeps its number, marked "Withdrawn in version x.y", so audit findings, exceptions and training that cite "ACP-7" still point to the right text.

Aim for 8 to 20 statements. Fewer than 8 usually means the policy says too little to be tested; more than 20 usually means standard-level detail has crept in.

Version numbers and document IDs

Document ID. Give each policy an ID of a three-letter topic code, a hyphen, then a three-digit serial number (ISP-001) or a tier code (EXC-STD). Use the same short code as the prefix for its statement numbers (ACP-001 carries statements ACP-1, ACP-2 …). Name files [ID] [Title] v[major.minor], e.g. AUP-001 Acceptable Use Policy v2.1.

Version numbers follow the rule in the Policy Framework Standard:

Version	When
0.1, 0.2 …	While a new document is drafted and consulted on. Never published.
1.0	When a new document is first approved.
2.1 → 3.0	The major number rises for a material change. Needs consultation (PF-07), approval (PF-03) and re-acknowledgement (PF-09).
2.1 → 2.2	The minor number rises for a change that is not material, and for a review that changes nothing. Needs approval (PF-03), but not consultation or re-acknowledgement.

A change is material — a new major version, consulted on, approved and acknowledged again — if it:

adds, removes or changes a 'must' statement, or what anyone has to do to comply
changes who or what the document applies to (its scope)
changes a role, an approval authority, or the consequences of not complying
changes a value people work to: a deadline, frequency, threshold, strength or retention period
moves the document to a different tier

Only Policy-tier documents are acknowledged individually. An acknowledgement stays current through later minor versions, but not through a new major version: after a material change, everyone in scope acknowledges again within 30 calendar days of the new version's publication (PF-09).

Keeping it short

PF-05: "A policy is short enough to be read: at most [[4]] pages of body; detail belongs in standards and procedures." The limit is set in your Policy Framework Standard; replace the number there, not here. Body means the nine sections, without the identity block, the revision history and the definitions.

A policy nobody reads cannot be followed, and a policy people sign without reading gives a false picture of acknowledgement (PF-09). If a draft is over the limit, move content down a tier using the tables above, in this order: settings and numbers that could change in a year; steps; explanations; examples. Do not shrink the font or the margins.

Roles, compliance and consequences

Two sections are often left vague, and both are tested:

Roles and responsibilities says what each role must do under this policy, from executive management to every user. DORA financial entities must specify the responsibilities of staff at all levels (RTS 2024/1774 Art 2(2)(d)); a table from the most senior role to "everyone" does it.
Compliance and consequences says how compliance is checked — which records are sampled, how often, by whom — and what happens when the policy is not followed, for staff and for service providers (RTS Art 2(2)(e)). Point to your disciplinary procedure; do not restate it. Name one or two indicators you will report, so the policy can be monitored as well as audited.

Exceptions: one route, by reference

PF-10: "Deviations from any document are handled as security exceptions (P02), never by informal agreement." Every policy carries the same short Exceptions section, pointing to the Security Exception & Waiver Standard and its Security Exception Request & Approval Form. Do not describe an exception process inside a policy, and do not name a person who may grant exceptions "in special cases": that creates a second route that the Standard's approvals, expiry dates and register never see.

Use this wording, changing only the document reference:

Guidance — delete before approval

"Any deviation from this policy must be requested, assessed and approved under the Security Exception & Waiver Standard [[document ID]], using the Security Exception Request & Approval Form, before the deviation begins. An exception is time-limited and recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception."

Before you send it for approval

Every [[placeholder]] is replaced — search the file for two opening square brackets — and every guidance box is deleted.
The first page states the tier, owner, version and approver, and the approver is the one set for the Policy tier (PF-01 to PF-03). If a member of the approving body owns or wrote the policy, that member takes no part: the rest of executive management, without the member who owns or wrote it decides (see the Policy Development & Approval Responsibility Matrix).
The body is within the page limit (PF-05); the nine sections are present, in order, with their headings (PF-04).
Every statement uses "must" or "must not", names who acts, and you know the evidence that would show it is met.
The draft was consulted on with the people who must follow it, and with legal, HR and data protection where they are affected; comments and responses are recorded (PF-07).
The Exceptions section uses the standard wording (PF-10), and every document in Related documents exists and is Approved — or is listed as planned, with a date.
The Policy Register & Review Schedule has a row for the policy, and an acknowledgement is planned for everyone in scope: new starters within 10 working days of starting, everyone within 30 calendar days of the publication of a material change, and once a year, for every policy that applies to the person (PF-09, tracked in the Policy Attestation & Acknowledgement Tracker).

Part 2 — The policy template

Guidance — delete before approval

Copy everything from here to the end of Part 2 into a new document for each policy. Promote the headings one level (the section headings become Heading 1) and delete this box.

The identity block below goes at the top of the policy's first page. Its Status field takes only the words set in the Policy Framework Standard: Draft, In consultation, Awaiting approval, Approved, Review overdue, Retired.

[[Policy title]]
Document reference	[[e.g. ACP-001: see Version numbers and document IDs]]	Tier (PF-01)	Policy
Version	[[0.1 while drafting; 1.0 at first approval]]	Status	[[Draft / In consultation / Awaiting approval / Approved / Review overdue / Retired]]
Document owner (PF-02)	[[Role, not a person's name]]	Classification	[[Internal]]
Approved by (PF-03)	[[Executive management (the management body, or its delegate for the top policy)]]	Approval date RTS 2024/1774 Art 2(2)(b)	[[YYYY-MM-DD]]
Effective from	[[YYYY-MM-DD]]	Next review by (PF-06)	[[YYYY-MM-DD — at most 12 months after approval]]
Parent document	[[Information Security Policy, or 'none' for the top policy]]
Applies to	[[Everyone who must follow it, in one line — the detail is in Scope]]

Guidance — delete before approval

Approved by: the approver set for the Policy tier — executive management (the management body, or its delegate for the top policy) (PF-03). Record the body that approved it, not the person who signed on its behalf; the name and minute reference go in the approval record in Document control.

Next review by: no later than 12 months after the approval date (PF-06), and sooner if a trigger occurs — see Document control.

Owner: one role, not a committee and not a person's name, so the policy does not lose its owner when someone leaves (PF-02).

Purpose

This policy sets out how [[Organisation Name]] [[protects what, in a few words]], so that [[the outcome for the organisation, its customers or the people whose data it holds]].

Guidance — delete before approval

One paragraph: what this policy protects and why.

Say what the policy protects and why it matters to this organisation, in plain language. Leave out threat statistics and history. If the purpose runs past five lines, it is doing the work of a guideline.

Scope

This policy applies to:

People: [[e.g. all employees, contractors, temporary staff, and service providers with access to our systems or information]]
Information and systems: [[e.g. all information we hold or process, and every system, cloud service and device we own, rent or manage]]
Locations: [[e.g. every office, remote working and travel]]

Excluded: [[anything deliberately left out, and where it is covered instead — or "None"]]

Guidance — delete before approval

Who and what it applies to, and anything excluded.

Name service providers explicitly if they are in scope: a policy that is silent on them is usually read as not applying. An exclusion without a pointer to where the subject is covered is a gap an auditor will find.

Policy statements

[[ABC]]-1 [[Role or group]] must [[do one observable thing]] [[by when, or how often, with its unit]].

[[ABC]]-2 [[Role or group]] must not [[do one observable thing]].

[[ABC]]-3 [[Role or group]] must [[meet the requirement]] as set out in the [[Name of Standard]].

[[ABC]]-4 [[…]]

Guidance — delete before approval

Numbered 'must' statements; each one testable by an auditor.

Replace [[ABC]] with the policy's short prefix, as used in its document reference. One requirement per statement; "must" or "must not"; a named role; something an auditor can see. See Part 1 for examples.

Group the statements under short subheadings if there are more than about ten (for example: granting access; privileged access; leavers). Keep one number sequence across the groups.

Pointing to a standard (as in [[ABC]]-3) makes the standard's requirements part of what the policy requires, without the detail. The standard must exist and be Approved, or the statement cannot be met.

Roles and responsibilities

Role	Responsibilities under this policy
Executive management [[e.g. Executive Committee, or the management body]]	[[Approves this policy; receives the quarterly report on its compliance and acknowledgement; decides on …]]
Document owner [[e.g. Head of IT for the access control policy]]	[[Keeps the policy current and reviews it by its next review date or on a trigger; answers for its content; …]]
Information security [[e.g. Head of Information Security]]	[[Monitors compliance; assesses exceptions; reports …]]
[[Managers]]	[[Make sure their team members know and follow this policy; …]]
[[Everyone in scope]]	[[Read and acknowledge this policy within 10 working days of starting and when asked; follow it; report breaches to …]]
[[Service providers]]	[[Follow this policy where their contract requires; …]]

Guidance — delete before approval

Who does what (RTS 2024/1774 Art 2(2)(d), (i)).

Cover every level, from executive management to everyone in scope. Give each role only the duties this policy creates; general job descriptions do not belong here. Every role named in a statement should appear in this table.

Compliance and consequences

How compliance is checked. [[Role]] checks compliance with this policy [[how: e.g. by sampling records, reviewing reports from system X, or through internal audit]] [[how often, with its unit]]. The results are reported to [[executive management]] [[every quarter]] with these indicators: [[indicator 1, e.g. the share of leavers whose access was disabled by their last working day]]; [[indicator 2]].

Consequences of not complying. Failure to follow this policy may lead to [[access being suspended]] and to action under the [[disciplinary procedure]]. For contractors and service providers, it is treated as a breach of contract [[and may end the engagement]]. A suspected breach that may have harmed security is reported as an incident under the [[Incident Management Policy]].

Guidance — delete before approval

How compliance is checked and what happens if it is not met (RTS Art 2(2)(e)).

Name indicators you can actually produce. Two good indicators reported every quarter are worth more than ten that nobody collects. The acknowledgement coverage for this policy (PM-03) is reported for every policy and need not be repeated here.

Agree the consequences wording with HR and legal (PF-07). Point to the disciplinary procedure; do not restate it.

Exceptions

Any deviation from this policy must be requested, assessed and approved under the Security Exception & Waiver Standard [[document ID]], using the Security Exception Request & Approval Form, before the deviation begins. An exception is time-limited and recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception.

Guidance — delete before approval

Deviations go through the Security Exception & Waiver Standard (P02); none by informal agreement.

Keep this wording as it is (PF-10). Change only the document reference.

Reference	Document	Tier	Relationship
[[ISP-001]]	[[Information Security Policy]]	Policy	[[Parent policy]]
[[ABC-STD]]	[[Standard that sets the detail]]	Standard	[[Sets the detail that statements point to]]
[[ABC-PRC]]	[[Procedure that carries it out]]	Procedure	[[How the statements are carried out]]
[[EXC-STD]]	Security Exception & Waiver Standard	Standard	Handles every exception to this policy (PF-10)

Definitions

Term	Meaning in this policy
[[Term]]	[[Meaning, in one or two sentences]]
[[Term]]	[[Meaning]]

Guidance — delete before approval

Terms a reader might not know.

Define only the terms a reader of this policy might not know, or that the policy uses in a narrow sense. If your organisation keeps a single glossary, point to it and define here only what differs.

Document control

Approval record

Version	Approved by	Date (RTS Art 2(2)(b))	Evidence of approval	Next review by
[[1.0]]	[[Body that approved it]]	[[YYYY-MM-DD]]	[[e.g. minutes of meeting, reference and item]]	[[YYYY-MM-DD]]

Revision history

Version	Date	Author	Summary of change	Review type
[[0.1]]	[[YYYY-MM-DD]]	[[Role]]	[[First draft]]	[[—]]
[[1.0]]	[[YYYY-MM-DD]]	[[Role]]	[[First approved version]]	[[—]]
[[1.1]]	[[YYYY-MM-DD]]	[[Role]]	[[Reviewed; no change to any obligation]]	[[Scheduled / Triggered: which trigger]]

Review. This policy is reviewed at least every 12 months, and sooner after: a major incident, or an incident the document should have prevented; a material change to the organisation's activities, systems or suppliers; a change in law, regulation or a contract the document supports; an audit or assessment finding against the document; a significant change in the threats the document addresses (PF-06). A review that changes nothing is still recorded, as a new minor version with a new next review date. A material change is a new major version: consulted on (PF-07), approved (PF-03) and acknowledged again by everyone in scope within 30 calendar days of its publication (PF-09).

Publication. The current approved version is published at [[location everyone in scope can reach]]. Superseded versions are withdrawn and archived at [[archive location]] (PF-08).

Guidance — delete before approval

Owner, version, approver, approval date (RTS Art 2(2)(b)) and next review date.

The approval record is the evidence that the policy is in force (PF-03): keep the minute or signed record it points to. A policy with no recorded approval at the right level is counted in PM-02, documents in force without approval.

Changing a statement is a material change: a new major version that goes back through consultation and approval. Only the Policy Register & Review Schedule is the authoritative list of what is in force (PF-11); keep the version, dates and status here identical to it.

Part 3 — Worked example: an access control policy

This is a completed policy for the fictional example organisation used across the Security Policy Management pack: a software services company with 240 staff in two offices, an NIS2 important entity. It is the Access Control Policy in the example Policy Register & Review Schedule — ACP-001, version 2.0, owner Head of IT, approved 2026-01-20, next review 2027-01-20, status Approved — and covers topic PT-03, access control and identity. The documents it refers to are the example register's own.

Guidance — delete before approval

Note what the example leaves out: password lengths, which second factors are accepted, product names and the steps of a request. Those live in standards and procedures, so this policy has not needed a new version each time one changed.

In the example register, 229 of the 240 people in scope held a current acknowledgement of this policy as at 2026-09-30 (95.4%). PM-03, acknowledgement coverage, counts these pairs across every policy against the 95% target: acknowledged person-and-policy pairs ÷ in-scope pairs, across Policy-tier documents that require acknowledgement. That figure is reported, not written into the policy.

The organisation, its roles and dates are fictional. Delete this example from your adopted template.

Access Control Policy — EXAMPLE
Document reference	ACP-001	Tier (PF-01)	Policy
Version	2.0	Status	Approved
Document owner (PF-02)	Head of IT	Classification	Internal
Approved by (PF-03)	Executive Committee	Approval date RTS 2024/1774 Art 2(2)(b)	2026-01-20
Effective from	2026-01-20	Next review by (PF-06)	2027-01-20
Parent document	ISP-001 Information Security Policy
Applies to	Everyone with access to the Company's systems or information: all 240 staff, contractors and service providers

Purpose

This policy makes sure that only the right people can use the Company's systems and information, with only the access their work needs, and that access ends as soon as it is no longer needed. It protects the customer data and the software services the Company runs for its clients, and the Company's own operations. (EXAMPLE)

Scope

People: all 240 staff, contractors and temporary staff, and every service provider with access to the Company's systems or information.
Information and systems: every system, cloud service and device the Company owns, rents or manages, including the environments it operates for customers.
Locations: both offices, remote working and travel.

Excluded: customer-owned systems where the customer manages access; the Company's staff follow the customer's rules there, as the contract sets. Physical access to the offices is covered by the building access arrangements, not this policy. (EXAMPLE)

Policy statements

ACP-1 Every user account must belong to one named person. Shared or generic accounts must not be used to sign in, except service accounts recorded with a named owner.

ACP-2 Access must be granted only on a request approved by the person's line manager and, for systems holding customer data, by the system owner, following the Joiner, Mover, Leaver Procedure (JML-PRC).

ACP-3 System owners must define, for each system they own, the access each role needs. Access must not be granted beyond it without an approved exception.

ACP-4 Every sign-in from outside the office networks, every administrator account and every sign-in to a system holding customer data must use multi-factor authentication.

ACP-5 Administrators must carry out administration only from a separate administrator account that is used for nothing else.

ACP-6 Access that a person's new role does not need must be removed within 5 working days of their move to that role.

ACP-7 All of a leaver's access must be disabled by the end of their last working day.

ACP-8 System owners must review who has access to each system holding customer data at least every 6 months, and record the review and its result.

ACP-9 System owners must review who has administrator access to each of their systems at least every 3 months, and record the review and its result.

ACP-10 Users must not share a password or other sign-in secret with anyone, or place one in source code, email or chat.

ACP-11 A service provider's access must be named to individuals, limited to the systems and period in its contract, and removed when the work ends.

Roles and responsibilities

Role	Responsibilities under this policy
Executive Committee	Approves this policy; receives the quarterly report on its compliance and acknowledgement.
Head of IT	Owns this policy (reviews it by its next review date and on any trigger); runs the account and access services that carry it out.
Head of Information Security	Checks compliance each quarter; assesses exceptions; reports to the Executive Committee.
System owners	Define role access (ACP-3); approve access to their systems (ACP-2); carry out access reviews (ACP-8, ACP-9).
Line managers	Request access for their staff, and its removal on a move (ACP-6); tell HR of leavers in time for ACP-7.
HR	Notify joiners, movers and leavers under the JML-PRC procedure.
Everyone in scope	Acknowledge this policy within 10 working days of starting and once a year; use only their own account; keep sign-in secrets to themselves (ACP-10).
Service providers	Follow this policy as their contract requires; tell the Company when a named individual no longer needs access.

Compliance and consequences

How compliance is checked. The Head of Information Security checks compliance every quarter, by comparing the quarter's leavers with the dates their accounts were disabled (ACP-7), checking that access reviews were recorded on time (ACP-8, ACP-9), and sampling 10 accounts on systems holding customer data against the role access defined for them (ACP-1, ACP-3). The results go to the Executive Committee every quarter, with two indicators: the share of leavers disabled by their last working day, and the share of access reviews completed on time. (EXAMPLE)

Consequences of not complying. Failure to follow this policy may lead to access being suspended and to action under the Company's disciplinary procedure. For contractors and service providers, it is a breach of contract. A suspected breach that may have harmed security is reported as an incident under the Incident Management Policy (INC-001).

Exceptions

Any deviation from this policy must be requested, assessed and approved under the Security Exception & Waiver Standard (EXC-STD), using the Security Exception Request & Approval Form, before the deviation begins. An exception is time-limited and recorded in the Security Exception Register. Agreement by email, in a meeting or by a manager is not an exception.

Reference	Document	Tier	Relationship
ISP-001	Information Security Policy	Policy	Parent policy
JML-PRC	Joiner, Mover, Leaver Procedure	Procedure	How access is requested, changed and removed (ACP-2, ACP-6, ACP-7)
EXC-STD	Security Exception & Waiver Standard	Standard	Handles every exception to this policy
AUP-001	Acceptable Use Policy	Policy	What users may do with the access they are given
RMT-GDL	Remote Working Guideline	Guideline	Recommended practice for signing in from outside the office
INC-001	Incident Management Policy	Policy	How a suspected breach of this policy is reported

Definitions

Term	Meaning in this policy
Administrator account	An account that can change a system's settings, users or security controls.
Multi-factor authentication	Signing in with two different kinds of proof, such as a password and a code from a registered device.
Service account	An account used by a system or program rather than a person.
System owner	The manager accountable for a system and the information in it, named in the Company's asset register.

Document control

Version	Approved by	Date	Evidence of approval	Next review by
2.0	Executive Committee	2026-01-20	Executive Committee minutes, meeting of 2026-01-20	2027-01-20

Version	Date	Author	Summary of change	Review type
1.x	—	Head of IT	Earlier versions, withdrawn and archived (PF-08)	—
2.0	2026-01-20	Head of IT	Rewritten in the policy template: statements numbered and made testable; settings moved to standards	Scheduled

Review. Reviewed at least every 12 months and after any trigger set in the Policy Framework Standard. Publication. The current version is on the Company intranet policy page; earlier versions are archived by the Head of Information Security. (EXAMPLE)

Document	Relationship
Policy Framework Standard	Sets the rules this template applies: tiers, sections, testable statements, length, approval and review (PF-01 to PF-12)
Policy Lifecycle Operating Procedure	The procedure that governs this template: the steps from identifying a need to publication and review
Security Policy Hierarchy & Document Map	Shows where each policy sits in the hierarchy, and the standards and procedures beneath it
Policy Register & Review Schedule	Records every policy written with this template: owner, tier, status, version, approval and review dates (PF-11)
Policy Attestation & Acknowledgement Tracker	Tracks who has acknowledged each policy (PF-09)
Policy Coverage Gap Assessment	Lists the policy topics an organisation of your profile needs
Policy Development & Approval Responsibility Matrix	Who drafts, is consulted on, approves and communicates each tier — and who approves when the approver owns or wrote the document
Security Exception & Waiver Standard	The route for every exception to a policy (PF-10); P02 pack

Adapting this template

Guidance — delete before approval

Small organisation: keep all nine sections, even when some are two lines long; that is what makes a short policy auditable. Start with the Core topics in the Policy Coverage Gap Assessment, and consider one Information Security Policy that carries the Core topics as numbered parts, each with its own statements, rather than five separate policies. Where the owner, the author and the approver would be the same person, see the Policy Development & Approval Responsibility Matrix: nobody approves a document they own or wrote. For a policy: the rest of executive management, without the member who owns or wrote it.

Regulated entity (NIS2, DORA): under NIS2 Article 20(1) the management body approves the cybersecurity risk-management measures, so record the management body's approval of each policy, not only a committee's. DORA Article 9(4)(a) requires a documented information security policy. For DORA financial entities, RTS 2024/1774 Article 2(2) lists what each ICT security policy must contain; this template places them as follows — approval date: identity block and approval record ((b)); indicators and recorded exceptions: Compliance and consequences, and Exceptions ((c)); responsibilities of staff at all levels: Roles and responsibilities ((d)); consequences of non-compliance: Compliance and consequences ((e)); documentation to be maintained: add it to Related documents ((f)); review and material changes: Document control, with the triggers ((j), (k)).

IT run by a service provider: put service providers in Scope by name or category, give them a row in Roles and responsibilities, and require compliance with your policies in the contract. The provider's own policies do not replace yours; ask for evidence that it meets your statements, and use the Security Exception & Waiver Standard for anything it cannot meet.

Delete this section before approval.

Framework references

These references show where this document supports an external framework. They indicate relevance only and do not reproduce the text of any standard. Editions referenced: ISO/IEC 27001:2022 incl. Amd 1:2024; NIST CSF 2.0; Directive (EU) 2022/2555 (NIS2); Regulation (EU) 2022/2554 (DORA); Delegated Regulation (EU) 2024/1774.

Framework	Reference	Supported by
ISO/IEC 27001:2022	Clause 5.2 — Policy	Parts 1 and 2: a policy with a stated purpose, commitments and approval, communicated to those it applies to
ISO/IEC 27001:2022	Annex A 5.1 — Policies for information security	Whole template: policies defined, approved, published, acknowledged and reviewed
ISO/IEC 27001:2022	Annex A 5.36 — Compliance with policies, rules and standards for information security	Compliance and consequences: how compliance with the policy is checked
NIST CSF 2.0	GV.PO-01 — “Policy for managing cybersecurity risks is established based on organizational context, cybersecurity strategy, and priorities and is communicated and enforced”	Whole template: policy established, communicated and enforced
DORA — Regulation (EU) 2022/2554	Article 9(4)(a) — a documented information security policy with rules to protect the availability, authenticity, integrity and confidentiality of data and assets	Whole template: a documented information security policy
DORA — Delegated Regulation (EU) 2024/1774	Article 2(2)(b) — ICT security policies indicate the date of their formal approval by the management body	Identity block and approval record: date of formal approval
DORA — Delegated Regulation (EU) 2024/1774	Article 2(2)(c) — policies contain indicators to monitor their implementation and record exceptions from it	Compliance and consequences (indicators); Exceptions (recorded under the P02 Standard)
DORA — Delegated Regulation (EU) 2024/1774	Article 2(2)(d) — policies specify the responsibilities of staff at all levels	Roles and responsibilities: staff at all levels
DORA — Delegated Regulation (EU) 2024/1774	Article 2(2)(e) — policies specify the consequences of non-compliance by staff	Compliance and consequences: consequences of non-compliance

Definitions

Term	Meaning in this template
Tier	One of the four levels of security document — Policy, Standard, Procedure, Guideline — each with its own purpose, approver and review interval (PF-01).
Policy	What the organisation commits to and why. Short, stable, written for everyone.
Standard	The specific, measurable requirements that make a policy real: settings, deadlines, minimums.
Procedure	How a task is done, step by step, by named roles.
Guideline	Recommended practice. Helpful, not mandatory; nobody is non-compliant for not following it.
Policy statement	A numbered requirement in a policy, written with "must" or "must not", naming who acts, and testable from evidence.
Testable	Two people looking at the same evidence would agree whether the statement was met.
Identity block	The table at the top of a policy's first page: reference, tier, version, status, owner, approver, approval date and next review date.
Document owner	The one role accountable for a document's content and its review (PF-02).
Trigger	An event that forces a review before the scheduled date (PF-06).
Exception	An approved, time-limited decision that a requirement need not be met in a stated scope, handled under the Security Exception & Waiver Standard (PF-10).
Status	The state of a document in the register: Draft — being written; not in force; In consultation — circulated for comment to the people it affects (PF-07); Awaiting approval — final text with the approver for its tier (PF-03); Approved — in force: approved, published, and within its review date; Review overdue — in force, but past its next review date (PF-06); Retired — withdrawn and archived; no longer in force (PF-08).