Once you stop trusting the network, something has to decide whether each request is allowed, and something has to enforce that decision. Splitting those two jobs is the single most useful mental model in modern security architecture.
It is also very old. The vocabulary comes from access control work going back decades, and it turns out to describe almost every security product on the market.
The Two Roles
A policy decision point evaluates a request against policy and returns an answer. It needs inputs: who is asking, what device, what resource, what action, and what the current risk signals say.
A policy enforcement point sits in the path of the request and does what the decision says. It does not reason, it acts.
There is usually also a policy administration point where rules are written, and policy information points that supply the signals such as device posture, group membership, or threat intelligence.
This is the structure NIST SP 800-207 uses to describe zero trust, and it is why the model is coherent rather than a slogan.
Why Separating Them Matters
You get one place to change policy and many places to enforce it. Without the split, policy lives in dozens of consoles and drifts apart immediately, which is exactly the state most organizations are in.
You also get consistency. The same rule about who may reach the finance system applies whether the request arrives through a browser, an API, or a remote access client.
And you get auditability. A decision point that logs every decision with the inputs that produced it answers questions that are otherwise unanswerable during an incident or an audit.
Where Enforcement Actually Happens
At the network layer: firewalls and access lists, covered in next generation firewalls.
At the network edge: NAC deciding what a device may do when it connects.
At the access layer: ZTNA brokers and reverse proxies deciding per application.
At the identity layer: conditional access policies in your identity provider, which is where a great deal of modern enforcement actually lives. See identity and MFA.
In the application: authorization checks in code, which remain the last and most precise line.
In the data layer: row and column level permissions, encryption, and tokenization.
And in the cloud control plane, where an IAM policy is a decision point and enforcement point combined. See cloud security.
Policy as Code
Writing policy in a language, storing it in version control, testing it, and deploying it through a pipeline. The best known engine is Open Policy Agent, which uses a language called Rego and is widely used in Kubernetes and microservice environments.
The benefits are the ones you would expect from treating anything as code: review before change, history of who changed what and why, tests that catch a policy that would deny everyone, and the ability to run the same policy in several places.
The cost is that it is genuinely a new skill for most security teams, and a policy language is still a language you can write bugs in.
Designing for Failure
Every enforcement point in a request path is a dependency. What happens when the decision point is unreachable is an architecture decision, and it needs to be made deliberately.
Fail closed is secure and takes people offline. Fail open keeps the business running and removes the control exactly when something may be wrong. Cached last known decisions with a short expiry are the usual compromise.
The wrong answer is not deciding, because then the behavior is whatever the vendor chose by default and you find out during an outage.
Common Mistakes
Enforcement without logging. If a decision point does not record what it decided and why, you have a control you cannot audit or troubleshoot.
Policy scattered across products with no single view, which is how organizations end up unable to answer who can reach the finance system.
Rules that use IP addresses as identity. Addresses were never identity and in cloud and container environments they change constantly.
And policy that grows only in one direction. Access gets added and never removed, which is how least privilege quietly becomes most privilege over a few years.
Learn This at HackRange
This model is the thread that connects firewalls, NAC, ZTNA, identity, and cloud IAM. Once you see it, every product in the category becomes easier to place.