Who is accountable when an IDOR issue exposes customer or internal data?

Why This Matters for Security Teams

IDOR is not just a coding defect. It is an access-control failure that can expose customer records, internal documents, or operational data when the application trusts user-supplied object references too much. Accountability therefore extends beyond the developer who introduced the bug. It includes the application owner, engineering leadership, and the control owners who are expected to verify object-level authorisation before release.

That matters because repeated IDOR findings usually indicate a systemic design and assurance gap. NHIMG research shows that 97% of NHIs carry excessive privileges, which is a reminder that overbroad access becomes dangerous fast when a control is missing or bypassed. See the Ultimate Guide to NHIs — Key Research and Survey Results and NIST SP 800-53 Rev 5 Security and Privacy Controls for the control expectations behind least privilege and authorised access.

Security teams often miss that IDOR accountability is shared because the failure is usually visible only after data has already been accessed, copied, or exported in production.

How It Works in Practice

In practice, accountability for an IDOR exposure is assigned across the lifecycle of the application. Product and application owners are accountable for the business risk, engineering leadership is accountable for secure implementation, and security or platform control owners are accountable for testing, review, and governance evidence. That division is important because IDOR is usually preventable with design-time controls, not just incident response.

Practitioners should treat object-level authorisation as a required control, not a code-quality preference. The application must verify whether the authenticated user is allowed to access the specific record, file, or object at request time. This should be validated in threat modelling, enforced in code review, and exercised in pre-release tests using both positive and negative cases. The control expectation in NIST SP 800-53 Rev 5 Security and Privacy Controls aligns with this approach because access decisions must be explicit and reviewable.

For broader governance, the pattern should be tracked as a recurring assurance issue if it appears across services. NHIMG’s 52 NHI Breaches Analysis and Ultimate Guide to NHIs — Why NHI Security Matters Now both reinforce the same operational lesson: when access is too broad or too implicit, exposure becomes a design outcome rather than an isolated defect.

• App owner: accepts business risk and ensures remediation priorities are set.
• Engineering leadership: ensures secure-by-design review, testing, and release gates.
• Security control owner: defines the verification standard for object-level authorisation.
• Governance or risk: tracks repeat findings as an assurance failure, not a one-off ticket.

These controls tend to break down when legacy applications rely on direct object IDs without a central authorisation layer because inconsistent enforcement makes review and testing incomplete.

Common Variations and Edge Cases

Tighter object-level checks often increase development and testing overhead, requiring organisations to balance faster delivery against stronger assurance. That tradeoff becomes sharper in large platforms where many teams own different services, because accountability can blur unless ownership is written down.

Current guidance suggests that shared responsibility is the right model when a platform team provides reusable authorisation components, but the application team still remains accountable for using them correctly. There is no universal standard for this yet, so organisations should define who owns the control, who tests it, and who signs off on exceptions. If a data exposure affects a third-party integration, the vendor or consuming service may also share responsibility, but that does not remove accountability from the application owner.

Repeat IDOR findings in the same codebase usually mean the issue is rooted in architecture, not just implementation sloppiness. In those cases, teams should escalate the finding into secure design review, not merely patch the endpoint and close the ticket.

When customer data is exposed through an administrative interface, the accountable party is often the service owner and the internal system owner together, because privileged workflows still require the same object-level controls.

Related resources from NHI Mgmt Group

• Who is accountable when a banking breach exposes internal systems and customer data?
• Who is accountable when GenAI traffic is allowed to bypass policy controls and exposes sensitive data?
• Who is accountable when a connected app exposes Salesforce data?
• Who is accountable when a vulnerability report contains personally identifiable information or customer data?