Policy management lifecycle: from draft to attested to retired
In most firms, policies are where good intentions go to die. They are often treated as a checkbox exercise for an audit, resulting in 50-page documents that no one reads and even fewer follow. To build a robust GRC framework, you must treat policy management as a living lifecycle—moving from a drafted intent to a functional, attested, and eventually retired asset.
Michael McCarroll— Founder · 20+ yrs GRC, ISO 27001 lead implementer 16 min read Updated June 2026
The Drafting Phase: Rejecting Template Culture
The biggest mistake I see as a Lead Auditor is 'copy-paste compliance.' Founders often download a generic set of templates, change the logo, and call it a day. This creates immediate friction because the policy describes a business that doesn't exist, leading to non-conformities when the reality on the ground fails to match the written word. A policy must be a reflection of your actual risk appetite and operational capabilities.
Stage one of the lifecycle is scoping and drafting. Every policy should address a specific set of risks identified in your risk assessment. For ISO 27001:2022, this means aligning your policies with the relevant controls in Annex A. If you don't use mobile devices for work, you don't need a 10-page Mobile Device Management policy; you need a simple statement forbidding their use for company data.
Drafting should be a collaborative process involving those who will actually have to do the work. If you write an Access Control Policy without talking to your Lead Engineer, you will likely include requirements that break their deployment workflow. Start with the 'why'—the business objective—and move toward the 'what'—the mandatory requirements. Every policy needs a clear owner who is accountable for its performance.
Authorisation and Formal Approval
Once a policy is drafted, it requires formal authorisation. Under ISO 27001 Clause 5.2, top management must demonstrate leadership and commitment by ensuring the security policy is established and communicated. This isn't just about a signature; it's about the leadership team standing behind the rules and providing the resources needed to enforce them.
The approval process should be transparent and documented. In a small startup, this might be a Slack approval or a Jira ticket; in a larger firm, it's often a formal board-level sign-off. The key is to ensure that the document version being approved is the exact one that will be distributed. Version control is the hallmark of a mature GRC function, and failing here is a quick way to lose an auditor's trust.
Approval also includes a sanity check against legal and regulatory requirements. If you operate in the UK or EU, your privacy-related policies must be checked against GDPR/UK GDPR. If you handle credit card data, the PCI DSS requirements must be baked into your operational policies. This legal cross-walk ensures that by following the policy, the firm remains compliant by default.
Clear version numbering (e.g., v1.0, v1.1) to track iterative changes.
A change log at the start of the document detailing what was modified and why.
Formal approval by the ISMS Steering Committee or CEO.
A defined 'effective' date and a 'next review' date.
The Power of Attestation and Communication
A policy that sits in a Folder on a shared drive and is never seen by the staff is a liability. The 'Attestation' phase is where you transform the document into an enforceable internal law. Every employee must not only have access to the policy but must formally acknowledge that they have read, understood, and agree to comply with it. This is a critical legal and compliance step.
For new starters, this should be part of the onboarding workflow. However, the real challenge is recurring attestation. Whenever a policy is significantly updated, the entire relevant workforce needs to re-attest. This protects the company; if an employee goes rogue and bypasses a security control, your first line of defence in a disciplinary or legal situation is the signed attestation proving they knew the rule existed.
Modern GRC platforms streamline this by sending automated pings to staff. This removes the administrative burden of chasing people over email. From an audit perspective, being able to pull an 'attestation report' that shows 100% completion across the engineering team for the Secure Coding Policy is gold. It demonstrates that the policy is a 'living' document that is actively communicated to the group.
Maintenance and Monitoring for Policy-Reality Drift
The 'Check' phase of the Plan-Do-Check-Act cycle is where many GRC programmes fall apart. You must regularly monitor whether the policy is actually working. Is it making the company more secure, or just making everyone's life harder? This requires looking at metrics—for example, if your Password Policy is too complex, are people writing their passwords on sticky notes? If so, the policy has failed.
Maintenance involves keeping the document updated as the threat landscape shifts. If your firm moves from a purely AWS environment to a multi-cloud setup, your Infrastructure Security Policy needs to reflect that change immediately. You shouldn't wait for your annual audit to fix these gaps. A proactive policy manager is always looking for 'policy-reality drift' and correcting it before it becomes a risk.
Version history management is vital during this stage. When an auditor asks to see what your Information Security Policy looked like in June of last year, you must be able to produce that specific version. Maintaining an archive of old policies, clearly marked as 'Superseded,' prevents staff from following outdated guidance while keeping a clear audit trail for historical compliance.
Annual policy review cycles as a minimum standard.
Event-driven reviews (e.g., after a data breach or a major cloud migration).
Internal audits against the policy to check if people are actually doing what is written.
Stakeholder feedback loops to identify where policies are causing operational friction.
The Final Act: Retirement and Archiving
Policies do not live forever. Eventually, a policy will become obsolete because the technology it governed is gone, or the business has pivoted away from that service. Retiring a policy is a formal act; you don't just delete the file. You must notify the relevant stakeholders that the policy is no longer in effect to avoid confusion and redundant work.
The retirement process should include an assessment of whether the requirements from the retired policy have been absorbed into a new document. For example, if you retire a 'Remote Work Policy' to replace it with a broader 'Global Workforce Policy,' the transition must be seamless. This prevents 'compliance gaps' where a control is accidentally dropped during a document reshuffle.
Finally, retention of retired policies is a regulatory requirement in many sectors. You may need to hold onto copies of old policies for seven years or more to defend against legal claims or provide evidence for multi-year regulatory audits. Ensuring these are stored in a secure, read-only archive is the final step in a professional policy management lifecycle. This ensures you can always prove what the rules were at any given point in time.
Ready to automate your policy compliance?
ISO-STANDARD.app automates the policy lifecycle, from initial drafting and version control to automated employee attestation and evidence collection. Build a world-class GRC framework that doesn't just pass audits, but helps you close enterprise deals faster.
ISO-STANDARD.app ships a ready-to-adopt GRC workspace with the risk register, controls catalogue, policies and audit-ready exports already wired together — no spreadsheet sprawl, no consultant lock-in.
Prefer a conversation? Email hello@iso-standard.app — a real human responds within one business day.
Frequently asked questions
How often should I review my security policies?
At a minimum, policies should be reviewed annually or whenever a significant change occurs in your technical environment or business structure. Clause 5.2 of ISO 27001 requires management to ensure policies remain suitable and effective, which mandates a recurring feedback loop rather than a 'set and forget' approach.
What is the difference between a policy and a procedure?
A policy is a high-level statement of intent and direction, whereas a procedure is a step-by-step instruction on how to execute that policy. For example, your Access Control Policy might state that MFA is required for all systems, while your Onboarding Procedure details exactly which buttons to click in your IAM provider to enable it.
Who should own a policy within a startup?
Ownership should rest with the head of the relevant business function, not just the IT team. For example, the HR Director should own the Data Protection Policy, and the CTO should own the Secure Software Development Lifecycle (SSDLC) policy. The GRC team acts as the coordinator, not the sole author.
How do I prove to an auditor that employees have read the policies?
Modern GRC tools track attestation at the user level, providing a timestamped log of when an employee read and agreed to the policy. This digital trail is far superior to manual spreadsheets and is often required during SOC 2 Type II or ISO 27001 surveillance audits to prove the 'communication' requirement.
Action checklist PDF
Mirrors this guide with owners, artefacts & a 30/60/90-day plan.
