GDPR access controls: least privilege over personal data, in practice
GDPR governs how you handle personal data of people in the EU. The security obligation sits in Article 32: put in place technical and organisational measures appropriate to the risk, with confidentiality of personal data named explicitly. The word doing the work is appropriate. GDPR tells you the outcome and expects you to justify how you got there.
For access, that means you cannot simply assert that personal data is protected. You have to be able to show who can reach it, why, and how you would know if that changed. When a regulator or a customer's data protection officer asks how you control access to personal data, they want to see whether the policy is true in your environment, not just that it exists on paper.
- GDPR tells you the outcome and expects you to justify how you got there. Article 32 expects technical and organisational measures appropriate to the risk, with confidentiality of personal data named explicitly.
- You cannot simply assert that personal data is protected. You have to show who can reach it, why, and how you would know if that changed.
- Data minimisation (Article 5(1)(c)) and protection by design and default (Article 25) mean narrow scopes on API keys and integrations and defaulting to the minimum access necessary.
- You cannot scope a breach within the Article 33 72-hour window if you cannot say who and what had access to the affected data.
- The gaps are rarely the obvious controls; they are the ones that decay quietly: personal data spreading into unmapped SaaS, access accumulating on role change, and former employees keeping logins to apps outside the directory.
what GDPR actually asks about access
A few articles raise the stakes around access:
- Article 5(1)(c), data minimisation. Personal data must be limited to what is necessary, which for access means narrow scopes on API keys and integrations rather than broad ones.
- Article 25, data protection by design and by default. Default to the minimum access necessary, not the maximum convenient.
- Article 30, records of processing. These assume you know where personal data sits and who processes it.
- Article 33, breach notification within 72 hours. You cannot scope a breach quickly if you cannot say who and what had access to the affected data.
the access work, mapped to the regulation
Know where personal data lives. You cannot apply least privilege to data you have not located. Map the systems that hold personal data: the CRM, the HR system, the support desk, the marketing platform, the data warehouse, and the SaaS tools that quietly accumulate it. This underpins Article 30 as much as Article 32.
Apply least privilege to those systems. Only people who need access to personal data for their role should have it. Narrow broad grants, especially in the CRM and support tools where access tends to widen as people change roles and nobody narrows it back.
Enforce strong authentication. Multi-factor authentication on the systems holding personal data is the clearest "appropriate technical measure" you can point to. Cover the awkward edges: admins, remote access, and any login outside single sign-on.
Keep access correct over time. Article 32 expects ongoing confidentiality, not a one-time setup. That is the joiner-mover-leaver lifecycle: access granted when needed, adjusted on role change, and removed when people leave, including the apps outside the directory.
Review and record. Article 32 expects you to regularly test the effectiveness of your measures. For access, that is recurring access reviews over the systems holding personal data, with a record of who reviewed what and what changed.
Control non-human access. Integrations and service accounts move personal data between systems on broad, often unreviewed scopes. An OAuth grant that can read your whole mailbox is access to personal data, whether a person is behind it or not.
where companies fall short
The gaps are rarely the obvious controls. They are the ones that decay quietly. Personal data spreads into SaaS tools that were never mapped against the records of processing. Access to the CRM or support desk accumulates as people change roles. Former employees and contractors keep logins to systems holding personal data because offboarding closed the directory account and missed the apps. Service accounts and integrations move personal data with broad, unreviewed scopes. And when a breach question lands, the honest answer to "who could reach this data" is a guess, which makes the 72-hour clock far harder to meet. None of this surfaces until someone asks: a regulator after an incident, a customer's data protection officer during due diligence, or your own team after a near miss.
a practical sequence
- Locate personal data. List the systems that hold it. Do not forget the SaaS tools outside the core stack.
- Map who can reach each one. Human and non-human. This is the access picture Article 32 assumes you have.
- Cut access to least privilege. Start with the highest-sensitivity systems and the broadest grants.
- Confirm MFA coverage on those systems, and document any exception with a reason.
- Fix the leaver path so access to personal data closes everywhere, not just the directory.
- Run and record an access review, then set a cadence so it stays current.
- Review integrations and service accounts that touch personal data, and revoke the scopes nobody needs.
let's start with a conversation
Most first conversations start with not quite knowing what you have or where to begin. That's normal, and it's exactly where we're useful.
Tell us what prompted this. An upcoming audit, an incident, a client's security questionnaire, or just a sense that things have gotten messy.
We'll take it from there
+48 783 762 997
julian@unshadowit.com
