GDPR access control and MFA requirements

What GDPR access control and MFA require in practice

The GDPR requires no audit, attestation or certificate, so when a customer, contract or regulator asks for access control evidence, the question is how your controls meet the security of processing duty in Article 32. Access control is one of the measures that duty expects, and the organization owns its controls. An implementation partner can prepare systems and evidence, but only an independent auditor or certification body issues reports or certificates. The European Data Protection Board's small business guide sets out the practical baseline: each user should have a unique identifier, shared accounts should be prohibited or tracked through logs, and authentication is considered strong when it combines at least two categories of factors.

The same guide recommends access on a need-to-know basis with differentiated authorisation profiles, a regular review of access rights (it gives six months as an example interval), and a documented access control policy covering joiners, leavers and role changes. Leaver accounts and temporary authorisations left in place are named as practices to avoid, so your evidence should show removal dates matched against HR records. Ask which systems hold personal data, who can reach them remotely, and whether every such path requires a second factor. Those answers drive the scope of any work.

Cost and timeline depend on scope, the number of systems and identity sources, and how mature your evidence already is. Confirm with your own team how many applications share credentials, whether remote access runs through a VPN with MFA, and whether access reviews are recorded. Any quote should follow from a written scope that lists these systems, the deliverables for profiles and review records, and who maintains the evidence after handover. Your access control records will also need to stand up to the enforcement context: the CNIL's 2026 fine against Hôpital Privé de la Loire cited external access without VPN or MFA, so remote paths deserve the first review.

Which access controls produce evidence an assessor accepts

Each access control below pairs a decision the organization makes with an artifact an assessor can sample. The same records also show whether the controls work in practice, because a policy without an export, a review sign-off or a removal ticket gives an assessor nothing to test. Confirm the exact expectations with your supervisory authority and against your own Article 32 risk assessment.

Unique accounts per user

Every person who touches personal data needs an individual identifier, and shared logins make it impossible to tell who did what. The EDPB's small business guide treats shared accounts as something to avoid unless their use is tracked through logs. Ask for an identity directory export listing each account, its owner and its status, and check that service accounts have a named owner and a documented purpose. Duplicate or generic accounts found in that export are the first thing an assessor will question.

Strong authentication with two factors

The EDPB's guide considers authentication strong when it combines at least two categories of factors, such as something the user knows and something the user holds. For remote and privileged access, the evidence is an MFA enrolment report showing which accounts have a second factor registered, plus the policy that enforces it. Check whether exceptions exist, who approved them and whether they expire. An enrolment rate without a matching enforcement setting is weak evidence.

Need-to-know access profiles

Access should follow role-based profiles that match what each team needs for its work, and the EDPB recommends differentiated authorisation profiles for this reason. The evidence is a role matrix that maps each profile to the systems, record types and actions it allows, together with the approval trail for any deviation. Illustrative example: a billing role may see invoice fields but not clinical notes. An assessor will compare live permissions against this matrix and look for broad groups that grant more than the matrix states.

Periodic access reviews

Access rights need a regular review, and the EDPB offers a six-month cadence as an example rather than a fixed rule. The evidence is a dated review record for each system, showing the account list reviewed, the reviewer, the decisions taken and the changes made afterward. Ask whether reviewers can see the actual permissions, not just group names, and whether unreviewed accounts are escalated. Sign-offs without changes made after them often signal that the review was not substantive.

Leaver and role-change removal

The EDPB lists forgotten temporary authorisations and leavers' accounts as practices to avoid, so removal must follow joiner, mover and leaver events. Evidence includes HR-triggered deprovisioning tickets with timestamps, role change records showing old permissions removed, and a sample of accounts that left the organization to confirm they are disabled. Check the gap between the HR end date and the account disablement, and whether temporary access carries an automatic expiry.

Remote access through VPN and MFA

The CNIL fined Hôpital Privé de la Loire EUR 500,000 under Articles 32 and 34 after finding that external access to its patient record system lacked VPN and multi-factor authentication. For this control, collect the network diagram showing that the record system is reachable only through the VPN gateway, the MFA configuration for that gateway and firewall rules that block direct internet access. Confirm these facts in your own environment, because the enforcement decision describes what a regulator examined, not a test specification.

