GDPR compliance shifts data liability to every organisation

At a glance

What this is: This is a GDPR-focused analysis arguing that organisations now carry direct responsibility for EU citizen personal data they hold and must be able to manage access, deletion, and compliance obligations.

Why it matters: It matters to IAM, privacy, and security teams because identity-linked data governance, retention, and access processes determine whether organisations can answer subject rights requests and reduce regulatory exposure.

By the numbers:

• Only 5.7% of organisations have full visibility into their service accounts.
• 71% of NHIs are not rotated within recommended time frames, increasing the risk of compromise over time.
• 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools.

👉 Read Ground Labs' analysis of GDPR liability and compliance responsibility

Context

GDPR is not just a legal checkbox, because it forces organisations to prove how personal data is collected, stored, processed, and deleted. For security and identity teams, the practical challenge is governance: if you cannot map where data lives or who can access it, you cannot reliably answer subject access or erasure requests.

The article frames GDPR as a liability shift rather than a one-time deadline. That is a useful lens for practitioners in IAM, privacy, and data security, because access control, retention policy, and auditability become the mechanisms that turn compliance from promise into evidence.

For organisations with heavy use of service accounts, automation, and shared platforms, the governance burden is larger than it first appears. That starting position is common rather than exceptional, which is why visibility and lifecycle control matter so much.

Key questions

Q: How should organisations prepare for GDPR data requests across distributed systems?

A: They should first build a current inventory of where personal data lives, which identities can reach it, and what retention rules apply. Then they need a repeatable workflow for access, correction, restriction, and deletion requests that produces evidence. Without that linkage, requests become manual and risky.

Q: Why do IAM and data governance need to work together for GDPR?

A: Because GDPR obligations are operational, not abstract. IAM tells you who or what can access regulated data, while data governance tells you what the data is, where it is stored, and when it should be removed. If either side is missing, accountability breaks down.

Q: What breaks when organisations cannot find all copies of personal data?

A: Erasure, retention, transfer governance, and breach scoping all break when personal data is not fully discoverable. If teams cannot locate copies in backups, replicas, logs, or analytics exports, they cannot reliably delete, protect, or prove compliance. Discovery is the foundation for every other GDPR control in cloud environments.

Q: Who is accountable when GDPR compliance fails across shared platforms and automation?

A: Accountability sits with the organisation that collects and processes the personal data, even when cloud services, vendors, or automation are involved. Shared platforms do not remove responsibility. Teams need named owners, documented controls, and audit evidence that covers both human and non-human access.

Technical breakdown

Why GDPR turns data handling into a governance problem

GDPR applies pressure on the entire data lifecycle, not just on storage. Organisations must know where personal data is collected, how it moves, where it is retained, and how it is deleted when a data subject exercises rights. That requires policy, inventory, and evidence, not just encryption or perimeter security. IAM matters because data often becomes inaccessible to the wrong person through excessive access, orphaned accounts, or poor service account governance. If identity control is weak, the organisation cannot reliably prove lawful processing or controlled access.

Practical implication: map personal-data systems to owners, access paths, and retention rules so subject rights requests can be executed and audited.

Subject access and deletion requests depend on identity-linked records

A Subject Access Request or a Right to be Forgotten is only manageable when the organisation can connect data to a person, a system, and a retention decision. In practice, that means metadata quality, searchability, and access logging are as important as the storage layer itself. Identity systems often hold the clues needed to locate records, especially in distributed SaaS and internal platforms. Without that link, deletion and disclosure become manual, error-prone, and slow, which increases regulatory and reputational risk.

Practical implication: ensure identity and data records can be correlated quickly across platforms before the organisation faces a statutory request.

Data transparency requires more than a policy statement

The article points to transparency as a competitive and regulatory advantage, but transparency only exists when the organisation can demonstrate control. That includes inventorying personal data, classifying it, restricting access, and preserving logs that show who accessed what and why. In modern environments, those controls are spread across IAM, data security, and governance tooling. Where non-human identities access personal data, the same rules should apply to service accounts and automation as to human users, because the regulator cares about accountability, not account type.

Practical implication: extend data access review and logging to non-human identities that touch regulated personal data.

NHI Mgmt Group analysis

GDPR exposes the cost of poor identity and data governance, not just poor legal process. The article is right to frame liability as organisational rather than technical alone. In practice, the ability to answer regulators depends on access control, retention enforcement, and audit evidence across human and non-human identities. The practitioner takeaway is that compliance breaks first where identity governance is incomplete.

