Policy Framework Standard

Purpose

This standard sets the rules every information security document at [[Organisation Name]] follows: which tier it belongs to, who owns and approves it, what a policy must contain, how documents are numbered and versioned, how they are consulted on, published, acknowledged, reviewed and retired, and how the whole set is kept on one register and reported to management.

Its aim is that every security document people are told to follow is current, approved at the right level, published in one place, known to the people it applies to, and on the register. A policy that nobody has read, that has not been reviewed for three years, or that exists in four versions on four drives protects nothing.

Scope

This standard applies to:

• every information security policy, standard, procedure and guideline of [[Organisation Name]], including topic-specific policies and the security sections of other documents (together, security documents);
• security documents written or operated for us by service providers, where we require our people or the provider's people to follow them;
• everyone who owns, writes, approves, publishes or must follow a security document.

It does not cover: records and evidence (logs, tickets, completed forms), which are kept under [[the records management policy]]; contracts; or a service provider's own internal documents that we do not require anyone to follow.

Parent policy and authority

This standard is issued under the [[Information Security Policy]], which gives [[the Head of Information Security]] authority to maintain the security document set and [[e.g. Executive Committee, or the management body]] authority to approve this standard. It is a Standard-tier document owned by information security, so under the conflict rule in PF-03 it is approved by executive management — the right level in any case, because it sets who may approve every other security document.

Where another document sets its own approval, review or publication rule, the stricter of the two applies: the shorter review interval, the higher approver.

Roles and responsibilities

The document hierarchy

PF-01 Every security document belongs to exactly one tier (Policy, Standard, Procedure, Guideline) and says which on its first page.

The four tiers, top to bottom. The maximum review interval counts from the approval date.

Every document below the Policy tier names its parent document on its first page. A lower tier may add detail, never contradict the tier above: where a standard and its policy disagree, the policy applies until the standard is corrected. A guideline may not contain a 'must' statement; if something must be done, it belongs in a standard or procedure.

Ownership

PF-02 Every document has one named owner, accountable for its content and its review.

The owner is a role, named in the document control table and the register, held by a person with the authority to make the document work — usually the head of the function that must follow or operate it. A committee is not an owner. When an owner leaves or changes role, [[the Head of Information Security]] records the new owner in the register within [[10 working days]]; until then, the owner's line manager is the owner.

Approval

PF-03 Each tier is approved at the level set for it; a document is not in force until approved and published.

Approval is given in writing and dated: the minute of the meeting, a signed approval page, or the approval record in [[the document management system]]. The date of that decision is the document's approval date; it is printed in the document control table and on the register.

Nobody approves a document they own or wrote. Where the tier's approver owns or wrote the document, it is approved instead by:

• An approver of a higher tier may approve a document of a lower tier. The reverse is never allowed.
• Every new version is approved at its tier's level, minor or major. A minor version may be approved in writing without a meeting.
• A document is in force from its effective date, which is no earlier than the date it is published (PF-08). An approved document not yet published is not in force.
• A document people are told to follow that has no recorded approval at the right level is counted in PM-02 and is brought for approval, or withdrawn, within [[30 calendar days]] of being found.

What a policy contains

PF-04 A policy carries the sections in the table below, in order, and states requirements as testable 'must' statements.

PF-05 A policy is short enough to be read: at most [[4]] pages of body; detail belongs in standards and procedures.

The mandatory sections, in this order. The Security Policy Document Template provides them with guidance.

A 'must' statement is testable when an auditor could decide, from evidence, whether it was met: "Administrator accounts must use multi-factor authentication" is testable; "Access should be appropriately controlled" is not. Each statement is numbered so that exceptions (PF-10) and audit findings can cite it.

Standards, procedures and guidelines carry at least: Purpose, Scope, the requirements or steps, Roles, Related documents and Document control. Their layout otherwise follows their type.

Identification, naming and versioning