What the 2026 CNIL fine against Hôpital Privé de la Loire shows

The French supervisory authority, the CNIL, fined Hôpital Privé de la Loire EUR 500,000 in a decision dated 3 September 2026, finding infringements of Articles 32 and 34 of the GDPR. The core failure was simple to state: external access to the hospital's patient record system did not sit behind a VPN and did not require multi-factor authentication, and access inside the system ignored the care-team need to know. An attack on that system affected data on 524,867 patients. The decision shows that a regulator will treat an exposed clinical system as a security failure in its own right, and will connect the access design to the scale of harm when data is taken.

For any organization that lets people outside its network reach personal data, the lesson is to treat remote access as a design decision with its own evidence. Confirm that every external path into a system with personal data passes through a controlled entry point, that the entry point enforces multi-factor authentication for every account, and that no system of record is reachable directly from the internet without that control. Then check whether the same accounts are limited to the records their role needs. A remote consultant, a vendor support engineer and a clinician working from home each need a different profile, and the review should show that the profiles were set that way on purpose.

Ask your team to walk the external access path end to end before an assessor or regulator does. List every route in, the authentication method on each, the roles that can use it, and the date each account was last reviewed. Where the answers are unclear, the gap is the finding. The EDPB's own guidance on securing personal data for small organizations treats unique accounts, strong authentication and need-to-know profiles as the baseline, and the Hôpital Privé de la Loire decision shows how a missing baseline control on remote access can carry both an Article 32 finding and an Article 34 finding about how individuals were informed.

How an access control readiness project moves from scope to evidence

The sequence turns an informal set of logins into a documented access model, with MFA and remote access controls in place and a dated review record that an internal DPO or independent assessor can test.

Scope the systems holding personal data
The controller's project lead, with the DPO or privacy lead, lists every system, database, file share, SaaS tool and remote access path that holds or reaches personal data, including patient, employee and customer records. Systems that are reachable from outside the network are flagged first. The output is a scoped system register with an owner named for each system. The step is done when the register is signed off and any system missing an owner has been assigned one.
Inventory accounts and roles
The IT team exports user lists, directory groups, service accounts and administrator accounts from each in-scope system and matches them to people who still work for the organization. Shared accounts are identified and either split into individual identifiers or documented with a compensating log trail. The output is an account inventory that maps each identity to a role and a business need. The step is complete when every account has a named human or documented service owner and every shared account has a recorded decision.
Define the access control policy
The information security lead drafts a written policy that sets out how access is requested, approved, changed and removed. It covers joiners, leavers and role changes, requires need-to-know access with differentiated authorization profiles, and states the review frequency. The EDPB's small business guide offers an example review interval of six months, which the organization should confirm against its own risk assessment. The output is an approved policy with a named owner and a version date. The step is done when management has signed it and the policy is linked from the access profile catalogue.
Implement MFA and VPN for remote access
Engineers configure multi-factor authentication for all remote and external access, using at least two factor categories, and route outside connections through a VPN or equivalent controlled gateway before they reach patient or customer records. Administrator and vendor accounts are included. Testers attempt login from outside the network without the second factor to confirm the control holds. The output is a configuration record and test results showing that unauthenticated or single-factor external access is refused. The step closes when those tests pass and are saved.
Align profiles with care and job roles
Role owners and the system team translate the policy into authorization profiles, removing broad default rights and limiting each profile to the data its role needs. For clinical or care settings, profiles reflect the care team's actual need to know, not general staff membership. Default accessibility settings are reviewed so that records are not open to an indefinite group of people without an individual's intervention. The output is a profile matrix with the permitted data for each role. The step is done when each in-scope account is mapped to one approved profile.
Run the first access review
The system owners compare the account inventory with the approved profiles and with current employment and contract status. Each account is marked as retained, changed or removed, and leavers and expired temporary authorizations are cleared. The reviewer signs off each system. The output is a dated review record listing exceptions and the action taken on each one. The step is complete when every exception has an owner and a closing date, and the review is scheduled for its next cycle under the policy.
Collect evidence in one file
The project lead assembles the scope register, account inventory, approved policy, MFA and VPN configuration records, test results, profile matrix and review record into a single controlled evidence file with an index and version history. Each item is named after the control it supports so an assessor can trace it. The output is an indexed evidence package. The step is done when someone outside the project can locate each item from the index without help.
Hand the package to the DPO or assessor
The organization passes the evidence file to its internal DPO or privacy lead for review, and to any independent assessor it has engaged. The DPO checks that the measures match the Article 32 risk analysis and the processing records. An independent auditor or certification body, where one is used, tests the evidence and issues any report. DeployOpen can prepare systems and evidence but does not issue reports. The output is a reviewed package with a list of open points. Confirm with the assessor which format and sampling approach they will use before handover.

