Policy Lifecycle: From Creation to Retirement

The Problem with Policies Nobody Maintains

In many organizations, the following happens: policies are written to build the ISMS or prepare for certification. Sometimes with great effort, sometimes as copies of templates from the internet. The policies are approved, placed in a folder, and then forgotten. Two years later, an audit approaches, and suddenly it becomes apparent: the password policy still demands a 90-day change cycle, even though the BSI no longer recommends that. The mobile device policy still mentions an MDM system that was replaced a year ago. And half the employees have never seen the current versions.

This is not a theoretical problem. It is one of the most common audit findings of all: outdated documents, missing acknowledgment evidence, no traceable change history. ISO 27001 explicitly requires in clause 7.5 (Documented information) that documents be controlled, kept current, and made accessible to relevant persons. And "controlled" does not mean "stored somewhere" but a defined process with responsibilities, versioning, and evidence.

That is exactly what a policy lifecycle process achieves. It ensures that every policy follows a defined path from the first idea to retirement and that this path is documented.

The Phases of the Policy Lifecycle

A complete policy lifecycle consists of seven phases. Each phase has defined activities, responsibilities, and deliverables.

Phase 1: Identify Need and Create Draft

Before you write a policy, it must be clear why it is needed. The need can come from various sources:

• Risk assessment: The risk analysis has determined that a specific topic needs to be regulated (e.g., mobile device usage).
• Regulatory requirement: A law or standard requires a documented regulation (e.g., NIS2, ISO 27001 Annex A).
• Security incident: An incident has revealed a regulatory gap (e.g., missing rules for cloud service usage).
• Audit finding: An internal or external audit has identified a missing policy as a nonconformity.
• Organizational change: New business processes, new technologies, or structural changes require new regulations.

Once the need is identified, drafting begins. The draft should not be created in a vacuum but on a clear foundation:

Content Preparation:

• Which risks should the policy address?
• Which legal or normative requirements must be considered?
• Are there existing regulations that are being supplemented or replaced?
• Who is the target audience (all employees, IT only, managers only)?
• Are there templates or best practices that can serve as a starting point?

Formal Structure: Every policy should follow a uniform structure. This makes reading, maintaining, and finding information easier. A proven structure includes:

1. Document header (title, version, status, author, approver, date)
2. Introduction and purpose
3. Scope
4. Terms and definitions (if needed)
5. Regulations (the actual content)
6. Responsibilities
7. Violations and consequences
8. References (parent documents, related policies)
9. Change history

The draft is saved with a "Draft" status and is not yet valid. It is initially made accessible only to reviewers.

Phase 2: Review and Alignment

The draft is reviewed by defined stakeholders. Who must review depends on the topic, but some roles are almost always involved:

• Subject-matter reviewers: Persons with expertise in the topic area. For a password policy, that would be IT management; for a physical access control policy, facility management.
• ISM (Information Security Manager): Checks consistency with the overarching information security policy and other policies.
• Data Protection Officer: Checks compatibility with data protection, especially for policies involving monitoring, logging, or employee data.
• Works council: Has co-determination rights for policies that regulate employee behavior or introduce control mechanisms. Involving this step early saves significant time later.
• Legal department/lawyers: For policies with employment law implications (violations, consequences) or contractual references (external service providers).

The review process should be structured:

1. The draft is sent to reviewers with a deadline (typically 5-10 business days).
2. Reviewers provide feedback in a traceable form (comments in the document, feedback form, ticket).
3. The author incorporates feedback and documents which changes were made and why certain feedback was not adopted.
4. For substantial changes, a second review round occurs.
5. The final draft is marked as "Review completed."

A common mistake in this phase: the review drags on endlessly because no timeframe is defined or the wrong people are involved. Set clear deadlines and define what happens if a reviewer does not respond (e.g., no feedback within the deadline is considered approval).

Phase 3: Approval

Approval is the formal act through which the policy becomes effective. It is granted by a defined authority, typically:

• Top management or CISO for overarching policies (information security policy, data protection policy)
• ISM for operational policies (password policy, clean desk policy)
• Department head for area-specific work instructions

Approval must be documented. This can be a digital signature, approval in the ISMS tool, or a documented email confirmation. What matters is that it is traceable who approved what and when.

Upon approval, the policy receives:

• A status: "Approved" or "In effect"
• A version number (e.g., 1.0 for the first release)
• An effective date (from when it applies)
• A planned review date (when it will next be reviewed)

Phase 4: Publication and Distribution

An approved policy that nobody can find is worthless. Publication ensures the policy is made accessible to the right people.

