Policy Lifecycle Operating Procedure
Covers the full document lifecycle from drafting through consultation, approval, publication, attestation, review and retirement.
Available soon
- Format
- Word
- Size
- 61 KB
- Length
- 17 pages
- Version
- 1.0
- Updated
What's inside
- Purpose
- Scope
- Roles
- Triggers and inputs
- Procedure steps
- Decision points
- Outputs and records produced
- Timing targets
- Escalation
- Evidence retained
- 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.
Purpose
This procedure sets out how a single security document moves through [[Organisation Name]], from the moment someone sees the need for it to the moment it is retired. It is the working routine behind the Policy Framework Standard: the Standard sets the rules (PF-01 to PF-12); this procedure says who does what, in which order, by when, and what record each step leaves.
It answers three questions for every document: who writes, approves and owns it, how the people it applies to come to know it, and how it is kept current — by a review on time, and sooner when something changes.
Scope
This procedure applies to:
- every security document on the Policy Register & Review Schedule — policies, standards, procedures and guidelines — whether new, under review, or being retired;
- everyone with a role in the table below, including service providers who draft or operate documents for us.
It does not cover how a document is laid out (the Security Policy Document Template), which topics the set must cover (the Policy Coverage Gap Assessment), or how a deviation from a document is handled, which is a security exception under the [[Security Exception & Waiver Standard]] (PF-10).
Roles
Role | What they do in this procedure |
|---|---|
Document owner [[e.g. Head of IT for the access control policy]] | Accountable for the document (PF-02). Asks for it to be written or revised, agrees the text for consultation, answers review notices, decides the review outcome and proposes retirement. |
Author [[whoever the owner asks to draft]] | Drafts and revises the text, runs consultation and keeps the comment log. |
Information security [[e.g. Head of Information Security]] | Keeps the register. Decides the tier, checks drafts against the Standard, routes approval, sends review notices, tracks acknowledgement and escalates. Prepares the quarterly figures. |
Approver [[set per tier: see the document hierarchy]] | Approves, returns or rejects in writing and dated (PF-03), and confirms whether a change is material. |
Executive management [[e.g. Executive Committee, or the management body]] | Approves Policy-tier documents. Receives escalations of overdue reviews and the quarterly report (PF-12). |
Consulted functions [[e.g. Legal, HR, Data Protection Officer]] | Comment on drafts that affect them within the consultation period (PF-07). |
Publisher [[e.g. Internal Communications, or HR for acknowledgements]] | Publishes approved versions, withdraws and archives old ones (PF-08), and sends acknowledgement requests and reminders (PF-09). |
Independent reviewer [[e.g. internal audit]] | Tests a sample of documents against this procedure at least once a year. |
Guidance — delete before approval
In a small organisation the author may be the owner, and information security the publisher. That is acceptable, but the approver is never the document's owner or author: the Standard names who approves instead (PF-03). The Policy Development & Approval Responsibility Matrix sets out the full split of responsibilities.
Triggers and inputs
When this procedure runs
Trigger | What starts | Steps |
|---|---|---|
A gap found by the Policy Coverage Gap Assessment, a new service, law or contract, an audit finding, or a manager's request | A new document | 1 to 26 |
90 calendar days before a document's next review date (PF-06) | A scheduled review | 27, 29 to 33 |
A review trigger: 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 | A triggered review | 28 to 33 |
A document's next review date passes without an approved review | Overdue handling | 33 |
A new starter joins, someone moves role, or the annual cycle opens | Acknowledgement | 23 to 26 |
A document is superseded, merged or no longer needed | Retirement | 34 to 37 |
Inputs
Input | Where it comes from | Used for |
|---|---|---|
The register | Policy Register & Review Schedule | Existing documents, owners, versions, review dates |
The hierarchy and document map | Security Policy Hierarchy & Document Map | Choosing the tier and the parent document |
The policy layout | Security Policy Document Template | Drafting a policy with the mandatory sections |
The responsibility split | Policy Development & Approval Responsibility Matrix | Who drafts, is consulted and approves |
Acknowledgement records | Policy Attestation & Acknowledgement Tracker | Who has acknowledged which version |
Exceptions granted against the document | [[Security exception register]] | Signs that a requirement is wrong or unworkable |
Incidents, audit findings, changes in law | [[Incident log, audit reports, legal updates]] | Triggered reviews |
Procedure steps
The tiers this procedure works to
These are the tiers in the Policy Framework Standard, repeated for convenience; the Standard governs if the two ever differ. The next review date is the approval date plus the maximum interval, in months.
Tier | Approved by | Reviewed at least every | Acknowledged by |
|---|---|---|---|
Policy | Executive management (the management body, or its delegate for the top policy) | 12 months | Everyone in its scope (PF-09) |
Standard | Head of Information Security (the document owner is consulted) | 12 months | Not individually; people who operate it are trained on it |
Procedure | Head of Information Security (the process owner is consulted) | 24 months | Not individually; people who operate it are trained on it |
Guideline | Information security | 24 months | Not individually; people who operate it are trained on it |
Stage 1 — Identify the need
Step | What happens | Who | When | Output |
|---|---|---|---|---|
1 | Identify the need for a new document and tell information security what it must cover and why. | Anyone; usually the future owner | When the need arises | Request |
2 | Check the register. If a document already covers the need, this is a review of that document (stage 7), not a new one. | Information security | Within [[5]] working days of the request | New document or review |
3 | Choose the tier (PF-01) and the parent document using the Security Policy Hierarchy & Document Map, and agree the owner (PF-02). The owner accepts in writing. | Information security; proposed owner | Within [[5]] working days of the request | Tier, parent and owner agreed |
4 | Give the document an ID and enter it on the register: status Draft, version 0.1, the owner, and a target approval date. | Information security | The same day | Register entry |
Stage 2 — Draft
Step | What happens | Who | When | Output |
|---|---|---|---|---|
5 | Draft the document. A policy uses the Security Policy Document Template, with its sections in order and every requirement a numbered, testable 'must' statement (PF-04). Settings, deadlines and values go in a standard, not a policy. | Author | By the date the owner sets | Draft 0.x, or draft of the next version |
6 | Check the draft: tier stated on the first page (PF-01); sections in order (PF-04); a policy's body no more than [[4]] pages (PF-05); nothing that contradicts a higher-tier document; Exceptions section routes to the exception standard (PF-10). | Information security | Within [[5]] working days of receiving it | Draft checked, or returned with comments |
7 | For a revision, decide whether the change is material, using the test in the Standard. If either of the two thinks it is, treat it as material. A change that is not material skips stage 3. | Document owner; Information security | With step 6 | Classification recorded |
8 | Agree the text for consultation and list who must be consulted: the people who must follow it, and legal, HR and data protection where affected (PF-07). | Document owner | With step 6 | Consultation list |
Stage 3 — Consultation
Step | What happens | Who | When | Output |
|---|---|---|---|---|
9 | Circulate the draft with a closing date at least [[10]] working days away. For a new document, set the status to In consultation. | Author | When step 8 is done | Consultation request |
10 | Record every comment and the response — accepted, changed, or declined with a reason. | Author | By [[5]] working days after closing | Comment log |
11 | If the text changes materially after consultation, consult again the people affected by that change. | Author; Document owner | Before step 12 | Second consultation, if needed |
12 | Confirm the final text. | Document owner | After step 10 or 11 | Final text |
Guidance — delete before approval
A consultation that nobody answers is not consultation. Name a person in each consulted function, and ask for "no comment" in writing if they have none.
Stage 4 — Approval by tier
Step | What happens | Who | When | Output |
|---|---|---|---|---|
13 | Send the approval pack to the approver for the document's tier: the final text, a summary of changes, the material-change classification and the comment log. If the usual approver owns or wrote the document, send it to the approver the Standard names for that case (PF-03; see the table below). For a new document, set the status to Awaiting approval. | Information security | Within [[5]] working days of the final text | Approval pack |
14 | Decide in writing: approve, return with required changes, or reject. Confirm or correct the material-change classification. | Approver | At the next meeting, or within [[20]] working days | Dated approval record |
15 | Set the version (1.0 for a new document; the next major or minor number for a revision), the approval date and the next review date — the approval date plus the tier's maximum interval, or earlier — in the document control table and the revision history. | Information security | The day of approval | Final approved document |
16 | If no decision is made by the date in step 14, escalate to [[e.g. Executive Committee, or the management body]]. | Information security | The next working day | Escalation |
Who approves when the tier's usual approver owns or wrote the document (PF-03):
Tier | Approver instead |
|---|---|
Policy | The rest of executive management, without the member who owns or wrote it |
Standard | Executive management |
Procedure | Executive management |
Guideline | Executive management |
Stage 5 — Publication and withdrawal of the old version
Step | What happens | Who | When | Output |
|---|---|---|---|---|
17 | Publish the approved version in the policy library, read-only, with its effective date. It is in force from that date (PF-03, PF-08). | Publisher | Within [[5]] working days of approval | Published document |
18 | Withdraw the previous version from the library and from every other place it was put — shared drives, onboarding packs, supplier portals — and archive it with its approval and consultation records. | Publisher; Document owner names the other places | The day of publication | Old version withdrawn and archived |
19 | Update the register: version, status Approved, approver, approval date, next review date and location (PF-11). | Information security | The day of publication | Register updated |
20 | Tell the people it applies to what has changed and why, and whether they must acknowledge it. | Publisher; Document owner | The day of publication | Announcement |
Stage 6 — Acknowledgement
For Policy-tier documents (PF-09). Every window runs from the date shown: 10 working days for a new starter, 30 calendar days after a material change, and once a year, for every policy that applies to the person.
Step | What happens | Who | When | Output |
|---|---|---|---|---|
21 | Confirm who is in the policy's scope, and record the number in the register and the tracker. | Information security; Publisher | Before publication | Acknowledgement scope |
22 | For a new policy or a new major version, ask everyone in scope to acknowledge it. Deadline: 30 calendar days after publication. A minor version needs no new acknowledgement. | Publisher | The day of publication | Acknowledgement requests |
23 | Ask each new starter, and each person who moves into a policy's scope, to acknowledge every policy that applies to them. Deadline: 10 working days after their start or move date. | Publisher; [[HR, through onboarding]] | On the start or move date | Joiner requests |
24 | Open the annual cycle: ask everyone to acknowledge every policy that applies to them. A re-acknowledgement after a material change in the last [[12 months]] counts for that policy. | Publisher | [[Month]] each year | Annual requests |
25 | Remind people [[5]] working days before their deadline. After the deadline, name them to their line manager; the quarterly report counts them (PM-04). | Publisher; Information security | As shown | Reminders; overdue list |
26 | Record each acknowledgement — person, document ID, version, date — in the Policy Attestation & Acknowledgement Tracker. | Publisher | As received | Acknowledgement record |
Stage 7 — Scheduled and triggered review
Step | What happens | Who | When | Output |
|---|---|---|---|---|
27 | Send the owner a review notice with the next review date, any triggers recorded, exceptions granted against the document, and its acknowledgement coverage. | Information security | 90 calendar days before the next review date | Review notice |
28 | When a trigger occurs, tell the owner and record it in the register's notes. The owner sets a review completion date with information security, no later than [[60 calendar days]] after the trigger. | Information security | Within [[5]] working days of learning of it | Triggered review opened |
29 | Review the document: is it still accurate, complete and followed? Consider the triggers, exceptions granted against it, audit findings, incidents and acknowledgement coverage. Decide the outcome. | Document owner | Before the next review date | Review outcome |
30 | No change, or a change that is not material: prepare the next minor version, recording "Reviewed — no change" where nothing changed, and go to stage 4. No consultation, no new acknowledgement. | Document owner; Information security | With step 29 | Minor version for approval |
31 | Material change: prepare the next major version and go to stage 2. It is consulted on, approved and re-acknowledged in full. | Document owner | With step 29 | Major version in draft |
32 | No longer needed: go to stage 8. | Document owner | With step 29 | Retirement proposal |
33 | If the next review date passes without an approved review, set the status to Review overdue and tell the owner. The document stays in force. At 30 calendar days overdue, escalate to [[e.g. Executive Committee, or the management body]]; name it in every quarterly report until the review is approved (PF-12). | Information security | The day after the next review date | Status changed; escalation |
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.
Stage 8 — Retirement
Step | What happens | Who | When | Output |
|---|---|---|---|---|
34 | Propose retirement with the reason — superseded, merged into another document, or no longer needed — and say where any requirements that still apply now live. | Document owner | When the need ends | Retirement proposal |
35 | Approve the retirement in writing. | Approver for the document's tier | Within [[20]] working days | Dated retirement decision |
36 | Withdraw the document from the policy library and every other place, archive it, set its status to Retired, and remove it from acknowledgement cycles. Its ID is never reused. | Publisher; Information security | Within the publication window | Retired register entry |
37 | Update references to it in other documents, as minor changes to them, and tell the people it applied to. | Information security; owners of the other documents | At their next change, within [[3 months]] | Cross-references corrected |
Decision points
Decision | Who decides | Rule | Recorded in |
|---|---|---|---|
New document or review of an existing one? | Information security | Only one document per need; the register is authoritative (PF-11) | Register |
Which tier, and who owns it? | Information security; owner accepts | PF-01, PF-02 | Register; document control |
Is the change material? | Document owner and Information security; approver confirms | Material if it adds, removes or changes a 'must' statement, or what anyone has to do to comply, or any other point in the Standard's test; if in doubt, material | Revision history |
Is consultation complete? | Document owner | Everyone affected has answered or the period has closed (PF-07) | Comment log |
Approve, return or reject? | Approver for the tier, never the owner or author | PF-03 | Approval record |
Review outcome: no change, minor, major or retire? | Document owner | PF-06 | Revision history; register |
Escalate an overdue review? | Information security | At 30 calendar days overdue | Escalation; quarterly report |
Worked example — the Acceptable Use Policy's overdue review
EXAMPLE — an illustration, not part of the procedure. It follows AUP-001, the Acceptable Use Policy, from the example organisation's register (a software services company with 240 staff in two offices, an NIS2 important entity) as at Wed, 30 Sept 2026. Replace the as-at date with today's date when you use the example for training. Dates are worked out from the Standard's rules; working days exclude weekends only.
Date | What happened | Step |
|---|---|---|
Thu, 2 Apr 2026 | Review notice due, 90 calendar days before the next review date of Wed, 1 Jul 2026 (12 months after approval on Tue, 1 Jul 2025). The Head of IT, the owner, does not start the review. | 27 |
Thu, 2 Jul 2026 | The next review date has passed. Status set to Review overdue; version 2.1 stays in force. | 33 |
Fri, 31 Jul 2026 | 30 calendar days overdue: escalated to executive management, which accepts the owner's plan to start the review in September. | 33 |
Wed, 30 Sept 2026 | The quarterly report names AUP-001 as 91 calendar days overdue — a policy past its review date, so PM-01 misses its target. Acknowledgement of version 2.1 stands at 214 of 240 people (89.2%), below the 95% target of 228. Management asks for approval at its November meeting. The owner reviews the policy: since 2.1, staff may read work email on their own phones (a material change to the organisation's activities, systems or suppliers), and an internal audit found that the policy says nothing about putting company information into online AI tools (an audit or assessment finding against the document). Both change what staff must do: material, so the next version is 3.0. | 29, 31 |
Wed, 14 Oct 2026 | Draft 3.0 ready, written on the Security Policy Document Template. Information security checks it: tier, sections, body within the page limit. Consultation opens with HR, legal, data protection (personal phones and monitoring) and [[staff representatives]]. The register keeps status Review overdue, with "3.0 in consultation" in its notes. | 5 to 9 |
Wed, 28 Oct 2026 | Consultation closes after 10 working days. Comments logged with responses; no change after consultation needs a second round. | 10 to 12 |
Mon, 2 Nov 2026 | Approval pack sent to the Executive Committee, the Policy-tier approver, which approved version 2.1. The Head of IT is not a member of it, so no one approves their own document. | 13 |
Thu, 5 Nov 2026 | Approved at the Executive Committee meeting, confirmed as material. Version 3.0; approval date 2026-11-05; next review date 2027-11-05 (12 months). The review was 127 calendar days late. | 14, 15 |
Mon, 9 Nov 2026 | Published in the policy library, 4 calendar days after approval. Version 2.1 withdrawn from the library and the onboarding pack and archived. Register: 3.0, Approved. Everyone in scope — 240 people — asked to acknowledge by Wed, 9 Dec 2026. Acknowledgements of 2.1 do not count for 3.0: coverage restarts at 0 of 240. | 17 to 22 |
Mon, 16 Nov 2026 | A new starter joins. They acknowledge 3.0 with their other policies by Mon, 30 Nov 2026 (10 working days). | 23, 26 |
Wed, 2 Dec 2026 | Reminder to everyone who has not yet acknowledged, 5 working days before the deadline. | 25 |
Thu, 10 Dec 2026 | Everyone still without an acknowledgement is named to their line manager. At least 228 of 240 acknowledgements are needed to meet the 95% target. The quarter-end report no longer counts AUP-001 in PM-01. | 25 |
Had the review found nothing to change, the owner would have prepared version 2.2 recording "Reviewed — no change", and the Executive Committee could have approved it in writing without a meeting: no consultation and no new acknowledgement, so 214 acknowledgements of 2.1 would still have counted. Had the review started when the notice fell due on Thu, 2 Apr 2026, the 90 calendar days before the review date would have covered drafting, a 10-working-day consultation and a meeting of the Executive Committee, and the policy would never have been overdue. Its next review notice falls due 90 calendar days before Fri, 5 Nov 2027.
Outputs and records produced
Output | Produced at step | Held in | Maintained by |
|---|---|---|---|
Register entry: ID, tier, owner, version, status, approval and review dates, notes | 4, 15, 19, 28, 33, 36 | Policy Register & Review Schedule | Information security |
Drafts and the material-change classification | 5 to 7, 30, 31 | [[Document management system]] | Author |
Comment log | 10, 11 | [[Document management system]] | Author |
Dated approval or retirement record | 14, 35 | [[Minutes / approval workflow]] | Approver |
Published version; archived previous version | 17, 18, 36 | [[Policy library and archive]] | Publisher |
Acknowledgement requests, reminders and records | 22 to 26 | Policy Attestation & Acknowledgement Tracker | Publisher |
Review notices, triggered reviews and escalations | 16, 27, 28, 33 | [[Email or workflow]] | Information security |
These records feed the quarterly report required by the Policy Framework Standard (PF-12), produced with the Policy Health & Attestation Reporting Workbook.
Timing targets
Activity | Target | Basis |
|---|---|---|
Consultation period | At least [[10]] working days | Standard PF-07 |
Publication after approval | Within [[5]] working days | Standard PF-08 |
Previous version withdrawn | The day the new version is published | Standard PF-08 |
Review — policy | At least every 12 months from approval, and after any trigger | Standard PF-06 |
Review — standard | At least every 12 months from approval, and after any trigger | Standard PF-06 |
Review — procedure | At least every 24 months from approval, and after any trigger | Standard PF-06 |
Review — guideline | At least every 24 months from approval, and after any trigger | Standard PF-06 |
Review notice to owner | 90 calendar days before the next review date | Standard PF-06 |
Overdue review escalated | At 30 calendar days overdue | Standard PF-06; PM-01 |
Acknowledgement — new starter | Within 10 working days of the start date | Standard PF-09 |
Acknowledgement — material change | Within 30 calendar days of publication | Standard PF-09 |
Acknowledgement — everyone | Annually — once a year, for every policy that applies to the person | Standard PF-09 |
Acknowledgement coverage | At least 95% of people in scope | Standard PF-09; PM-03 |
Register check after a request, and tier and owner agreed | Within [[5]] working days | This procedure |
Draft checked by information security | Within [[5]] working days of receipt | This procedure |
Approval decision | Next meeting, or within [[20]] working days | This procedure |
Quarterly report | Every quarter | Standard PF-12 |
Guidance — delete before approval
Targets marked "This procedure" are not in the Standard. You may change them, but check that the review notice still leaves time for drafting, consultation and a meeting of the approver before the review date.
Escalation
When | Escalated to | By | Basis |
|---|---|---|---|
No approval decision by the date in step 14 | [[e.g. Executive Committee, or the management body]] | Information security | This procedure |
A review 30 calendar days overdue | [[e.g. Executive Committee, or the management body]] | Information security | Standard PF-06 |
A document in use without a recorded approval | The tier's approver; [[e.g. Executive Committee, or the management body]] if not resolved in [[30 calendar days]] | Information security | Standard PF-03; PM-02 |
Acknowledgements past their deadline | The person's line manager; counted in the quarterly report | Publisher | Standard PF-09; PM-04 |
A consulted function does not respond | Its head, before the closing date | Author | This procedure |
An owner leaves with no successor named | The owner's line manager, who is owner until one is named | Information security | Standard PF-02 |
An escalation states the document ID and title, the owner, the date missed, the days overdue, and the decision needed. It asks for a decision, not just attention.
Evidence retained
Keep the following so a reviewer can follow any document from its request to its current version. Retention periods follow the Records to keep section of the Policy Framework Standard.
Evidence | Shows | Minimum retention |
|---|---|---|
Every approved version, and the one it replaced | Which version was in force on any date (PF-08) | [[Life of the security management system + 3 years]] |
Approval records with approver and date | The right approver approved it before it was in force (PF-03) | [[As the version they approve]] |
Comment logs | The people affected were consulted (PF-07) | [[As the version they concern]] |
Review records, including no-change reviews | Reviews happened on time and after triggers (PF-06) | [[6 years]] |
Acknowledgement records | People knew the version in force (PF-09) | [[Employment + 6 years]] |
Escalations and quarterly reports | Management knew and decided (PF-12) | [[6 years]] |
Guidance — delete before approval
An auditor typically picks a few policies and asks for the approval record, the date it was published, proof the old version was withdrawn, the last review, and acknowledgement records for a sample of staff and one recent joiner. Test this yourself each quarter on two documents, one of them recently revised.
Related documents
Document | Relationship |
|---|---|
Policy Framework Standard | The rules this procedure runs (PF-01 to PF-12) |
Security Policy Document Template | The layout every policy is drafted on (step 5) |
Security Policy Hierarchy & Document Map | Choosing the tier and parent document (step 3) |
Policy Register & Review Schedule | Where every document is recorded (steps 4, 19, 33, 36) |
Policy Attestation & Acknowledgement Tracker | Where acknowledgements are recorded (stage 6) |
Policy Coverage Gap Assessment | Which topics are missing (stage 1) |
Policy Development & Approval Responsibility Matrix | Who drafts, is consulted, approves and is informed |
Policy Health & Attestation Reporting Workbook | The quarterly figures (PF-12) |
[[Security Exception & Waiver Standard]] | Deviations from any document (PF-10) |
Adapting this template
Guidance — delete before approval
Small organisation: a shared folder with read-only rights can be the policy library, a shared mailbox the workflow, and an emailed form the acknowledgement record. Stages 2 and 3 can run together for a short document. Keep the approval by someone who is not the owner (step 13), the withdrawal of the old version (step 18) and the review notice (step 27); they are what an auditor tests.
Regulated entity (NIS2 or DORA): record that this procedure is part of your ICT risk management framework. Set every tier's review to 12 months, not 24 for procedures and guidelines (DORA Article 6(5)), and treat a major ICT-related incident as a trigger in every case. Policy-tier documents go to the management body, whose minutes give the approval date the document shows (Delegated Regulation (EU) 2024/1774 Article 2(2)(b)).
IT run by a service provider: the provider may draft procedures for the systems it runs (stage 2) and is consulted on documents it must follow (stage 3), but your own people own and approve them. The provider's staff acknowledge the policies that apply to them; require this, and notice of changes to its own procedures, in the service agreement.
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 7.5.2 — Creating and updating | Stages 2 to 4: identification, format, review and approval |
ISO/IEC 27001:2022 | Clause 7.5.3 — Control of documented information | Stages 5 and 8: publication, withdrawal, archiving and retention |
ISO/IEC 27001:2022 | Annex A 5.1 — Policies for information security | Whole procedure: policies approved, published, communicated, acknowledged and reviewed |
ISO/IEC 27001:2022 | Annex A 5.37 — Documented operating procedures | Whole procedure, as a documented operating procedure |
NIST CSF 2.0 | GV.PO-02 — “Policy for managing cybersecurity risks is reviewed, updated, communicated, and enforced to reflect changes in requirements, threats, technology, and organizational mission” | Stage 7: scheduled and triggered review; stage 6: communication |
NIS2 — Directive (EU) 2022/2555 | Article 21(2)(a) — “policies on risk analysis and information system security” | Whole procedure |
DORA — Regulation (EU) 2022/2554 | Article 6(5) — the ICT risk management framework is documented and reviewed at least once a year, and after major ICT-related incidents | Stage 7; regulated-entity tailoring |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(b) — ICT security policies indicate the date of their formal approval by the management body | Steps 14 and 15: the approval date recorded |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(j) — policies are reviewed in accordance with DORA Article 6(5) | Stage 7 |
DORA — Delegated Regulation (EU) 2024/1774 | Article 2(2)(k) — policies take into account material changes to the entity, the threat landscape or legal obligations | Steps 28 to 31: triggers and material changes |
Definitions
Term | Meaning in this procedure |
|---|---|
Acknowledgement | A person's recorded confirmation that they have read a named version of a policy and will follow it. |
Approval pack | The final text, change summary, material-change classification and comment log sent to the approver. |
Comment log | The record of every consultation comment and the response to it. |
Material change | A change to what anyone must do, to whom the document applies, to roles or consequences, or to a value people work to. It needs a new major version, consultation and re-acknowledgement. |
Next review date | The approval date plus the tier's maximum interval, or earlier. |
Policy library | The one place where approved security documents are published. |
Review notice | The message to the owner 90 calendar days before the next review date. |
Tier | One of Policy, Standard, Procedure, Guideline (PF-01). |
Trigger | An event that makes a review due before the next review date (PF-06). |
Working day | Monday to Friday, excluding [[public holidays where you are]]. |