What breaks when third-party access to personal data is not recertified?

Why This Matters for Security Teams

When third-party access to personal data is not recertified, the issue is not just stale permissions. It becomes a control failure across privacy, access governance, and audit readiness. Processor accounts, contractors, and delegated administrators can keep reading, exporting, or administering regulated data long after the approved business purpose has ended. That leaves security teams unable to prove who still has access, which is exactly where recertification should create accountability. The Ultimate Guide to NHIs notes that only 5.7% of organisations have full visibility into their service accounts, a pattern that mirrors the visibility gap many teams see with third-party identities too.

That matters because privacy programmes depend on timely entitlement reviews, not just initial approvals. If a vendor, outsourcer, or partner account is never revalidated, the organisation may be operating on assumptions instead of evidence. OWASP’s Non-Human Identity Top 10 reinforces that long-lived access without governance is a persistent risk pattern, especially where credentials outlive the business need. In practice, many security teams discover this only after an audit exception, a data-sharing dispute, or an offboarding review has already exposed the gap.

How It Works in Practice

Recertification is the mechanism that forces a fresh decision on whether third-party access is still justified. For personal data, that decision should be tied to the current processing purpose, contract scope, data minimisation obligations, and any change in vendor role. The practical workflow is straightforward: identify every external principal with access, verify the business owner, confirm the data category involved, and require explicit reapproval on a fixed cadence. Where possible, access should be reduced to the minimum dataset and shortest duration needed, with revocation triggered automatically when approval lapses.

That is why modern identity governance is increasingly paired with zero trust and workload-focused controls. NIST’s Cybersecurity Framework emphasises continuous access management, while the 52 NHI Breaches Analysis shows how overlooked non-human and delegated access can persist across environments. For vendor access, best practice is evolving toward time-bound entitlements, just-in-time approval, and direct linkage between recertification outcomes and automated deprovisioning. If a processor account is still needed, the scope should be narrowed rather than simply renewed.

• Map every third-party account to a named sponsor and lawful purpose.
• Require periodic attestation for access to personal data, not just annual checkbox reviews.
• Revoke access automatically when the review window closes without approval.
• Separate read-only access from export, admin, and support privileges.
• Log every renewal, downgrade, and removal so auditors can trace the decision.

These controls tend to break down when third parties use shared accounts, embedded service credentials, or multiple subcontractors behind one vendor contract because ownership and accountability become ambiguous.

Common Variations and Edge Cases

Tighter recertification often increases operational overhead, requiring organisations to balance privacy assurance against approval latency and vendor friction. That tradeoff becomes more visible where third parties support business-critical systems, because delayed reapproval can interrupt service even when the underlying access is low risk. Current guidance suggests avoiding blanket renewals, but there is no universal standard for recertification frequency across all third-party models.

Edge cases include emergency support access, outsourced payroll or benefits administration, and data processors that only touch personal data indirectly through APIs or batch jobs. In those cases, the control should focus on actual data reach, not contract labels. A vendor may look low risk on paper while still holding durable credentials, backup access, or dormant administrative roles. The Ultimate Guide to NHIs — Key Challenges and Risks highlights this kind of hidden access sprawl, and the The 52 NHI breaches Report shows why dormant access paths remain dangerous long after initial provisioning. Where delegated administration is involved, recertification should include tool-level permissions, not just user lists.

Ultimately, if a third party can still reach personal data but no one can prove why, the organisation has lost control of the access decision itself.

Related resources from NHI Mgmt Group

• What breaks when third-party access is not reviewed continuously?
• What breaks when third-party SaaS access is never reviewed?
• Who is accountable when third-party access to personal data persists too long?
• When should organisations treat third-party SaaS access as privileged access?