Who owns each part of the access control work

The controller remains responsible for access control under the GDPR, whoever builds the systems. The organization decides which roles exist, which staff need which personal data for their work, and who approves each grant. These are business and legal decisions, and they cannot be delegated to a technical provider. The EDPB's small business guide frames access on a need-to-know basis with differentiated authorisation profiles, so the organization must define those profiles against its actual care, service or case workflows.

Policy and scope: A written access control policy covering joiners, leavers and role changes, with named owners.
Role decisions: Definition of authorisation profiles and which data each profile may see.
Approvals and sign-off: Documented approval for each access grant and each privileged account.
Periodic reviews: Scheduled reviews of access rights, with the reviewer accountable for the outcome.
Leaver and exception handling: Timely removal of accounts and a record of every temporary authorisation granted and withdrawn.

Before starting any engagement, confirm internally who signs the access policy and who owns each role matrix, since these decisions are the ones an assessor will ask about first.

What access control readiness costs and who gets paid

This table separates the cost components of GDPR access control and MFA work by who is paid, whether the cost is one-time or recurring, and what drives it up. No price is published, so treat every amount as something to confirm in a written quote. The main takeaway is that most of the cost sits in internal role design and periodic reviews, which continue after any implementation project ends.

Cost component	Who is paid	One-time or recurring	What drives the cost
Internal staff time for role design	Your own staff (salaried time)	One-time, then revisited when roles change	Number of systems holding personal data, number of distinct care or business roles, and how well existing roles are documented
Access reviews and leaver removal	Your own staff, line managers and system owners	Recurring	Review frequency the EDPB guide suggests (for example every six months), headcount, and how many accounts sit outside central identity management
Identity provider and MFA licences	Software vendor or licensing reseller	Recurring, usually per user or per account	Number of users, external and remote accounts that need MFA, and whether you already hold licences for a directory service
Self-hosted identity and MFA platform setup	Implementation partner, under a written fixed scope	One-time, with later upgrades and support as separate items	Number of applications to integrate, custom authentication flows, hardening work, and documentation volume
Remote access gateway (VPN or equivalent) and MFA integration	Implementation partner and your network team	One-time setup, recurring operation	Number of external access paths, legacy systems that cannot use MFA, and monitoring requirements
External assessor or auditor fees	Independent auditor or certification body, if you commission a formal attestation or certification	Usually recurring with each assessment cycle	Scope of the assessment, number of systems sampled, and whether you pursue a voluntary Article 42 certification

What makes access control work longer or costlier

Access control under the GDPR is rarely slow because of one hard problem. The effort usually comes from how many systems hold personal data, how many kinds of users reach them, and how much of the access history is already documented. Each driver below is worth sizing before you ask for a quote, because each one changes the scope of work.

Systems holding personal data

Every application, database, file share, backup console and admin tool that holds personal data is part of the access control scope. Map them first with the record of processing, since a system missing from the inventory usually has no owner, no review and no leaver removal. Ask whether each system can be placed behind the same identity provider. Consolidating identity sources is often the step that most reduces the number of separate accounts to govern.

External and third-party users

Patients, customers, contractors, support vendors and processor staff who reach systems from outside the network widen the scope considerably. The CNIL's decision on Hôpital Privé de la Loire (3 September 2026) turned on external access to a patient record system without VPN or multi-factor authentication, so remote paths deserve their own inventory line. Ask every third party which accounts they use, who approves them and how they are removed when the contract ends.

