Who should be accountable when access decisions in Django span both application code and an external policy layer?

Application teams should remain accountable for enforcing authorization in code, while platform or identity teams should own the policy model, role mappings, and governance rules. When access decisions span multiple systems, clear ownership prevents drift between business intent and runtime enforcement. The strongest operating model treats authorization as a shared control with explicit responsibilities for policy design, sync, testing, and review.

Why This Matters for Security Teams

When access decisions span Django application logic and an external policy layer, accountability is not a paperwork issue. It is the only way to prevent business rules, role mappings, and runtime enforcement from drifting apart. Application teams control the code path that actually grants or denies access, while identity or platform teams usually own the policy model and review process. That split must be explicit, or gaps appear during deployments, refactors, and emergency fixes.

NHIMG data shows that 97% of NHIs carry excessive privileges, which is a reminder that authorization failures usually come from unmanaged scope, not just broken authentication. The risk is amplified when service accounts, API keys, and automation tokens are permitted to do more than the application truly needs, especially if policy intent is documented separately from code. The Ultimate Guide to NHIs and the Top 10 NHI Issues both show how quickly that mismatch becomes operational debt.

In practice, many security teams discover ownership gaps only after an application change silently weakens a policy rule that no one was actively testing.

How It Works in Practice

The strongest operating model treats authorization as a shared control with clear boundaries. Application teams remain accountable for enforcing checks in Django views, serializers, services, and middleware. Platform or identity teams own the central policy layer, role definitions, entitlement mappings, and governance rules. That division works only if both sides agree on who approves changes, who tests them, and who responds when runtime behavior diverges from policy intent.

At implementation time, the policy engine should evaluate access at request time, using the current user or workload identity, resource context, and action requested. Django code should not assume that a policy decision made elsewhere will remain valid unless it rechecks the result and fails closed. This is where policy-as-code becomes useful: it makes reviewable rules, version control, and change approval possible without moving all logic into the application. For broader control design, the NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls are useful anchors for ownership, access control, and change governance.

• Application teams own enforcement points inside Django, including object-level checks and deny-by-default behavior.
• Identity or platform teams own the policy model, role-to-permission mapping, and review cadence.
• Both teams should share test cases for edge conditions, especially admin overrides and delegated access.
• Policy changes need traceability from business request to code deployment to runtime decision.

The Ultimate Guide to NHIs — Regulatory and Audit Perspectives is a practical reference for documenting those responsibilities. These controls tend to break down in fast-moving teams that ship Django changes without synchronizing policy versioning, test coverage, and approval workflows.

Common Variations and Edge Cases

Tighter separation of duties often increases coordination overhead, requiring organisations to balance speed of delivery against confidence in access decisions. In smaller teams, a single group may own both Django enforcement and the external policy layer, but current guidance suggests the responsibilities should still be named separately even when the same people wear both hats. That reduces ambiguity during incidents and audits.

There is no universal standard for this yet, especially when access logic is split across a monolith, background jobs, and a policy service. Some teams centralize almost everything in policy code, while others keep high-risk decisions in Django and use the external layer mainly for governance and review. The right choice depends on how often roles change, how sensitive the data is, and how much runtime context the policy engine can actually see.

For teams dealing with service accounts, API keys, or other non-human identities, the accountability model should also include secret rotation, entitlement reviews, and break-glass procedures. NHIMG’s Lifecycle Processes for Managing NHIs is relevant here because policy ownership without lifecycle ownership is incomplete. The practical failure mode is simple: a rule can be approved in the policy layer, but if Django still grants access through a stale code path, the effective control is already broken.

Related resources from NHI Mgmt Group

• What breaks when LLM access control is limited to application code instead of a central policy layer?
• Who is accountable when an application access token is stolen and reused for unauthorized access?
• How do policy-driven authorization and application code differ in access control?
• Who is accountable when access logs or policy decisions are missing during assessment?