NHS England's decision to grant Palantir staff direct access to identifiable patient data highlights significant governance failures. This move contradicts the health service's 2023 assurance that "personal data remains protected and within the NHS at all times." It's a predictable outcome when organizations treat access control as a technical checkbox rather than a governance discipline.
Public-private data partnerships often fail not due to malicious intent, but because teams make preventable mistakes in designing permissions, communicating boundaries, and responding to operational friction. Here's what keeps going wrong.
Why These Mistakes Keep Happening
The core issue isn't technology. Organizations design data access frameworks during procurement, but operational pressures erode those frameworks after contracts are signed. When engineers need faster access to complete deliverables, and manual approval workflows create bottlenecks, teams choose expediency over control. The NHS briefing acknowledged that applying for individual permissions across hundreds of datasets had become "time-consuming" for contractors, including Palantir engineers. That's a process problem, not a justification for unlimited access.
Another factor is role confusion. When an organization treats a data processor as if it were an internal team, access controls drift. Palantir stated it is a "data processor" under GDPR, not a "data controller," meaning it can only process data according to customer instructions. But granting processor staff the same access as controller staff collapses that legal boundary in practice.
Mistake 1: Treating "Security Clearance" as an Access Control
Why it happens: Organizations assume government security clearance is enough for data access decisions.
The consequence: Security clearance evaluates trustworthiness and background. It does not define role-appropriate access or enforce the principle of least privilege. NHS England's statement that external consultants "must have government security clearance" addresses personnel risk, not data exposure risk. A cleared engineer still doesn't need access to identifiable patient records to configure data pipelines.
The fix: Separate vetting from authorization. Use security clearance as a prerequisite for employment, then apply role-based access control (RBAC) or attribute-based access control (ABAC) to limit what cleared personnel can actually see. Under GDPR Article 32, Technical and Organisational Measures require access restriction based on necessity, not just trustworthiness. Define access policies that map to specific job functions, not to clearance levels.
Mistake 2: Solving Process Friction by Expanding Permissions
Why it happens: Manual approval workflows don't scale when contractors need access to hundreds of datasets. Teams respond by granting broader permissions to reduce ticket volume.
The consequence: You've traded a workflow problem for a compliance problem. The NHS briefing revealed that contractors now have "unlimited access" to portions of the federated data platform to avoid the overhead of individual permission requests. This directly contradicts data minimization under GDPR Article 5(1)(c), which requires processing to be "adequate, relevant and limited to what is necessary."
The fix: Automate access provisioning with policy-based controls, not blanket permissions. Implement dynamic access management that grants time-limited, context-specific permissions based on the task. If an engineer needs to test a data pipeline, provision access to a pseudonymized subset for the duration of that sprint, then revoke it. Use attribute-based policies that evaluate role, project, and data sensitivity together. If your access request process is a bottleneck, fix the process, don't eliminate the control.
Mistake 3: Relying on "Technical Impossibility" Claims Without Verification
Why it happens: Vendors assert that their architecture makes misuse "technically impossible," and organizations accept this without independent validation.
The consequence: Palantir stated that using NHS data for unauthorized purposes would be "technically impossible due to granular access controls overseen by the NHS." But if NHS staff are granting unlimited access to non-NHS personnel, who is actually enforcing those granular controls? A system's theoretical capabilities don't matter if the governance layer overrides them. Public trust erodes when assurances conflict with disclosed practices.
The fix: Require independent audit of access controls, not vendor attestations. Under GDPR Article 28(3)(h), processors must "make available to the controller all information necessary to demonstrate compliance." Demand access logs, permission matrices, and evidence of least-privilege enforcement. Conduct your own penetration testing or hire third-party auditors to validate that controls work as described. Document these audits in your processing records under Article 30.
Mistake 4: Announcing Policy Changes After Implementation
Why it happens: Teams treat access control as an internal operational matter, not a public-facing commitment that requires stakeholder consultation.
The consequence: The Patients Association noted that patients were not consulted on "a significant change to who has unlimited access to patient data." When you've built public trust on a specific promise (data stays within NHS control), then quietly reverse that promise, you've created a legitimacy crisis. Polling showed more than two-thirds of the UK public are concerned about Palantir's public contracts. That concern compounds when changes happen without notice.
The fix: Treat access policy changes as material amendments requiring transparency and, where appropriate, renewed consent. If your original data protection impact assessment (DPIA) under GDPR Article 35 assumed restricted third-party access, and you're now expanding that access, you must update the DPIA and conduct Prior Consultation with your supervisory authority if the change introduces high-risk processing. Communicate changes to data subjects before implementation, not after media reports. Build a change control process that flags when access modifications trigger notification obligations.
Mistake 5: Logging Access Without Acting on the Logs
Why it happens: Organizations implement logging to satisfy audit requirements, but don't build response workflows around what the logs reveal.
The consequence: The NHS stated that instances when contractors see identifiable patient data are "logged." Logging is passive. If you're discovering through logs that contractors are regularly accessing identifiable data, that's evidence your pseudonymization pipeline is failing or your access controls are too broad. Logs without response are documentation of problems you chose not to fix.
The fix: Build alerting and review workflows around access logs. Set thresholds: if a contractor account accesses more than X records in Y timeframe, trigger a manual review. If identifiable data is accessed outside of approved pipeline maintenance windows, escalate immediately. Use your logs to refine permissions: if 90% of logged access events involve identifiable data that shouldn't be visible, your Role-Based Access Control policies are wrong. Treat logs as feedback, not just compliance artifacts.
Prevention Checklist
Before expanding third-party access to sensitive data:
- Update your DPIA to reflect the new access scope and conduct Prior Consultation if required
- Define role-specific access policies that enforce least privilege, regardless of security clearance
- Implement time-limited, task-based access provisioning instead of standing permissions
- Require independent audit of vendor access controls before granting expanded permissions
- Document the legal basis for processing and ensure it supports the expanded access model
- Notify data subjects of material changes to data access policies before implementation
- Build automated alerting on access logs that triggers review when thresholds are exceeded
- Establish a change control process that flags when access modifications require supervisory authority consultation
- Verify that pseudonymization occurs before data enters contractor-accessible environments
- Test break-glass access procedures separately from routine operational access
The NHS-Palantir situation isn't unique. It's what happens when access control becomes an obstacle to delivery and teams choose workarounds over redesign. If your approval process is slow, that's a signal to automate it with better policy engines, not to eliminate it by granting unlimited access. Every shortcut you take now becomes a disclosure you'll have to explain later.