Central storage location: All valid policies should be available at a single, defined location. This can be an ISMS tool, an intranet section, SharePoint, or a documented file system. What matters is: there is exactly one location where the current version resides. Copies in email inboxes or on local drives are not controlled versions.

Access permissions: Not every policy needs to be accessible to everyone. An incident response policy with detailed escalation paths and contact information should not be publicly posted on the intranet. Define for each policy who may read it.

Active communication: Mere availability is not enough. New or substantially changed policies should be actively communicated:

• Email to the target audience with a summary of key points
• Mention in the next team meeting
• For far-reaching policies: accompanying training or information session
• Announcement on the intranet or internal newsletter

Phase 5: Acknowledgment and Training

Acknowledgment is the evidence that employees have received, read, and understood the policy. For an ISMS under ISO 27001, this evidence is important because it demonstrates that the organization has fulfilled its communication obligations (clause 7.4 of the standard).

Digital acknowledgment: The most efficient approach is digital confirmation. Employees receive the policy (or a link to it) and confirm with a click that they have read and understood it. The ISMS tool or a simple database stores who confirmed when.

Advantages of digital acknowledgment:

• Automated tracking (who has not yet confirmed?)
• Reminder function (automatic reminders after deadline)
• Audit-proof evidence
• Easy repetition upon updates

What to do about non-acknowledgment? Your process must also cover the case where employees do not confirm acknowledgment. A proven escalation:

1. Automatic reminder after 7 days
2. Second reminder after 14 days
3. Escalation to the manager after 21 days
4. Conversation between manager and employee

Accompanying training: Not every policy requires separate training. But for fundamental policies (information security policy, password policy, clean desk policy) or for substantial changes, accompanying training is worthwhile. The training should:

• Summarize the key content of the policy
• Explain why the rules apply (not just what, but why)
• Cover practical examples and frequently asked questions
• Conclude with a brief comprehension check (optional, but effective)

Training attendance is documented and serves as additional audit evidence.

Phase 6: Operational Phase and Event-Driven Updates

After publication and acknowledgment, the policy enters the operational phase. It is in effect, is applied, and forms the basis for technical and organizational measures.

During the operational phase, events may occur that require a premature update:

• Security incident: An incident shows that the policy has a gap or a regulation is not working.
• New threat: A new attack type or vulnerability requires additional regulations.
• Regulatory change: A new law, regulation, or amended standard necessitates adjustments.
• Technology change: A new system is introduced or an existing one replaced that affects the policy.
• Audit finding: An internal or external audit identifies a weakness in the policy.
• Employee feedback: Practical experience shows that a regulation is unclear, impractical, or contradictory.

Event-driven updates follow the same process as initial creation (draft, review, approval, publication, acknowledgment) but can be expedited if the change is minor. The policy should define what constitutes a "minor change" (e.g., correcting typos, updating contact persons) and what abbreviated approval process these follow.

Phase 7: Scheduled Review

The scheduled review is the heart of lifecycle management. It ensures that policies do not become outdated, even when there is no concrete reason for a change.

Review cycle: For most ISMS policies, an annual review cycle is recommended. For critical or rapidly changing topics (e.g., cloud security), a semi-annual cycle may be appropriate. For stable, fundamental policies (e.g., information security policy), a two-year cycle may suffice, provided the policy is not affected by normative changes.

What is reviewed? The review is more than a cursory glance at the document. It should systematically answer the following questions:

1. Is the policy still current? Have technologies, systems, or processes changed that the policy addresses?
2. Does the policy still align with the risk landscape? Have threats or vulnerabilities changed?
3. Have regulatory requirements been added or removed?
4. Were security incidents recorded that indicate gaps in the policy?
5. Is there feedback from employees or auditors regarding the policy?
6. Is the policy consistent with other policies and the overarching information security policy?
7. Are the stated responsibilities and contact persons still correct?
8. Is the policy being followed in practice? Are there indications of systematic violations or circumventions?

Review outcomes: The review has three possible outcomes:

1. No change needed: The policy is current. The review result is documented, and the next review date is set.
2. Minor change: Small adjustments (contact persons, references, wording). Abbreviated approval process.
3. Major change: Substantive revision. Full lifecycle process (review, approval, publication, renewed acknowledgment).

Even when no change is needed, the review result must be documented. An auditor will ask: "When was this policy last reviewed?" And you must have a verifiable answer.

Retirement and Archiving

Policies do not live forever. There are reasons why a policy is retired:

