A policy isn't finished the day it gets approved. It moves through six distinct stages before it's retired, and each one carries its own risk.
Most compliance teams can name the first two stages without thinking: draft it, approve it. Fewer can say who owns enforcement, or what triggers a review, or what "retirement" is even supposed to look like on paper.
This gap is where audit trails break. Not at the drafting stage, where most attention goes, but further down the line, where ownership gets fuzzy.
This post breaks down all six stages in order, what happens at each one, who typically owns it, and what goes wrong when a stage runs outside a governed system.
Why Each Stage Matters on Its Own
Policy lifecycle management usually gets described as one continuous process. In practice, it's six separate handoffs, and most compliance failures trace back to one specific handoff breaking, not the whole system collapsing at once.
A policy can have a clean drafting process and still fail at enforcement. It can sail through approval and still create risk because nobody flagged it for review two years later. Treating the lifecycle as a single blob hides where the actual gap is.
Looking at each stage on its own makes the gap visible.
Stage 1: Drafting
A policy owner creates the initial document. This usually happens in response to one of three triggers: a new regulatory requirement, an internal risk or audit finding, or an operational gap someone has flagged.
Who owns it: Typically the function most affected, compliance, risk, HR, or a business unit head, sometimes with legal input from the start.
What goes wrong: Drafts get written in isolation, without checking whether a related policy already covers the same ground. This is how organisations end up with two policies that partially contradict each other, both technically "current."
Stage 2: Review and Approval
The draft moves through a defined chain of stakeholders before it becomes official. For a BFSI or insurance organisation, this chain often spans legal, compliance, risk, and the relevant business head.
Who owns it: No single owner. This is the stage where a structured workflow matters most, because multiple people need to weigh in, in a specific order, without the process stalling.
What goes wrong: Approval chains run over email. A draft sits in one person's inbox for three weeks because they're on leave and nobody has visibility into where it's stuck. When an auditor later asks who approved a policy and when, the answer has to be pieced together from email threads instead of pulled from a record.
Stage 3: Publication
The approved policy reaches the people who need to follow it. Access gets controlled by role, so a lending ops policy reaches lending ops, not the entire company.
Who owns it: The policy owner, usually supported by whoever manages the document repository.
What goes wrong: Publication happens inconsistently. A new SOP goes out over email to some teams and gets missed by others. There's no record of who actually received it, which becomes a problem the moment enforcement is questioned.
Stage 4: Enforcement
Teams apply the policy in daily operations. The organisation needs a way to confirm the policy is actually being followed, not just that it exists.
Who owns it: Frontline managers and team leads, with compliance monitoring adherence at a higher level.
What goes wrong: This is the stage most often skipped entirely. A policy gets published and then nobody checks whether it's being followed until an audit or an incident forces the question. By then, the gap has usually existed for months.
Stage 5: Review and Revision
Policies get checked on a set schedule, or triggered by a regulatory change, and updated when needed. For RBI, IRDAI, and SEBI-regulated organisations, this stage often runs on a fixed annual or biannual cycle, plus ad hoc triggers when a circular changes.
Who owns it: The original policy owner, with compliance tracking review dates across the full document set.
What goes wrong: Nobody is tracking review dates in one place. A policy written three years ago, referencing a regulation that's since been amended, stays live because no one was prompted to check it.
Stage 6: Retirement
Outdated policies get formally withdrawn and archived, with a clear record of when they stopped applying and what replaced them.
Who owns it: The policy owner, with sign-off from compliance to confirm nothing downstream still depends on the retired version.
What goes wrong: Old policies don't get removed, they just get buried. Someone finds an outdated SOP in a shared drive, assumes it's current because it's the only version they can find, and follows it. Retirement without archival is almost worse than no retirement process at all, because it leaves a false source of truth in circulation.
What Breaks When a Stage Is Skipped
Three patterns show up repeatedly, and each one traces back to specific stages breaking down.
Fragmented, ungoverned documents trace back to gaps at drafting, publication, and retirement. Without a single repository, drafts, live policies, and retired versions all end up sitting in the same folders, indistinguishable from each other.
Approval bottlenecks with no audit trail trace back entirely to stage 2. Email-based approval chains have no structural way to show who signed off, when, and in what order.
Business users locked out of self-service trace back to enforcement and review. When nobody can query current policy status directly, they either wait on IT or work from whatever version they can find, which may not be current.
How PolicyOS Supports Each Stage
TartanHQ's PolicyOS is built around four capabilities that map directly onto the gaps above.
A centralised, version-controlled repository covers drafting through retirement. Every version of a document lives in one place, so a retired policy can never be mistaken for a current one.
Role-based approval orchestration covers stage 2 directly. Approval chains run through the platform, not email, with every approval, rejection, and edit logged automatically. There's no reconstructing who signed off from an inbox.
Conversational policy retrieval supports enforcement. Teams can ask a direct question about a live policy and get a precise, sourced answer, instead of relying on memory or an outdated copy someone printed out two years ago.
Natural-language business analytics supports review and revision. Compliance heads can query which policies are due for review, which are past due, and which reference outdated regulations, without pulling a manual report.
The Six Stages, in Order
Drafting
Review and approval
Publication
Enforcement
Review and revision
Retirement
Each stage needs a clear owner and a visible record. Skip the record-keeping at any single stage, drafting, approval, publication, enforcement, review, or retirement, and the audit trail has a gap at exactly that point.
See PolicyOS in Action
PolicyOS puts all six stages, drafting, approval, publication, enforcement, review, and retirement, on one governed platform, built for BFSI, insurance, and lending teams working under RBI, IRDAI, and SEBI requirements.
[See PolicyOS in action →]
Frequently Asked Questions
What are the key stages of policy lifecycle management? Six stages: drafting, review and approval, publication, enforcement, review and revision, and retirement.
Who should own policy approval? No single function. Approval typically spans legal, compliance, risk, and the relevant business head, run through a structured workflow rather than a single gatekeeper.
How often should a policy be reviewed? Most BFSI and insurance organisations run reviews annually or biannually, with additional ad hoc reviews triggered by regulatory changes.
What happens if a policy is never formally retired? It stays discoverable alongside current policies, creating a risk that someone follows an outdated version because they can't tell it's no longer active.
