Two planes, two jobs
The control plane decides what should be allowed and distributes that intent. The data plane applies it to live requests. This split is familiar from networking and cloud platforms, and it applies equally to policy. Access-control literature uses related terms: a policy decision point evaluates rules, and a policy enforcement point applies the result. In practice a policy control plane manages policy and the decision logic, while enforcement points sit in the request path.
Keeping the roles separate has a practical payoff. You can change policy without redeploying applications, and you can scale enforcement without scaling authoring tools.
Where decisions are evaluated
Decision logic can run in three places. It can be remote, with each enforcement point calling a central service. It can be local, with a library or sidecar holding a copy of policy next to the application. Or it can be embedded in the platform, as with admission hooks. Remote evaluation is simple to update and audit but adds a network hop. Local evaluation is fast and resilient but must be kept in sync.
Most mature designs combine them. Policy is authored and approved centrally, pushed to local decision points and evaluated in the request path, with decision logs streamed back.
Failure behavior must be designed, not discovered
Every enforcement point needs a documented answer to one question: what happens when the control plane or decision service is unreachable? Failing closed protects data but can stop the business. Failing open keeps the business running but can silently remove protection. The right answer differs by resource. A payments API may fail closed, while an internal wiki may fail open with alerts.
- Define the failure mode per resource class, and record it with the policy owner.
- Cache the last known good policy locally, with a maximum age.
- Alert when an enforcement point is running on stale policy.
- Test the failure mode in a drill, not only on paper.
Latency budgets
Policy evaluation sits in the request path, so it consumes time that the user or the calling service feels. Set a latency budget for the decision, measure its distribution rather than its average and watch the slowest requests. Large data sets consulted during evaluation, such as group membership, are the usual cause of slow decisions. Precompute or cache what you can, and keep the rest small.
Ownership and acceptance testing
Assign clear owners to each plane. The platform team may own enforcement points while the security team owns policy content. Acceptance tests should prove three things: a change authored in the control plane reaches enforcement, a denied request is blocked with a clear reason, and every decision appears in the log with the policy version that produced it. If a supplier cannot show those three behaviors on your own systems, the architecture is not yet proven.
A worked scenario
Imagine an API gateway that checks each request against a policy decision service. During an outage of that service, the gateway can keep serving traffic from a cached copy of policy for fifteen minutes, then switch to denying all write operations while still allowing reads. The behavior is written down, owned by the service team, tested in a quarterly drill and visible on a dashboard that shows policy age at every gateway.
None of that is exotic. It is simply the control plane and data plane relationship made explicit, so that an outage becomes a planned state rather than a surprise.
