Should privacy teams track non-human identities as part of Law 25 compliance?

What Law 25 privacy compliance changes when non-human identities can access personal data

Law 25 compliance is not just a human-account exercise. If service accounts, devices, API credentials, or AI copilots can read, copy, or transform personal data, privacy teams need to treat those actors as part of the data handling chain. The practical question is not whether they “count” as people, but whether they can touch personal data without the controls, logging, and ownership needed for accountability.

That matters because privacy obligations depend on traceable handling, bounded access, and defensible purpose. A non-human identity can create exposure even when no employee directly opens the record, which means the privacy program has to understand who or what can reach data, under what authority, and with what evidence trail.

Which non-human identities belong in the privacy evidence chain

Any identity that can access personal data materially belongs in scope for privacy oversight, especially when it can operate continuously or at scale. That includes service accounts used by applications, device identities that sync or transmit data, integration credentials that move records between systems, and AI copilots or assistants that can retrieve personal data as part of a workflow.

For privacy teams, the useful test is whether the actor can create a data-processing event, even indirectly. If it can query a customer record, write it to another store, enrich it, export it, or expose it through a downstream system, then it affects the evidence chain for access, retention, and incident response. A clear identity inventory helps here, and NHIMG’s Human vs Non-Human Identity explains why those ownership and lifecycle differences matter in practice.

That inventory should not stop at named users. It should extend to integrations, automation, shared service accounts, and embedded machine access that can touch the same personal data repositories. Where those identities are hard to trace, privacy evidence becomes weak even if the underlying storage controls are strong.

Why the privacy risk is really an access and accountability problem

The core compliance issue is not the label on the account, it is the fact that the account can act without human review at the moment data is accessed. If a non-human identity is overprivileged, long lived, or poorly owned, it can bypass the kind of accountability privacy teams need for lawful processing, incident reconstruction, and internal assurance.

NHIMG’s Service Account Security Guide and NHI Ownership and Accountability Guide are useful because they map the exact failure pattern privacy teams worry about, orphaned or shared machine access with no clear owner. That is the same blind spot that creates gaps in access reviews, DPIA support, and breach investigation evidence.

Privacy teams also need to distinguish routine processing from excessive access. A workflow account that only moves tokenised fields is different from one that can export full records, and an AI assistant with read access is different again if it can summarise, copy, or disclose personal data outside the original system boundary. The compliance question is therefore one of authority, scope, and traceability, not just system presence.

How to operationalise this in a Law 25 program

The most reliable approach is to fold non-human identities into the same governance model used for data access, but with controls sized to their behaviour. Start with the systems that hold personal data, then identify every non-human identity that can reach them, classify what data it can touch, and document the business purpose for that access.

NHIMG’s Identity Data Privacy and Consent Guide supports this kind of mapping because privacy controls often depend on minimisation, retention discipline, and consent or delegated-access logic. For machine identities, that usually means tighter ownership, shorter credential lifetimes, and clearer evidence of why the access exists.

What to verify: Confirm that every identity with personal-data reach has an owner, a defined purpose, and a reviewable access path. If an account cannot be tied to a business function or cannot explain what data it may process, treat it as a compliance gap, not a minor inventory issue.

What to measure: Track the share of personal-data systems covered by a complete non-human identity inventory, the number of shared or ownerless accounts, and the percentage of machine access with time-bound or reviewable permissions. Those signals tell you whether privacy evidence is becoming operational rather than theoretical.

Practitioner takeaway: For Law 25, privacy teams should treat non-human identities as data-handling actors whenever they can reach personal data, because access accountability and incident readiness fail first at the machine layer, not the human layer.

Related resources from NHI Mgmt Group

• How should security teams govern non-human identities for compliance?
• How should security teams govern non-human identities for SOC 2 compliance?
• How should security teams govern non-human identities at scale?
• How should security teams govern non-human identities in Salesforce?