Legacy applications without SSO or MFA

Older applications that cannot delegate login to a central identity provider, or cannot enforce a second factor, force compensating controls such as a gateway in front of the application or a privileged access broker. These add build and run effort that recurs as long as the application stays in service. Check whether a vendor patch, a configuration option or a replacement plan exists before scoping the work, and document the risk decision for any system you keep.

Number of roles and profiles

The more distinct roles a system has, the more profiles must be designed, tested and reviewed. The EDPB guide for small business recommends differentiated authorisation profiles built on need to know, so the cost depends on how many real care, support or finance tasks must be separated. Start by listing roles against the data each one needs, and remove profiles that exist only because access was granted case by case in the past.

Shared and orphaned accounts

Shared accounts and accounts left behind by former staff or temporary authorisations make both the fix and the evidence harder. The EDPB guide for small business asks for a unique identifier per user, with shared accounts prohibited or tracked through logs. Removing shared accounts first is usually the cheapest way to shorten the project, because every later review depends on knowing who did what. Ask for a count of shared and dormant accounts in the initial assessment.

Maturity of existing evidence

An organization with a current access control policy, recent review records and tickets for every joiner, mover and leaver needs far less preparation than one reconstructing its history from memory. Evidence is what an independent assessor or a supervisory authority will ask to see, so gaps in records often cost more than gaps in technology. Ask a prospective partner how they will collect and retain review and removal records during the work, not only at the end.

Questions buyers ask about GDPR access control and MFA

Does the GDPR require multi-factor authentication by name?

No. The GDPR does not name MFA. Article 32 requires the controller and processor to apply appropriate technical and organizational measures for the risk, and strong authentication is one of the measures regulators look for. The EDPB's guide for small businesses treats authentication as strong when it combines at least two categories of factors, such as something you know, something you have, and something you are. Most assessors will expect MFA for remote access and for any account that reaches large volumes of personal data, because a password alone rarely meets the risk test for those cases. Confirm the expected level for your own data with your data protection officer or supervisory authority guidance.

Is there a GDPR certificate for access control?

No. The GDPR requires no audit, attestation or certificate. Certification under Article 42 is voluntary, is issued for at most three years by accredited certification bodies or supervisory authorities, and does not reduce the controller's or processor's responsibility for compliance. Buyers who ask for proof usually want written evidence instead: an access control policy, a user account register, MFA configuration exports, access review records and leaver removal logs. An independent auditor can test that evidence, but no body issues a GDPR certificate for access control as such.

How long does it take to put access control and MFA in place?

No duration has been established for this work, so ask any partner to state one in writing before work starts. The time depends on how many systems hold personal data, whether identity is already centralized, how many remote access paths exist, and how many accounts are shared or unmanaged today. DeployOpen works on fixed scope, so the timeline is agreed in a written scope document that lists the systems, the deliverables and the evidence to be produced. Ask for the assumptions behind any timeline, including who in your organization must approve role profiles and access reviews.

Can our own team implement GDPR access control without a partner?

Often yes, if the team has identity and network skills and time to document the work. The GDPR does not require an outside firm, and the controller stays responsible either way. The work falls into four parts: defining need-to-know profiles with business owners, enforcing unique accounts and MFA on each system, running periodic reviews, and writing the policy and evidence. Teams often underestimate the second and third parts, since shared accounts and orphaned access tend to surface only when someone checks every application. An internal team can also ask an implementation partner to prepare systems and evidence for an independent assessment, while keeping ownership of the decisions.

What does the work require from our staff?

It requires time from people who know the data, not just from the IT team. Business owners must define which roles need which records, because the EDPB expects access on a need-to-know basis with differentiated authorization profiles. HR must notify IT of joiners, leavers and role changes promptly, since forgotten leavers' accounts and temporary authorizations are practices the EDPB lists to avoid. Staff who use remote access need to enroll in MFA and accept new sign-in steps. Plan for a short training session and for managers to confirm access during each review cycle. The EDPB's example review interval is every six months, which you can adopt or change based on your risk assessment.

Must a processor warn us if one of our instructions breaks the GDPR?

