Healthcare Access Controls Under GDPR: Security Engineer Guide - Readiness Authority

Scope

This guide focuses on GDPR Article 32 security requirements for healthcare systems handling patient data, emphasizing access control architectures and monitoring obligations. It's designed for security engineers implementing or auditing authentication systems, monitoring infrastructure, and breach notification processes in clinical environments where external practitioners access electronic health records.

Key Concepts and Definitions

External User Access: Healthcare providers often grant system access to private-practice physicians, specialists, and referring providers who aren't employees. These accounts pose elevated risk because they operate outside your physical security perimeter and organizational controls.

Trusted Third Party: Under GDPR, this includes anyone whose personal data you process in connection with patient care, family members listed as emergency contacts, designated medical proxies, or individuals who accompany patients to appointments. Their data receives the same protection as patient records.

Real-Time Monitoring: GDPR Article 32 requires security measures "appropriate to the risk." For systems holding hundreds of thousands of health records, this means detection capabilities that alert within minutes or hours. Enforcement actions consistently penalize delays that allow attackers to conduct multi-day exfiltration campaigns.

Breach Notification Scope: Article 34 requires direct notification to affected individuals when a breach "is likely to result in a high risk to the rights and freedoms of natural persons." You can't satisfy this by notifying only patients while ignoring the 202,246 trusted third parties whose data was also compromised, as CNIL made clear in the HPL enforcement action.

Requirements Breakdown

Article 32: Security of Processing

Requirement 32(1)(a): Pseudonymization and encryption of personal data

For healthcare systems, this means:

Encrypt data at rest in your EHR database.
Encrypt data in transit between clinical workstations and database servers.
Consider field-level encryption for particularly sensitive data elements (psychiatric notes, HIV status, genetic information).

Requirement 32(1)(b): Ability to ensure ongoing confidentiality, integrity, availability, and resilience

Your access control architecture must enforce:

Authentication that verifies user identity before granting system access.
Authorization that limits each account to records necessary for legitimate treatment.
Audit logging that records every access attempt and data retrieval.

Requirement 32(1)(d): Process for regularly testing, assessing, and evaluating effectiveness

Documented evidence should show that you:

Test authentication controls quarterly at minimum.
Review access logs for anomalous patterns.
Conduct penetration testing that specifically targets your external user access paths.

Article 34: Communication of Breach to Data Subjects

When you discover unauthorized access to health records:

Within 72 hours: Notify your supervisory authority (your national data protection authority).

Without undue delay: Notify affected individuals directly unless you can demonstrate the breach won't result in high risk to their rights. For health data, you'll rarely clear this bar.

Notification must include: Description of the breach, contact point for questions, likely consequences, and measures taken or proposed to address it.

Implementation Guidance

External User Authentication

The HPL breach began with compromise of a single doctor's account that accessed the system without VPN or multi-factor authentication. Your external access architecture should enforce:

VPN Requirement: External practitioners connect through an encrypted tunnel that:

Authenticates the device before allowing network access.
Routes all traffic through your security monitoring infrastructure.
Terminates automatically after periods of inactivity.

Multi-Factor Authentication: Require a second factor beyond passwords:

Hardware security keys for high-privilege accounts.
Push notifications to registered mobile devices for standard clinical users.
Time-based one-time passwords as a fallback option.

Don't make exceptions for "trusted" external users or long-term referring providers. The attacker in the HPL case accessed the system through exactly this type of account.

Access Control Scoping

The compromised account at HPL could access records for all hospital patients. Your authorization model should enforce:

Role-Based Access Control: Define roles that match actual clinical workflows:

Emergency department physicians see patients currently in ED.
Referring specialists see only patients they're actively treating.
Administrative staff see scheduling and billing data, not clinical notes.

Break-Glass Procedures: When clinicians need emergency access to records outside their normal scope:

Log the access with required justification.
Alert security team in real-time.
Review all break-glass access within 24 hours.

Regular Access Reviews: Audit user permissions quarterly:

Remove accounts for providers who haven't accessed the system in 90 days.
Verify that each account's scope still matches the user's current role.
Document the review process for GDPR compliance evidence.

Monitoring and Alerting

The attacker at HPL extracted data over several days without detection. Your monitoring infrastructure must alert on:

Volume Anomalies:

User downloads more than 50 patient records in a single session.
Account accesses records at unusual hours (2 AM to 5 AM for daytime clinicians).
Rapid sequential access to records with no clinical relationship.

Geographic Anomalies:

VPN connection from a country where you have no affiliated providers.
Login from two distant locations within impossible timeframe.
Access from IP addresses associated with VPN services or Tor exit nodes.

Behavioral Anomalies:

User who normally accesses 5-10 records per day suddenly accesses 500.
Account that typically views records now downloading them in bulk.
Access patterns that don't match the user's clinical specialty.

Your security operations team should receive these alerts within 15 minutes of the triggering event, not through daily batch reports.

Common Pitfalls

Assuming External Providers Need Full Access: Private-practice physicians don't need access to your entire patient population. Scope their access to patients they're actually treating.

Treating Monitoring as a Compliance Checkbox: Installing a SIEM doesn't satisfy Article 32 if nobody reviews the alerts or your detection rules don't match actual attack patterns.

Notifying Only Direct Patients: When you discover a breach, map out everyone whose data was exposed, including emergency contacts, medical proxies, and family members listed in records. CNIL fined HPL for failing to notify 202,246 trusted third parties.

Delaying Investigation to Avoid Notification Deadlines: The 72-hour clock starts when you discover the breach, not when you complete your investigation. Notify your supervisory authority within the deadline even if you're still determining the full scope.

Grandfathering Legacy Accounts: External users who've accessed your system for years still need VPN and MFA. Don't create exceptions based on tenure or relationship history.

Quick Reference Table

Control Domain	GDPR Article	Minimum Standard	Detection Timeframe
External authentication	32(1)(b)	VPN + MFA for all non-employee access	Immediate (authentication failure)
Access scoping	32(1)(b)	Role-based limits matching clinical need	15 minutes (anomalous volume)
Encryption in transit	32(1)(a)	TLS 1.3 or equivalent	N/A (preventive control)
Encryption at rest	32(1)(a)	AES-256 database encryption	N/A (preventive control)
Audit logging	32(1)(d)	All authentication and data access events	Real-time collection, 15-minute alerting
Access review	32(1)(d)	Quarterly audit of user permissions	N/A (periodic control)
Breach notification (authority)	33(1)	Within 72 hours of discovery	N/A (response requirement)
Breach notification (individuals)	34(1)	Without undue delay when high risk	N/A (response requirement)
Penetration testing	32(1)(d)	Annual test of external access paths	N/A (periodic control)

When you're implementing these controls, remember that GDPR doesn't specify exact technical measures. Instead, it requires security "appropriate to the risk." For a system holding 727,000 health records accessible to external users, that risk is high, and supervisory authorities will judge your controls accordingly.