What is the difference between policy drafting and policy approval?

Why drafting and approval are different governance steps

Drafting is where the policy is formed into a usable proposal: scope, intent, exceptions, and the behaviour the rule is supposed to enforce. Approval is a separate governance decision that tests whether the proposal is actually fit for use, aligned to business intent, and defensible under the organisation’s risk posture. The difference matters because a well-written draft can still be the wrong rule.

Drafting is usually owned by the subject matter owner or control designer, while approval belongs to the people accountable for governance, risk acceptance, and operational impact. That separation prevents the person shaping the wording from also being the only person judging whether the rule should exist, how strict it should be, or whether exceptions are acceptable.

A useful way to think about the split is that drafting creates candidate policy content, while approval converts that content into an authorised organisational rule. A draft can be revised many times without any authority to bind operations. Approval is the point at which the organisation says the rule reflects policy intent, not just an individual contributor’s interpretation.

What approval checks that drafting cannot

Approval is not a proofread. It should test whether the policy is internally consistent, whether the denial behaviour is explicit, whether exceptions are handled deliberately, and whether the rule can be operationalised without creating ambiguity for the teams that must enforce it. This is where governance turns a statement of intent into a usable control boundary.

Approval also checks for gaps that drafting often misses, such as unclear ownership, unenforceable language, hidden dependencies on other policies, or a rule that is too broad for the actual risk. A draft may describe the desired state, but approval asks whether the organisation can support that state with people, process, and tooling.

When the subject is a security policy, approval is the moment to confirm that the draft matches the control objective rather than the convenience of the drafter. The distinction is important in policy libraries and control frameworks, where a policy can look complete while still failing to define who is accountable, when review happens, and what happens when a request is denied.

Why the separation matters in practice

When drafting and approval are collapsed into one step, teams often release policy language that has not been challenged for unintended consequences. That is how vague rules, overbroad restrictions, or missing exception paths reach production and then have to be interpreted informally by operators.

The separation also creates traceability. Drafting shows how the requirement was translated into policy language, while approval shows who accepted the final trade-offs. If a policy later causes friction, audit questions, or control failure, the organisation needs both the draft history and the approval record to understand what was intended and who signed off on it.

For policy programmes that are reviewed regularly, the distinction helps keep change control clean. Small edits, emergency exceptions, and periodic refreshes should not bypass approval just because the underlying policy already exists. The policy may be old, but the governance decision still needs to be current.

Risk and Threat Considerations

The main risk is governance drift: a drafted policy is treated as authoritative before reviewers have confirmed that it matches business intent, risk tolerance, and denial behaviour. That creates control failures, inconsistent enforcement, and approval-by-default for rules that were never properly challenged.

Failure mechanism: A policy draft can move into production as if it were approved, especially when teams confuse authoring with authorisation or let operational urgency override review. That leaves the organisation with a rule that exists on paper but has not been validated as a governance decision.

Impact: The result is weak accountability, poorly defined exceptions, and policy language that may be enforced in ways the business never intended. In security settings, that can lead to overrestriction, underrestriction, or inconsistent denial decisions across teams.

Practitioner Guidance

What to verify: Treat drafting and approval as separate artefacts in the workflow. A reviewer should be able to see the requirement source, the draft text, the exception logic, and the explicit approval decision without assuming they are the same thing.

Decision rule: If the policy changes business behaviour, access, or denial conditions, require approval from the governance owner before publishing it. If it only changes wording without changing intent or enforcement, a lighter review may be enough, but the approval boundary should still be explicit.

Common mistake: Teams often ask subject matter experts to “approve” their own drafts without a separate governance check. That removes the independent challenge that approval is supposed to provide and makes policy quality dependent on the drafter’s judgement alone.

Practitioner takeaway: Drafting creates the candidate rule, approval makes it organisationally real, and the value of the separation is independent scrutiny before the policy can affect operations.

Related resources from NHI Mgmt Group

• Who should own approval policy for autonomous agent actions, IAM or application teams?
• When should firms prioritise compliance operations over new policy drafting?
• What breaks when AI agents can make network policy changes without explicit approval?
• Why do approval based authorization patterns need to keep policy and workflow separate?