Yes. Under Article 28(3), the processor must immediately inform the controller if, in its opinion, an instruction infringes the GDPR or other data protection provisions. This matters for access control because a controller may instruct a processor to grant broad or shared access that conflicts with the principles of need to know and unique accounts. The duty does not make the processor responsible for the controller's choices, but a processor that stays silent on a clear conflict weakens its own position. Put this in the processing agreement and agree a named contact for these notices so that the warning reaches someone who can act on it.

How to choose a consultant or assessor for access control evidence

Access control evidence for GDPR is only useful if the people producing it and the people judging it are kept apart and the work is clearly defined. The cards below cover the checks that separate a sound engagement from one that leaves gaps in your records. Review each one with your DPO, security lead and procurement team before a written scope is agreed.

Separate the preparer from the assessor

A firm that configures your identity platform, writes your access policy and then certifies that the result works has marked its own homework. Ask whether the same firm or any of its staff will act as an independent assessor for the same scope. Where a regulator, certification body or auditor will later test the controls, that body must be independent of the team that built them. Get this confirmed in writing before scoping begins.

Ask for fixed-scope written deliverables

Access control work should end in named artefacts: a unique-account inventory, role and need-to-know profiles, a joiners, movers and leavers procedure, a review record and a remote access configuration. Ask for each deliverable to be listed with an acceptance test. Most engagements are fixed-scope, so ask who decides when the scope changes and how that change is priced and recorded.

Confirm experience with your identity platforms

Access control depends on the products in use: the directory, single sign-on, VPN or zero-trust gateway, MFA method and the admin consoles of each application. Ask for hands-on experience with those specific platforms, not general security knowledge. Ask how the consultant would verify that every account is unique and that MFA covers remote access to patient or customer records, and request a sample of the configuration evidence they would produce.

Check how evidence is handed over

Evidence has to be exported in a form your team can keep, retrieve and show later. Ask where exports, screenshots, configuration files and review records will be stored, who owns them after the engagement and in what format they arrive. Confirm that the consultant will not keep copies of personal data beyond what the work requires, and that any access they hold to your systems is removed at handover.

Confirm DPO and legal sign-off

Access decisions shape what personal data staff can see, so the DPO or legal counsel should approve the access policy, the need-to-know profiles and any monitoring of access logs. Ask the consultant to name the approval step and show where the DPO's sign-off is recorded. If the consultant also acts as your outsourced DPO, check for a conflict of interest before accepting that arrangement.

Ask who will run the reviews later

Periodic access reviews and leaver removal recur long after the project ends. The EDPB's small business guide suggests a regular review of access rights, for example every six months, so the review cadence must be owned internally. Ask whether the consultant offers a retainer for ongoing reviews, and whether your own staff can run the same checks using the documented procedure. Make sure the handover includes the procedure and a trained owner.

How DeployOpen prepares access control systems and evidence

DeployOpen plans, implements and documents the access control and multi-factor authentication setup for self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. The organization keeps ownership of its controls, while DeployOpen prepares the systems and written evidence that support an assessment.

How we scope

Engagements are fixed-scope, with systems, user populations and access paths agreed in writing before work starts.
The written scope lists which platforms, remote access routes and privileged accounts the access control work covers.
Ongoing support, upgrades and continuous testing are available as a retainer after the initial scope is delivered.

How we build

Unique accounts, role-based profiles and multi-factor authentication are configured on the in-scope platforms and remote access paths.
Access to patient or personal data is designed around documented need-to-know roles, with leaver removal included in the offboarding process.
Security testing of the configured access paths is run to confirm that external users cannot reach records without VPN and MFA.

How we hand over

Deliverables include the access control policy, role matrix, configuration records and the review schedule for access rights.
Logs that show sign-ins, failed attempts and privilege changes are set up so your team can produce them on request.
Your staff receive documentation and handover sessions so they can run periodic access reviews after the engagement ends.

How we support

Retainers can cover periodic access reviews, configuration changes when roles shift, and re-testing after platform upgrades.
Support scope, response expectations and review cadence are written into the retainer agreement before it starts.
Questions about the independent assessment itself go to your auditor or certification body, since DeployOpen does not issue reports or certificates.