Document ID. Every document has a unique ID: a three-letter topic code, a hyphen, then a three-digit serial number (ISP-001) or a tier code (EXC-STD). The ID is given when the document is first registered, never changes when the document is revised, and is never reused after the document is retired.

Title. The title names the document's tier as its last word or words — "Acceptable Use Policy", "Backup Standard", "Joiner, Mover, Leaver Procedure", "Remote Working Guideline" — so its tier is obvious wherever it is quoted (PF-01).

File name. [ID] [Title] v[major.minor], e.g. AUP-001 Acceptable Use Policy v2.1. Only the published version carries no "DRAFT" marking.

Version numbers are major.minor:

What counts as a material change

A change is material if it does any of the following:

• 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;

A change is not material if it is only:

• spelling, grammar, formatting or layout;
• a role, team, system or document renamed with no change to what anyone does;
• an updated cross-reference, link or contact detail;
• a clarification that every consulted function agrees changes no obligation;

If the owner and information security disagree whether a change is material, it is treated as material. The approver confirms the classification when approving, and it is recorded in the revision history.

Consultation

PF-07 Drafts are consulted on with the people who must follow them and with legal, HR and data protection where they are affected.

A new document, and every material change, is circulated for comment for at least [[10]] working days, with the document's status set to In consultation for a new document. The author records each comment and the response to it — accepted, changed or declined with a reason — and the record goes to the approver with the final text. A draft that changes materially after consultation is consulted on again with the people affected by that change.

• Legal is consulted whenever a document states a legal or contractual duty or a consequence for staff or suppliers.
• HR is consulted whenever a document sets consequences for staff, or duties for joiners, movers and leavers.
• Data protection is consulted whenever a document concerns personal data, monitoring of staff, or retention.
• [[Staff representatives or works council]] are consulted where local law or agreements require it.

Publication, withdrawal and archiving

PF-08 Only the current approved version is published, in one place everyone can reach; superseded versions are withdrawn and archived.

• The one place is [[the policy library on the intranet]]. The approved version is published there within [[5]] working days of approval, as a read-only file with its document control table complete.
• On the day a new version is published, the previous version is withdrawn from the library and from every other place it was put — shared drives, onboarding packs, supplier portals — and archived with its approval record and consultation record.
• Copies saved or printed elsewhere are uncontrolled. Every published document states: "Printed or downloaded copies are uncontrolled; the current version is in [[the policy library]]."
• Archived versions are kept for [[the life of the security management system plus 3 years]], so the version in force on any date can be shown.

Document status

A security document carries exactly one of these statuses in the register, and no others:

Only a document with status Approved or Review overdue is in force. While a new version of a document in force is drafted, consulted on and approved, the register keeps the status of the version in force (Approved or Review overdue) and records the revision's stage in its notes. The statuses Draft, In consultation and Awaiting approval describe a document with no version in force yet.

Review

PF-06 Every document is reviewed by its tier's maximum interval, and sooner on any trigger; a review that changes nothing is still recorded.

The next review date is the approval date plus the tier's maximum interval: 12 months for a policy, 12 months for a standard, 24 months for a procedure, 24 months for a guideline. The owner may set an earlier date; never a later one.

A review is also due, whatever the next review date, after any of these triggers:

• 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;

Information security tells the owner at least [[90]] calendar days before the next review date, and within [[5 working days]] of learning of a trigger. A review ends in one of four outcomes, each recorded in the revision history and the register: no change (a new minor version, approved, with a new next review date); a change that is not material (a minor version); a material change (a major version, consulted on and re-acknowledged); or retirement (PF-08).

A document whose next review date has passed becomes Review overdue. It stays in force — people keep following it — until the review is approved. A document 30 calendar days overdue is escalated by information security to [[e.g. Executive Committee, or the management body]], and every overdue document is named in the quarterly report (PF-12).

EXAMPLE — as at Wed, 30 Sept 2026, the example organisation (a software services company with 240 staff in two offices, an NIS2 important entity) had 2 documents past their review date (PM-01):