• Replacement: A new policy replaces the old one (e.g., when multiple individual policies are consolidated into a more comprehensive one).
• Obsolescence: The policy's topic is no longer relevant (e.g., a policy for a system that has been decommissioned).
• Organizational change: A restructuring renders the policy moot.

Retirement must occur formally:

• Decision and documentation by the approver
• Marking as "Retired" with date and justification
• Removal from the active storage location (employees must not accidentally use an invalid policy as the current one)
• Archiving with a defined retention period

Archiving is not optional. For several reasons, you must retain old policy versions:

• Audit evidence: An auditor may ask which policy was in effect at a specific point in the past.
• Legal disputes: In disagreements (e.g., termination due to policy violation), it must be provable which rules applied at the time of the violation.
• Learning effect: The change history shows how security requirements have evolved over time.

A typical retention period for archived policies is three to five years after retirement. Check whether industry-specific retention obligations require longer periods.

Versioning: More Than a Number

Versioning sounds trivial but is surprisingly often done incorrectly or inconsistently. Clean versioning is the foundation for knowing which version of a policy is valid at any given time.

Versioning Scheme

A proven scheme is based on major and minor versions:

• Major version (1.0, 2.0, 3.0): For substantial content changes that require renewed acknowledgment.
• Minor version (1.1, 1.2, 1.3): For minor changes (typos, contact persons, formatting) that do not require renewed acknowledgment.
• Draft versions (0.1, 0.2): For internal drafts that have not yet been approved.

Example of a version history:

Change History

In addition to the version number, every policy needs a change history documenting what was changed in each version. This does not need to capture every single text change, but the substantive content changes should be traceable.

The change history ideally belongs directly in the document (as a table at the beginning or end). This way, it is always with the document and cannot be lost.

Document Status

Every policy should carry a clear status:

Document Control: The ISO 27001 Perspective

ISO 27001 regulates document control in clause 7.5 (Documented information). The requirements can be grouped into three areas:

Creation and Updating (7.5.2)

When creating and updating, it must be ensured:

• Appropriate identification (title, date, version, author)
• Appropriate format and medium
• Appropriate review and approval

Control of Documented Information (7.5.3)

Documented information must be controlled so that it:

• Is available and suitable for use where and when needed
• Is adequately protected (against loss of confidentiality, improper use, loss of integrity)

Control includes:

• Distribution, access, retrieval, and use
• Storage and preservation (including readability)
• Control of changes (e.g., version control)
• Retention and disposition

This sounds bureaucratic but is fundamentally simple: it must be clear where the current version resides, who may read it, how changes are controlled, and how long old versions are retained.

Roles and Responsibilities in the Lifecycle

A functioning policy lifecycle requires clearly defined roles:

Policy Owner

The policy owner is the person who is content-responsible for the policy. Typically, the ISM for information security policies, the DPO for data protection policies, or a department head for area-specific policies.

Tasks:

• Creates and maintains the policy
• Initiates reviews and updates
• Incorporates feedback
• Ensures the policy is consistent with other documents

Approver

The authority that formally puts the policy into effect. Typically top management, the CISO, or the ISM, depending on the policy's significance.

Reviewer

Subject-matter experts who check the draft for content accuracy, practical feasibility, and consistency.

ISMS Coordinator

Handles the organizational process: monitoring deadlines, sending reminders, planning review cycles, tracking acknowledgments, performing archiving. In small organizations, the ISM often fills this role themselves.

Tools for Policy Lifecycle Management

The right tool makes the difference between a process that works and one that constantly stumbles.

Simple Solutions (for Small Organizations)

For organizations with few policies and a manageable team, a combination of file system and spreadsheet can work:

• Policies as Word or PDF documents in a central network drive or SharePoint
• An overview spreadsheet (policy register) with title, version, status, approval date, next review date, and responsible person
• Calendar entries for review dates
• Email-based acknowledgment (with archiving of confirmations)

This solution is cost-effective but scales poorly and is error-prone. Calendar entries get overlooked, email confirmations get lost, and the overview spreadsheet is not kept current.

Dedicated ISMS Tools

For organizations that seriously operate their ISMS (and certainly from a certain number of policies onward), a dedicated ISMS tool is the better choice. Tools like ISMS Lite offer exactly this integrated approach with automatic versioning, review reminders, and digital acknowledgment, 500 Euro pro Jahr for all modules without user limits. Good tools offer:

• Document workflow: Draft, review, approval as a defined workflow with status transitions
• Automatic versioning: Every change is versioned, the change history is generated automatically
• Review reminders: The system automatically reminds of due reviews
• Digital acknowledgment: Employees confirm with a click; the system tracks who has confirmed and who has not
• Audit trail: Every action (create, modify, approve, read) is logged
• Access control: Different roles (author, reviewer, approver, reader) with corresponding permissions
• Linking: Policies can be linked with risks, controls, and measures

