Notifications
Clear all
Topic starter
12/07/2026 12:16 pm
TL;DR: Data leakage often happens through misconfigured systems, poor password hygiene, exposed APIs, or third-party paths rather than a clean break-in, and SecurityScorecard argues most organisations discover it only after the damage is already done. The governance problem is that leakage lives in the boundary between access control, data handling, and ecosystem oversight, where identity controls must be continuous rather than assumed.
NHIMG editorial — based on content published by SecurityScorecard: data leakage, identity gaps, and third-party exposure
By the numbers:
- Organizations share sensitive or critical information with an average of 583 third parties, creating an enormous attack surface.
Questions worth separating out
Q: What breaks when identity governance is separated from data security?
A: Governance becomes blind to whether an approved identity can actually reach sensitive records.
Q: Why do third-party and workload identities increase data leakage risk?
A: Third-party and workload identities often have broad, persistent access to the data needed for automation and collaboration.
Q: How do security teams know if exfiltration controls are actually working?
A: Look for evidence that bulk file access, compression, and outbound staging are detected early and correlated with privileged sessions.
Practitioner guidance
- Inventory all data-moving identities Build a register of service accounts, API keys, OAuth grants, and delegated vendor accounts that can read or export sensitive datasets.
- Remove standing access from data export paths Replace persistent permissions with task-scoped access for systems that move sensitive files, records, or logs.
- Correlate identity and data movement telemetry Join IAM, cloud audit, DLP, and SaaS logs so exfiltration attempts can be linked to the exact account or workload that initiated them.
What's in the full article
SecurityScorecard's full article covers the operational detail this post intentionally leaves for the source:
- Examples of how leakage occurs through email, cloud storage, and compromised applications in day-to-day environments.
- The role of dark web monitoring in detecting leaked credentials and exposed data after the fact.
- Operational guidance on data classification, DLP, endpoint controls, and security awareness programmes.
- How third-party risk management and vendor monitoring change the leakage boundary for organisations.
👉 Read SecurityScorecard's analysis of data leakage, controls, and third-party risk →
Data leakage and the governance gap teams are missing?
Explore further
12/07/2026 12:30 pm
Data leakage is now an identity governance problem as much as a data security problem. Organisations rarely lose control of sensitive information because a single control failed in isolation. More often, broad access, weak oversight, and untracked integrations create the conditions for silent export. For IAM and PAM teams, the practical conclusion is that leakage prevention starts with controlling who and what can move data, not only where the data sits.
A question worth separating out:
Q: Who is accountable when sensitive data leaves through a vendor, API, or misconfigured system?
A: Accountability usually sits with the business owner of the data, the identity or platform team that granted access, and the vendor manager if external trust was involved. Frameworks such as Zero Trust and least privilege make that shared responsibility harder to ignore because they require continuous verification of access, not one-time approval.
👉 Read our full editorial: Data leakage and identity control gaps are widening across ecosystems