Data subject rights become operational only when records are searchable and attributable. Subject Access Requests and erasure requests fail when data is fragmented across systems without consistent identity linkage. That creates a governance gap between policy and execution. The result is that privacy obligations depend on IAM, data mapping, and lifecycle controls working together.

Non-human identities are part of the GDPR accountability surface. If service accounts, tokens, and automation can reach personal data, they must be visible in access reviews and retention workflows. The article does not discuss NHIs directly, but the governance logic extends there immediately. Practitioners should treat machine access to regulated data as part of the compliance boundary.

Data transparency is a control outcome, not a communications claim. Organisations often talk about transparency as a trust message, but regulators need evidence. That evidence comes from inventories, logs, and policies that can be shown to hold under review. The practical conclusion is that transparency programs must be backed by measurable control coverage.

Compliance and brand risk are linked because defensible controls reduce both exposure and embarrassment. The article’s warning about fines and reputation is credible, but the deeper issue is whether the organisation can prove reasonable effort. That is where governance frameworks matter. Teams that can evidence control coverage are better positioned to absorb scrutiny without operational improvisation.

What this signals

Data transparency will increasingly be judged by control evidence, not policy language. For identity and privacy teams, that means service account visibility, access logging, and retention enforcement will be part of the audit conversation, not separate operational concerns. The best programmes will tie data inventories to identity records so subject rights can be executed without manual triage.

GDPR programmes that ignore non-human identities will miss a growing share of the access surface. As automation and shared platform use expands, the organisations that can see and govern machine access to personal data will be better placed to prove accountability. That is where identity governance becomes a privacy control, not just an authentication layer.

For practitioners

• Map personal data to access paths Build and maintain a record of where EU citizen data is stored, which systems process it, and which identities can reach it. Include human users, service accounts, and automated workflows in the same visibility model.
• Operationalise subject rights workflows Create a repeatable process for Subject Access Requests and erasure requests that ties identity records to storage locations, retention schedules, and deletion evidence. Test the workflow before a regulator or customer forces the timeline.
• Extend access reviews to non-human identities Review service accounts, API keys, and automation that can access personal data, not only employee accounts. Reconfirm business purpose, scope, and owner for every non-human identity with exposure to regulated information.
• Preserve audit evidence for regulatory defence Retain logs that show who accessed personal data, when access was granted, and how deletion or restriction actions were completed. A defensible evidence trail is what turns a policy into something a regulator can verify.

Key takeaways

• GDPR turns personal data handling into an ongoing accountability obligation, not a one-time legal milestone.
• Visibility, traceability, and deletion workflows determine whether organisations can answer subject rights requests without guesswork.
• Identity governance, including non-human access, is now part of the evidence base for privacy compliance and regulatory defence.

Key terms

• Subject Access Request: A Subject Access Request is a formal request by an individual to see the personal data an organisation holds about them. It requires the organisation to locate, review, and disclose relevant records within legal timelines while protecting other individuals’ information and maintaining evidence of the response.
• Right to be Forgotten: The Right to be Forgotten is a GDPR-driven request for erasure of personal data when specific legal conditions are met. Operationally, it demands coordinated deletion across systems, backups, logs where appropriate, and retention controls, with clear evidence that the request was handled correctly.
• Data Subject Rights: Data subject rights are the legal rights individuals have over their personal data, such as access, correction, restriction, or deletion-related requests. Organisations need validated workflows, identity checks, and audit evidence so those rights can be fulfilled consistently across systems.
• Data Transparency: Data transparency is the ability to show what personal data is collected, where it resides, how it is used, and who can access it. In governance terms, it depends on inventories, logging, retention controls, and accountable ownership rather than policy statements alone.

What's in the full article

Ground Labs' full article covers the operational detail this post intentionally leaves for the source:

• How the business liability argument maps to real GDPR enforcement and compliance exposure
• The practical impact of Subject Access Requests and Right to be Forgotten obligations on day-to-day operations
• Why poor transparency can become a reputational problem as well as a legal one
• How organisations should think about data discovery and governance in relation to personal data risk

👉 Ground Labs' full article expands on enforcement risk, subject rights, and the operational impact of non-compliance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It gives identity and security practitioners a practical foundation for governing automated access alongside human identity controls.