Who should own DSPM accountability under UK GDPR?

Why This Matters for Security Teams

dspm accountability is not just an organisational chart problem. Under UK GDPR, the business must be able to show where personal data lives, who can access it, and what controls reduce exposure. That requires clear ownership for policy, discovery, remediation, and oversight. The NIST SP 800-53 Rev 5 Security and Privacy Controls framework is useful here because it treats privacy and security as shared control objectives rather than siloed duties.

The most common failure is assuming the security team can “own” DSPM on its own. Security can deploy tools, but it usually cannot classify data, confirm lawful processing context, or decide retention and deletion obligations without help from data governance and privacy stakeholders. Likewise, privacy teams may define policy but not operate the technical discovery and containment workflow. A workable model assigns one accountable owner, then defines explicit control responsibilities across the teams that create, store, move, and protect data. In practice, many security teams encounter DSPM only after a data exposure has already become an incident, rather than through intentional ownership design.

How It Works in Practice

In operational terms, DSPM accountability should sit with the data governance function because that team is best placed to define data domains, sensitivity labels, retention rules, and decision rights. However, the accountabilities that make DSPM effective must extend across security, privacy, application, and platform teams. UK GDPR compliance depends on traceability, not just tooling, so the organisation needs a repeatable process for inventorying personal data, prioritising exposure risks, and proving remediation.

A practical model usually works as follows:

• Data governance owns the policy: what data is in scope, how it is classified, and what constitutes acceptable exposure.
• Security owns technical detection: scanning cloud storage, databases, SaaS, and endpoints for sensitive data and risky permissions.
• Privacy owns regulatory interpretation: whether the processing context, retention, and sharing arrangements remain lawful.
• Application and platform teams own implementation: fixing over-permissive access, removing shadow copies, and hardening data pipelines.

That division aligns well with privacy-by-design expectations and with the control logic in EU General Data Protection Regulation (GDPR), even though UK GDPR is the applicable regime in this question. The important point is that DSPM is not a one-time scan. It is a governance workflow that links discovery, risk scoring, exception handling, and evidence collection. Mature programmes also connect DSPM findings to ticketing, SIEM, and access review processes so remediation does not stall after a report is issued. These controls tend to break down when data spans legacy estates, unmanaged SaaS, and developer-owned cloud accounts because ownership boundaries become unclear and remediation authority is fragmented.

Common Variations and Edge Cases

Tighter DSPM governance often increases operational overhead, requiring organisations to balance rapid discovery against the need for accurate classification and legal review. That tradeoff becomes sharper when the environment includes third-party processors, regulated research datasets, or engineering teams that move quickly and create data copies for testing.

There is no universal standard for this yet, but current guidance suggests that accountability should follow the control plane, not just the data owner. If an organisation centralises DSPM too aggressively, it can create a reporting function with no authority to fix issues. If it decentralises too far, findings will be duplicated, inconsistent, or ignored. The strongest model is usually a federated one: central policy and evidence standards, distributed technical action, and named escalation paths for unresolved exposure.

Edge cases also matter. For example, where personal data is embedded in AI training sets, logs, or analytics exports, DSPM accountability must include the teams managing those pipelines. In cloud-native estates, platform engineering may need to act as the execution layer even when data governance remains accountable. The same logic applies to NHI-related service accounts and automated workflows that can move or expose data at scale: they do not replace human accountability, but they widen the number of teams that must answer for control failures.

Related resources from NHI Mgmt Group

• Who should own CAASM outcomes in a mature security programme?
• Who should own remediation when a DAST finding reveals exposed application paths?
• Who should own the decision to remove public access from shared files?
• Who should own vishing response when the attack targets credentials or approvals?