One of the most overlooked questions in GDPR compliance is also one of the most fundamental: who in your organisation actually has access to personal data, and why? In many organisations the answer is unclear. Access is granted when someone joins, rarely reviewed, and almost never removed in a structured way. Over time, more and more people accumulate access to data — often without any justification linked to their current role.
This is where compliance breaks down — not because of missing documents, but because of missing control. GDPR’s data minimisation principle requires that personal data is accessed only by those who need it, only to the extent they need it, and only for as long as their role requires it. Demonstrating that this is the case in practice is part of the accountability obligation under Article 5(2) GDPR.
What GDPR requires regarding access to personal data
GDPR does not prescribe a single specific mechanism for controlling who processes personal data. What it does require is that the controller ensures personal data is protected against unauthorised access and processed only by those acting on the controller’s instructions.
Article 29 GDPR states that persons acting under the authority of the controller or processor who have access to personal data shall process it only on instructions from the controller. This has several practical implications:
- access to personal data must be granted deliberately, not by default,
- the scope of access should be limited to what is necessary for the individual’s role,
- the controller must be able to demonstrate that access controls are in place and functioning.
In practice, this is typically achieved through a combination of role-based access controls in IT systems, confidentiality obligations in employment contracts or separate agreements, and an access register documenting who has access to what and on what basis.
Who needs access to personal data — and who does not
A common mistake is granting access based on seniority or convenience rather than actual need. A manager does not automatically need access to all data their team processes. An IT administrator does not need to read customer records in order to maintain the system. Access should follow function, not hierarchy.
In practice, the following groups typically require defined and documented access to personal data:
Customer-facing staff — sales, customer service, account management — access to customer contact and transaction data relevant to their accounts.
HR and payroll teams — access to employee personal data, limited to what their specific role requires. A recruiter does not need payroll data; a payroll processor does not need recruitment records.
Finance and accounting — access to invoice and financial data, limited to what is needed for tax and accounting obligations.
IT and system administrators — technical access required to maintain systems, which should be separated from access to the content of personal data where possible.
Contractors and temporary workers — access granted for the duration of the engagement and scoped strictly to the tasks performed.
Processors — external organisations processing data on behalf of the controller — are governed by a data processing agreement, not by internal access management.
How to implement access control in practice
Role-based access in IT systems
The most effective and auditable form of access control is role-based access control (RBAC) implemented directly in the systems that hold personal data — CRM, HR platform, ERP, email. Each role is assigned a defined set of permissions, and individuals are assigned to roles based on their function. When a role changes, permissions change automatically.
This approach minimises the risk of excessive access accumulating over time and makes it straightforward to demonstrate what access each individual holds.
Confidentiality obligations
Beyond system access, individuals who process personal data should be bound by a confidentiality obligation. This is typically included as a clause in employment contracts or in a separate confidentiality agreement signed at the start of employment. The EDPB recommends that organisations provide for the signing of a confidentiality agreement or include a specific confidentiality clause regarding personal data in contracts with employees and other data handlers.
The obligation should cover not only the duration of employment but also the period after it ends.
Access register
Regardless of the technical mechanism used, organisations should maintain a record of who has access to which categories of personal data. This does not need to be a complex document — but it does need to be current, accurate and available for inspection.
A basic access register should record for each individual: their name and role, the categories of personal data and systems they can access, the date access was granted, and the date it was modified or removed.
The access lifecycle — grant, review, revoke
Access management is not a one-time decision. It is an ongoing process with three critical moments:
Grant — access should be assigned when an individual takes on a role that requires it, scoped precisely to what that role needs. Granting broad access “just in case” violates the data minimisation principle from day one.
Review — access should be reviewed whenever an individual’s role changes, and periodically regardless of changes — at least annually. The question to ask at each review: does this person still need this access for their current responsibilities?
Revocation — when an individual leaves the organisation or changes role, access must be removed promptly. A former employee with active access to personal data systems is one of the most straightforward and serious GDPR risks an organisation can face. It is also one of the easiest for a supervisory authority to identify.
Most common mistakes in access management
Access granted and never reviewed. Permissions accumulate as people change roles, take on new projects and then move on. Nobody takes responsibility for removing what is no longer needed.
Scope too broad. Granting access to “all customer data” when only access to a specific segment or system is required. This is a direct breach of the data minimisation principle.
No process for leavers. A former employee retains active accounts in CRM, HR and email systems for weeks or months after departure. This is both a GDPR risk and a practical security vulnerability.
No central overview. Access permissions are scattered across multiple systems, each managed independently. No single person or team has a complete picture of who can access what across the organisation.
No link between role and access. Access was granted based on an individual request or a manager’s decision, with no connection to a defined role profile. When responsibilities change, nobody thinks to review the permissions.
Access control in iGDPR
iGDPR includes a dedicated access management module that allows you to maintain a central register of who has access to which processing activities, track the history of changes, and set up review reminders. Access records are linked directly to the record of processing activities — so for every processing activity, you can see who is authorised to handle that data, and when that authorisation was last reviewed.
Summary
GDPR access control is not a technical setting — it is a compliance obligation. The data minimisation principle requires that personal data is accessed only by those who need it, only to the extent necessary, and only for as long as their role requires. Demonstrating this in practice means having role-based access controls, confidentiality obligations, a current access register and a process for reviewing and revoking access when circumstances change.
Key principles:
- access to personal data should follow function, not hierarchy or convenience,
- scope of access should be limited to what the role actually requires,
- access must be revoked promptly when someone leaves or changes role,
- a central access register supports accountability and audit readiness,
- periodic access reviews are essential — at least annually.
Frequently asked questions about GDPR access control
GDPR does not mandate a specific document format. What it requires is that personal data is processed only by individuals acting on the controller’s instructions, and that appropriate access controls are in place. How this is implemented — through role-based IT access, confidentiality agreements, an access register or a combination — is left to the controller.
Data minimisation means that access to personal data should be limited to what is strictly necessary for the individual’s role. Nobody should have broader access than their function requires. This applies both to the categories of data accessible and to the systems they can access.
Only those whose role requires it — typically HR, payroll and direct line managers for specific purposes. Access should be scoped: a recruiter does not need payroll records, a payroll processor does not need recruitment correspondence.
Whenever a role changes, and periodically regardless of changes — at least once a year. Access should also be reviewed after incidents or significant organisational changes.
Uncontrolled access breaches the data minimisation and accountability principles. It increases the risk of data breaches, makes it impossible to demonstrate compliance, and is one of the areas most readily identified during supervisory authority inspections.
Yes — anyone processing personal data on the controller’s behalf, whether an employee or a contractor, should have access limited to what their engagement requires, and that access should be removed when the engagement ends.
Manage access to personal data in one system — with a full audit trail
iGDPR lets you maintain a central access register linked to your record of processing activities, track every change, set review reminders and demonstrate compliance at any point. See how it works in practice.
START FREE TRIAL
