A policy decision point (PDP) is a component that evaluates an access request against applicable policy and context to determine whether it’s permitted. Its inputs can include the requesting identity, target resource, requested action and relevant environmental conditions.
For example, a policy may allow a finance analyst to post adjusting entries during the month-end close. The PDP evaluates whether those conditions are met. A policy enforcement point then applies the decision before the entries are posted.
The PDP supplies the authorization decision. Access-management controls activate any permissions required, and enforcement controls govern what the requester can actually do.
Key takeaways
- A PDP evaluates policy and request context. A policy enforcement point applies the resulting decision.
- Decisioning can run in a remote service, a local engine or embedded application logic.
- The requested action and target resource are essential parts of the authorization question.
- Missing context, conflicting rules and evaluation errors need explicit handling.
- Cached decisions need a defined scope, validity period and reevaluation conditions.
Quick facts: policy decision points
| Attribute | Detail |
| Primary responsibility | Evaluate an access request against applicable policy |
| Typical inputs | Identity, resource, action and relevant context |
| Output | An authorization result, with conditions or obligations where supported |
| Deployment options | Remote service, local policy engine or embedded evaluation |
| Related roles | Policy enforcement, policy information and policy administration |
| Important design questions | Input trust, policy conflicts, failure handling, decision freshness and enforceable conditions |
What is the difference between a PDP and a PEP?
A PDP determines whether an operation is permitted. A policy enforcement point (PEP) applies that determination on the protected access path. A PDP can go wrong through incorrect evaluation, missing context or stale policy. A PEP can go wrong when a request bypasses it or when it can’t apply the restriction the decision requires.
These are separate responsibilities, but they don’t require separate products or processes. An application can evaluate policy locally and enforce the result before touching data. A gateway can consult a remote decision service and reject unauthorized requests.
This page covers the decision side. For where enforcement happens, how to check for bypass paths and what enforcement evidence shows, see what is a policy enforcement point (PEP)?
Which inputs does a PDP evaluate?
The inputs depend on the policy and the protected operation. NIST SP 800-162 describes attribute-based access control as evaluating subject, object, requested-operation and, where relevant, environmental attributes against policy.
A practical request may include:
| Input | Example | Design question |
| Requesting identity | Engineer, service account or workload | How was the identity verified? |
| Target resource | A designated production service | Is the resource identifier unambiguous? |
| Requested action | Read logs, restart service or change configuration | Does the action match the operation the target will execute? |
| Relevant permissions | Role membership or resource entitlement | Are inherited and resource-level permissions represented accurately? |
| Task or purpose | Investigate an active incident | Is the purpose supported by trustworthy workflow evidence? |
| Environment | Device posture, time or deployment environment | How fresh and reliable are these attributes? |
| Approval state | Approval for a particular operation and duration | Does the approval apply to this exact request? |
A requester saying an operation is urgent doesn’t establish that an incident exists. Where policy depends on incident status, the decisioning system should get or verify that fact from an appropriate source.
Collect only the attributes that influence the decision. Extra context adds complexity and can expose sensitive information without improving authorization.
How does policy evaluation work?
A practical evaluation flow connects five responsibilities:
- Describe the request. Identify the requester, action and resource using consistent identifiers.
- Obtain relevant context. Retrieve or verify the facts applicable policy requires.
- Select and evaluate policy. Determine which rules apply and how their results combine.
- Return the result. Produce an authorization outcome and any supported obligations or constraints.
- Record the evaluation. Keep enough information to explain the decision without logging sensitive data unnecessarily.
A decision only holds for the identity, action and resource that were evaluated. If any of those change, the request may need a new decision. The decision also has to be one the protected path can actually apply: if it permits access only to designated fields, something downstream needs to be able to enforce that.
How are conflicting policies handled?
Several rules may apply to one request. A team policy might allow access while a resource policy restricts it.
Define how those results combine. For example, an organization may specify that an applicable prohibition overrides a general permission. The exact behavior depends on the policy model and its combining rules.
Test conflicting-policy cases explicitly. Each rule can evaluate correctly on its own and still produce an unintended overall result if the combination is poorly defined.
How do XACML and NIST describe a PDP?
OASIS XACML 3.0 defines a policy-based access control model with decision, enforcement, information and policy-administration roles. Its formal decision values are:
| XACML result | Meaning |
| Permit | Evaluation permits the request |
| Deny | Evaluation denies the request |
| NotApplicable | No policy or rule applies, or evaluation yields NotApplicable under the relevant combining rules |
| Indeterminate | An evaluation error prevents a conclusive result |
Applications have to define how these results are handled. NotApplicable and Indeterminate shouldn’t silently become permission to proceed.
XACML also supports obligations and advice attached to decisions. The enforcement side must fulfill applicable obligations as a condition of permitting access; if it can’t, it must not permit the operation. Advice is optional.
A workflow may require human approval before access proceeds. That requirement sits around policy evaluation. It isn’t one of XACML’s formal decision values.
NIST SP 800-207 uses a related Zero Trust model in which the policy engine and policy administrator together perform PDP functions. The engine decides whether access should be granted, and the administrator directs establishment or termination of the communication path.
Watch the terminology. The NIST policy administrator differs from an XACML policy administration point, which manages policies. State which model you’re using when you describe component responsibilities.
Where should a PDP run?
Decisioning can be deployed centrally or close to the protected operation.
| Approach | How it works | What to evaluate |
| Remote decision service | Applications or gateways request decisions over a network | Availability, request latency, context exposure and dependency failures |
| Local policy engine | Evaluation runs near the application, often using distributed policy | Policy synchronization, attribute freshness and version consistency |
| Embedded evaluation | Application code or an integrated library evaluates policy | Consistent implementation, policy updates and test coverage |
Central policy management can coexist with distributed evaluation. A shared policy source doesn’t require every operation to make a remote call.
Choose the deployment model around the workflow’s latency, availability, context and update requirements. Measure representative requests, including context retrieval and failure cases.
Example: a ledger decision changes with business context
This example illustrates a policy design, not a specific product deployment.
A finance analyst requests permission to post adjusting entries to the general ledger. Policy requires a verified identity, membership in the close team, an open month-end close window and an approved adjustment ticket.
| Request state | Illustrative decision | Reason |
| All required conditions are met | Permit | The adjustment fits the close policy |
| The analyst targets a different entity’s ledger | Deny | The target is outside the ticket’s approved scope |
| The analyst has left the close team | Deny | A required eligibility condition is no longer met |
| The ticketing system is unavailable | No permit; deny the protected operation under the configured failure policy | The system can’t establish a required condition |
| The close window ends before a later request | Deny after reevaluation | The earlier justification no longer applies |
The permit covers posting the approved adjustments only. It shouldn’t authorize unrelated operations, such as changing the chart of accounts. Each decision needs a clearly defined action and resource scope.
How should cached decisions and changing context be handled?
Caching can reduce evaluation overhead, but a decision is only valid within its defined scope and assumptions.
A cached permit can become inappropriate after a role change, incident closure, resource reclassification or policy update. Define:
- Which request attributes identify a reusable decision
- How long the result stays valid
- Which events invalidate it
- What happens when required context can’t be refreshed
- Whether sensitive operations require a fresh evaluation
A decision’s cache lifetime is different from a credential’s lifetime or a temporary entitlement’s duration. Expiring one doesn’t automatically invalidate the others. Where the underlying operation has its own authorization checks, the target may evaluate permissions again when the action is attempted.
How does a PDP relate to JIT access?
Just-in-time access controls when scoped permissions become available and when they end. A PDP can determine whether a temporary access request is justified and which conditions apply. These are distinct events:
- Decision: the request qualifies for temporary read access.
- Activation: the supported system establishes that access.
- Enforcement: the protected path permits reads and rejects prohibited operations.
- Revocation: lifecycle controls remove the temporary access.
Evidence should keep these events separate so reviewers can tell what was decided, what access became available and whether it was removed.
What changes for AI agents?
Agent workflows add delegation and task context, so policy may need to distinguish the originator, participating agents, tool, target resource and requested action. The PDP’s job stays the same: evaluate trustworthy context against policy and return a result the protected path can enforce. For the agent-specific model, see how runtime authorization works for AI agents.
How does P0 Security approach authorization decisioning?
In P0 Security’s platform, the decision point doesn’t stand alone. Each decision is tied to the access it activates and the evidence it leaves. The P0 Runtime Access platform connects identity context and runtime policy with authorization decisioning, scoped access activation, enforcement, revocation and evidence.
In P0’s model, runtime authorization determines whether and under what conditions a sensitive action may proceed. For supported workflows, the platform can establish temporary, task-scoped access. Where native enforcement is supported, the target system authorizes requested actions using the resulting identity and permissions.
P0 works alongside existing identity and access management (IAM) and privileged access management (PAM) systems. Specific capabilities and deployment behavior depend on the integration and workflow.
P0 determines whether the identities involved are authorized to take the requested action and enforces that decision before the action reaches the sensitive resource.
Summary
A policy decision point is only as good as its inputs and rules. Trustworthy context, explicit combining rules, defined failure handling and decisions scoped to the exact operation are what make its answers reliable.
Where the PDP runs is a deployment choice: remote, local or embedded. In every case, the decision still has to be activated and enforced somewhere else before it changes what anyone can do.
FAQs about policy decision points
Is a PDP the same as a policy engine?
A policy engine commonly performs authorization evaluation, but its relationship to the PDP depends on the architectural model. In XACML, the PDP evaluates authorization requests. In NIST’s Zero Trust model, the policy engine and policy administrator together perform PDP functions.
Does a PDP authenticate users?
Authentication establishes identity. A PDP uses verified identity and other context to evaluate authorization. One product may provide both capabilities, but they answer different questions.
Does every request need a remote PDP call?
No. Evaluation can run locally or use appropriately scoped cached results. The design must account for policy updates, context changes and decision validity.
Does a permit decision grant permissions?
The decision states what should be allowed. Separate access-management controls may need to create or activate permissions, and an enforcement point must apply the authorized scope.
What should happen when required context is missing?
Define an explicit handling rule. For sensitive operations, an inability to establish required conditions shouldn’t silently produce a permit. Record whether the request was denied by policy or couldn’t be conclusively evaluated.