Common Mistakes in the Policy Lifecycle

Mistake 1: No Defined Review Cycles

Policies are written and approved, but there is no mechanism to ensure they are regularly reviewed. Without review cycles, policies silently become outdated, and this is only noticed at the next audit. Define a review date for every policy and a tool that reminds you.

Mistake 2: Versioning Only in the Filename

Versions like "Password-Policy_v3_final_final2_corrected.docx" are not versioning. They are chaos. The version belongs in the document, not in the filename. And there is always only one current version at a defined storage location.

Mistake 3: Acknowledgment Is Not Tracked

The policy is sent by email, but it is not tracked who has read it. In an audit, it then cannot be demonstrated that employees were informed. Even a simple confirmation email is better than no evidence at all, but an automated solution saves enormously in the long run.

Mistake 4: Outdated Versions Remain Accessible

Old versions still sit on the intranet or file shares and are taken by employees as the current version. When publishing a new version, old versions must be actively removed or marked as invalid. Only the current version may reside at the active storage location. Old versions go to the archive.

Mistake 5: No Linking Between Policies

Policies exist in isolation even though they are related in content. The password policy does not reference the overarching access control policy, which in turn does not reference the information security policy. This lack of cross-referencing leads to contradictions and gaps. Every policy should explicitly reference parent and related documents.

Mistake 6: Policies Are Too Long and Too Complex

A 40-page policy that no employee ever reads completely misses its purpose. Policies should be as long as necessary and as short as possible. Detailed technical instructions belong in separate work instructions or manuals; the policy itself formulates the rules at a level understandable to the target audience.

Mistake 7: No Clear Approval Process

Who may approve what? If this is not clearly defined, two problems arise: either nothing is approved because nobody feels responsible, or everything is approved "somehow" without a formal act. Both are problematic for an audit. Clearly define who may approve which category of policy.

The Policy Lifecycle as a Management Process

It is worthwhile to view the policy lifecycle not as a one-time setup but as an ongoing management process. For this, you need:

A policy register: A central overview of all policies with status, version, last review date, next review date, and responsible person. This register is your management instrument. A glance at it shows you which policies are current, which need review, and where gaps exist.

An annual plan: Distribute reviews across the year so that they do not all fall due simultaneously. If you have 20 policies with an annual review cycle, plan two reviews per month instead of 20 in December.

Metrics: Simple metrics help you assess the state of your policy management:

• Percentage of policies with overdue reviews
• Average time from draft creation to approval
• Acknowledgment confirmation rate
• Number of event-driven changes per year

Management report: Once a year (e.g., as part of the management review per ISO 27001 clause 9.3), the state of policy management should be reported to executive leadership: how many policies exist, are they current, where is action needed?

Pragmatic Introduction in Five Steps

1. Inventory: Which policies already exist? In what condition are they (current, outdated, never approved)? Where are they stored? An overview of the ISMS documentation helps with the inventory.

2. Define the process: Establish the lifecycle process: who drafts, who reviews, who approves, how is acknowledgment organized, how often are reviews conducted? Document the process itself in a brief procedural instruction.

3. Choose a tool: Decide whether a simple solution (file system + register) or a dedicated tool makes sense. A simple solution often suffices for the start, but plan for scalability.

4. Clean up existing stock: Bring existing policies into the defined process: catch up on versioning, conduct reviews, obtain approvals, organize acknowledgment. This is the most labor-intensive step, but afterward the process runs smoothly.

5. Establish regular operations: Conduct reviews on schedule, track acknowledgments, maintain the policy register, collect metrics. The process becomes part of regular ISMS work.

Conclusion

Writing policies is the visible part of the work. Managing the lifecycle is the part that determines long-term success. A defined process for drafting, review, approval, publication, acknowledgment, review cycles, and archiving ensures that your policies do not become outdated, that employees are informed, and that you can provide evidence at any time during an audit.

Further Reading

• Writing an Information Security Policy: Structure, Content, and Example
• Building an ISMS: The Complete Guide for Companies with 50 to 500 Employees
• Key ISMS Roles: ISM, CISO, Risk Owner – Who Does What?
• Creating a Password Policy: Requirements, Example, and Enforcement
• Conducting an Internal ISMS Audit: Planning, Checklist, and Report

The effort is manageable once the process is established and a suitable tool supports it. The alternative is a document graveyard full of outdated policies that create neither security nor audit success. The choice should not be difficult.