Who is accountable when application-layer ERP data is stolen?

Why This Matters for Security Teams

When application-layer ERP data is stolen, accountability is rarely confined to a single console or team. The breach usually reflects a chain of control failures across the application owner, identity governance, privileged access, logging, and the data layer. NHIMG research shows that 80% of identity breaches involved compromised non-human identities such as service accounts and API keys, which is why incidents involving ERP data often begin long before the exfiltration event is visible. That context is covered in The 52 NHI Breaches Report and reinforced in the Ultimate Guide to NHIs — Why NHI Security Matters Now.

Security teams often misread ERP theft as a pure data-loss problem, but application-layer access usually depends on over-privileged service accounts, stale API keys, direct admin paths, or weak separation of duties. That means the accountable parties are the ones responsible for the access model, the operational controls, and the protection of records in transit and at rest. The issue is not simply who clicked the wrong link; it is who allowed the access path to remain available. In practice, many security teams encounter ERP compromise only after toxic entitlements and missing audit trails have already been in place for months.

How It Works in Practice

Accountability should be assigned along the control chain, not after the fact to one incident owner. The application owner is accountable for the ERP configuration and exposure model. IAM or PAM owners are accountable for privileged pathways, service account governance, and credential lifecycle controls. Data governance is accountable for classification, retention, and access oversight. If the ERP integrates with automation or agentic workflows, the identity model should also reflect workload identity rather than only human users, because an application can move data through APIs faster than a person can notice.

Practically, this means the investigation should map four questions: who could access the data, which identity used the path, what privileges were active, and whether the logging was sufficient to prove the sequence. Current guidance suggests pairing least privilege with just-in-time elevation and short-lived secrets, then validating those controls against request-time policy. For application identities, workload identity frameworks such as SPIFFE help establish what the workload is, while policy engines like Open Policy Agent help enforce what it may do at runtime. That approach aligns with the governance emphasis in Ultimate Guide to NHIs — Key Research and Survey Results, especially where secret sprawl and excessive privilege are the root causes.

• Assign one named owner for the ERP application, one for identity controls, and one for data governance.
• Review service accounts, API keys, and admin paths as first-class accountability surfaces.
• Require evidence from logs, entitlement history, and revocation records before closing the incident.

These controls tend to break down in heavily customized ERP environments because integrations, batch jobs, and legacy admin tooling create hidden privilege paths that are not covered by standard access reviews.

Common Variations and Edge Cases

Tighter access control often increases operational overhead, requiring organisations to balance faster business processes against stronger evidence of control ownership. There is no universal standard for every ERP stack, so the exact accountable party can shift depending on whether the data was accessed through a SaaS tenant, an on-prem application, a third-party integration, or a shared service account. What does not change is that shared responsibility does not mean no responsibility.

If the theft occurred through a vendor-managed connector, the internal owner is still accountable for approving the integration and monitoring its scope, while the vendor may be responsible for the connector’s technical execution. If the breach involved an autonomous workflow or AI-assisted process, accountability broadens to include the team that approved the agent’s tool access and runtime limits. This is consistent with emerging guidance from the Anthropic report on AI-orchestrated cyber espionage, which highlights how machine-driven operations can compress the time between access and exfiltration. In practice, accountability becomes clearest when each control owner can show the exact approval, expiry, and review path for the access that touched the ERP data.

Related resources from NHI Mgmt Group

• Who is accountable when authorization logic is split between the application and the data layer?
• Who should be accountable when an MCP integration exposes cross-tenant data?
• Who is accountable when a stolen session is used to pivot into SaaS platforms?
• Who is accountable when cloud data is exposed through a shared account or snapshot?