Both are beyond the 30-day escalation point, and one of them is a policy, so the PM-01 target (zero policies; no document more than 30 days overdue) is missed twice. The Policy Lifecycle Operating Procedure follows the Acceptable Use Policy through its overdue review.

Acknowledgement

PF-09 People acknowledge the policies that apply to them: new starters within the joiner window, everyone again after a material change and once a year.

The acknowledgement windows:

• Policies are acknowledged individually. Standards and procedures are not acknowledged by everyone; the people who operate them are trained on them [[or acknowledge them, if you choose]].
• An acknowledgement records the person, the document ID, the version and the date, in the Policy Attestation & Acknowledgement Tracker. It is a deliberate act — ticking a box or signing — not the opening of a file.
• An acknowledgement counts for every minor version of the same major version: an acknowledgement of 2.1 is current for 2.2 but not for 3.0. A re-acknowledgement after a material change also counts as that year's annual acknowledgement of the policy.
• People are reminded [[5]] working days before their deadline. Anyone past it is named to their line manager (PM-04).

The target is that at least 95% of people in scope have a current acknowledgement of each policy that applies to them (PM-03).

Exceptions

PF-10 Deviations from any document are handled as security exceptions under the Security Exception & Waiver Standard (P02), never by informal agreement.

A person, team, system or supplier that cannot meet a requirement of any security document asks for an exception under the [[Security Exception & Waiver Standard]]. Each policy's Exceptions section says so. An exception is to a numbered requirement, for a named scope and a fixed time; it never changes the document. If a requirement should never apply to something, change the document through review (PF-06).

The rules of this standard may themselves be excepted only through the Security Exception & Waiver Standard (P02), except PF-03 (approval), PF-08 (publication) and PF-10 (the exception route itself), which may never be excepted: an unapproved or unpublished document is not in force, whatever anyone agrees, and there is no other route for a deviation. A review date missed without an approved exception is not an exception; it is Review overdue and is reported.

The register

PF-11 The register lists every document with owner, tier, status, version, approval date and next review date, and is the only authoritative list.

The Policy Register & Review Schedule is the register. For every security document it holds at least:

A document that is not on the register is not in force, whatever its contents. Information security reconciles the register with the policy library [[every quarter]].

Reporting

PF-12 Document currency and acknowledgement coverage are reported to management every quarter.

Information security reports to [[e.g. Executive Committee, or the management body]] every quarter using the Policy Health & Attestation Reporting Workbook, with these four headline measures:

The report names every document that is Review overdue with its owner and days overdue, every document in force without approval, and every manager with overdue acknowledgements in their team. It states the decisions management needs to take.

Exceptions to this standard

The rules of this standard may themselves be excepted only through the Security Exception & Waiver Standard (P02), except PF-03 (approval), PF-08 (publication) and PF-10 (the exception route itself), which may never be excepted: an unapproved or unpublished document is not in force, whatever anyone agrees, and there is no other route for a deviation. If a rule should change for everyone, [[the Head of Information Security]] proposes a revision to its approver, and the rule stays in force until the revision is approved.

Records to keep

Compliance

Compliance with this standard is monitored through the quarterly report (PF-12) and the quarterly reconciliation of the register (PF-11), and checked through [[internal audit / independent review]] at least once a year. A document in force without approval, or a person who repeatedly fails to acknowledge a policy after reminders, is reported to management and handled under [[the disciplinary procedure / supplier performance terms]].

Review of this standard

This standard is a Standard-tier document and is reviewed at least every 12 months, and sooner after any of the triggers in PF-06.

Related documents

Adapting this template

Small organisation

Regulated entity (NIS2 or DORA)

The table covers the points of Article 2(2) that concern how policies are written, approved and kept. Check the remaining points against the Regulation's text when you write each topic policy.

IT run by a service provider

Transition

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.

Appendix A — Definitions