Who is accountable when discovery features expose personal data at scale?

Why This Matters for Security Teams

Discovery features are often treated as a product convenience, but when they can enumerate people, accounts, profiles, or linked records at scale, they become a security and privacy exposure surface. The core issue is not just access control. It is whether the feature can be abused to extract sensitive data faster than teams can detect, rate-limit, or revoke access. That makes accountability a design question, not only an operational one.

In practice, teams often discover the problem only after a crawler, script, or partner workflow has already queried far more data than intended. The lesson from Ultimate Guide to NHIs — Key Challenges and Risks is that enumeration risk sits alongside privilege and lifecycle risk, while NIST SP 800-53 Rev. 5 Security and Privacy Controls makes clear that privacy and security controls should be designed together, not bolted on after launch.

NHIMG research shows only 5.7% of organisations have full visibility into their service accounts, which matters because invisible non-human actors are the ones most likely to automate discovery abuse at scale. In practice, many security teams encounter this only after personal data has already been enumerated, rather than through intentional abuse testing.

How It Works in Practice

Accountability should follow the control plane behind the discovery function, not just the business team that requested the feature. Product security usually owns abuse-resistance, platform engineering owns the implementation and telemetry, and privacy owns the data-handling rules, disclosure thresholds, and lawful basis review. The practical mistake is assigning one owner for the feature but no owner for enumeration risk.

Current guidance suggests breaking the feature into measurable controls: who can query, what fields are returned, how much can be retrieved per request, and what patterns trigger review. Discovery endpoints should be protected with least privilege, purpose limitation, rate limits, pagination caps, and anomaly detection. For non-human identities, that also means binding access to workload identity and short-lived credentials rather than long-lived secrets, because static credentials make automated scraping much easier to sustain.

Operationally, security teams should define:

• the system owner for the discovery surface itself
• the data owner for the records being exposed
• the privacy reviewer for consent, notice, and retention concerns
• the detection owner for logging, alerting, and abuse investigations

That mapping matters because the feature may be technically correct while still creating a privacy incident through scale. The most relevant failure mode is a highly discoverable interface backed by overprivileged service accounts, especially when secrets are reused across environments or never rotated. The 52 NHI Breaches Analysis shows how non-human access paths repeatedly become the amplification layer for broader exposure, while the GDPR adds obligations around minimisation and purpose limitation that are easy to violate when discovery is too broad. These controls tend to break down in partner-integrated SaaS environments because external callers, shared tenants, and inconsistent logging make enumeration hard to distinguish from normal use.

Common Variations and Edge Cases

Tighter discovery controls often increase friction for legitimate users, requiring organisations to balance search utility against data minimisation and incident exposure. That tradeoff becomes sharper when the feature supports support teams, fraud teams, marketplace partners, or internal search across customer records. There is no universal standard for this yet, but current guidance suggests classifying discovery by blast radius: internal-only, tenant-scoped, partner-scoped, or public.

Edge cases matter. A feature may be low risk for one role and high risk for another if it returns different fields, searchable joins, or exportable results. Discovery also becomes harder to govern when autonomous agents or scripts invoke it indirectly through APIs, because the caller may be a service account rather than a named employee. In that environment, the right question is not just who approved the feature, but who approved the data shape, the query volume, and the machine identity that can exercise it.

If personal data is exposed through discovery at scale, accountability should be assigned before launch and revisited after any schema change, permission expansion, or integration rollout. That is the practical line between a useful search capability and an abuse path that scales silently.

Related resources from NHI Mgmt Group

• Who is accountable when a sensitive user exposes movement data through a personal app?
• Who is accountable when AI-assisted discovery exposes a high-risk legacy system?
• What breaks when contractors can copy regulated identity data to personal devices?
• Why do Social Security and similar identity records require stricter handling than ordinary personal data?