Policy needs a lifecycle, not a deploy step.
A policy that can be changed without approval, signature, a recorded deployment state and a way back is not a control — it is configuration. The policy control plane is the surface that makes a change to authority an auditable event in its own right.
1. What this enforces
Who may change authority, and under what approval. The control plane governs the lifecycle of policy itself: authoring, review, approval, signing, promotion between environments, the deployment state actually in force, and rollback to a known-good version.
2. Where it enforces
Alongside the enforcement points rather than in front of them. B5 enforces in-process at the business method; the control plane is what decides which policy version those enforcement points are running, and proves which one was running at any past moment.
3. What evidence it produces
A record for every change: who authored it, who approved it, what was signed, when it was promoted, which environments received it, and what the previous state was. Drift between the declared policy and the policy in force is itself an event.
4. Why you cannot assemble this from what you already own
Identity systems do not version authority. External policy engines version their own rules but cannot attest that a given .NET process was enforcing a given version at a given time. A CI pipeline can deploy a policy file but produces no evidence a reviewer can use two years later. The gap is not the storage of policy — it is the chain from approval to the executing method.
5. What Q4 2026 adds
Central Policy Control Plane
Central administration for policies, permits, relationship models, versions, approvals, deployment status, rollback, ownership and delegated administration.
Provide four-eyes approval, scheduled activation, staged rollout, rollback and delegated administration.
Represent policy packages as signed immutable versions.
Policy-as-Code and GitOps
Human-readable signed policy bundles, CI validation, promotion, drift detection, environment comparison and rollback.
Multi-Tenant Administration
Tenant-isolated policy spaces, keys, evidence, delegated administrators, hierarchical tenancy and managed-service-provider controls.
6. Acceptance criteria
These are the conditions the capability must satisfy to be considered complete. They are quoted from the specification rather than paraphrased, because an acceptance criterion that has been reworded is no longer the criterion.
- Administrators can create, validate, approve, schedule, activate and roll back a policy without rebuilding an application. MF-001
- Every policy change records author, approver, ticket, hash, timestamp and affected environments. MF-001
- Separation of duties prevents an author from self-approving protected production changes. MF-001
7. What is still open
The following are genuinely undecided rather than merely undocumented, and each one changes what the capability is:
- Whether tenant policy spaces (MF-025) are isolated by key, by namespace or both, and what delegated administration may and may not change.
- Whether signed bundles are verified at load, at first decision, or continuously.
- What happens to in-flight decisions during a promotion — the same fail-closed question that revocation raises.
Every Q4 2026 extension is also held to four platform-wide requirements, six test classes and four release gates. They are published once, on the Q4 2026 roadmap, rather than repeated on every page.