Most data breaches do not need to defeat encryption: they reach data that too many identities could already read, in places nobody was watching. In ENISA's Threat Landscape 2025, covering July 2024 to June 2025, 68.6% of recorded intrusions led to data breaches offered for sale on criminal forums, and data exfiltration accounted for 30.2% of intrusions. This top 10 data security risks list ranks the biggest data security risks by our judgement of likelihood and impact, mixing external data security threats with internal failures, with the data exposure path each one opens, an incident where one fits, and the first fix. It is for data protection leads, security architects and the owners of data platforms. It goes deeper than the Data Security Guide, which sets out the full programme.
The Top 10 at a glance
- Weak data access governance and over-permissioned identities
- Stolen credentials on data platforms
- Cloud data exposure: public storage, open databases and shareable links
- Shadow data drift and uncontrolled copies
- Third-party data exposure
- Data theft through exploited applications
- AI data exposure
- Insider misuse
- Weak encryption and key custody
- Accidental disclosure by people
| # | Risk | Data exposure path (ATT&CK v20 where relevant) | First fix |
|---|---|---|---|
| 1 | Over-permissioned access | Any valid identity reads far more than its job needs (T1078, T1213) | Remove organisation-wide and unused access to restricted data |
| 2 | Stolen credentials | Infostealer or phished credentials used against warehouses and SaaS (T1078, T1213.006) | Phishing-resistant MFA or key-pair authentication; network policies |
| 3 | Cloud data exposure | Public buckets, open databases, anonymous links (T1530) | Block public access at organisation level |
| 4 | Shadow data drift | Exports, test copies and snapshots outside governance (T1530, T1213) | Discovery across all stores; retention on copies |
| 5 | Third-party exposure | Supplier or integration with access to your data (T1199) | Inventory data shared and integrations; scope and expire them |
| 6 | Exploited applications | Mass exploitation of an internet-facing app holding data (T1190, T1048) | Emergency patching; short retention on exposed systems |
| 7 | AI data exposure | Assistants, retrieval and training data surface what identities can read | Fix oversharing before rollout; permission-aware retrieval |
| 8 | Insider misuse | Authorised users copy data out (T1078, T1567.002) | Least privilege on bulk data; monitor volume and destinations |
| 9 | Weak encryption and keys | Keys stored with or near the data they protect | Separate key custody; encrypt backups and copies |
| 10 | Accidental disclosure | Misdirected email, wrong attachment, overshared file | Labels, recipient checks and DLP on outbound channels |
1. Weak data access governance and over-permissioned identities
The risk: sensitive stores readable by "everyone in the organisation" groups, analyst roles with read on whole production schemas, and pipeline, BI and backup service accounts with standing read-all access that no access review covers (T1078 Valid Accounts, T1213 Data from Information Repositories).
Why it matters: over-permissioning sets the size of every other incident. When any identity is compromised, the data exposure surface is whatever that identity can read, not what it normally uses. NCSC calls bulk personal data stores "very tempting targets for attackers of all kinds" and structures its assessment around what you hold, who has access and how the system is run.
The fix: name an owner for every sensitive store, remove organisation-wide permissions on restricted data, cut identities that have not used their access in 90 days, and include non-human identities in data access reviews. Combine data discovery with identity data so a finding says who and what can reach restricted data. See the Access Reviews Guide and the Service Account Security Guide.
2. Stolen credentials on data platforms
The risk: passwords for warehouses, databases and SaaS tenants harvested by infostealers or phishing and used directly, because the platform accepts a password alone or from any network (T1078, T1213.006 Databases).
Why it matters: ENISA puts phishing at about 60% of observed initial intrusion vectors. In the Snowflake breach, infostealer credentials without MFA unlocked 165 customer data warehouses, with no flaw in the platform itself.
The fix: phishing-resistant MFA for people, key-pair or federated authentication for services, network policies that restrict where each account can connect from, and alerts on sign-ins from new locations to data platforms. Retire local accounts that bypass the identity provider. See the Phishing-Resistant MFA Guide.
3. Cloud data exposure: public storage, open databases and shareable links
The risk: buckets and blob containers readable by anyone, databases listening on the internet without authentication, public snapshots, and signed URLs or shared access tokens with broad scope and long expiry (T1530 Data from Cloud Storage).
Why it matters: cloud data exposure needs no exploit, only discovery. The Microsoft SAS token exposure showed one over-permissive link exposing 38TB of internal data, and the DeepSeek database exposure showed an open ClickHouse database leaking chat logs and API secrets.
The fix: block public access at the organisation or tenant level with a recorded exception process, disallow anonymous and account-key access to storage where the platform allows, keep databases on private networks, and limit shareable links to short expiries. Scan continuously for exposure. See the Cloud Misconfiguration Guide and the Database Security Guide.
4. Shadow data drift and uncontrolled copies
The risk: shadow data drift is the steady growth of sensitive data outside governed stores: CSV exports in personal drives, production copies in test and analytics accounts, pipeline staging buckets, old snapshots and abandoned projects (T1530, T1213). Each copy keeps the sensitivity of the original and loses its controls.
Why it matters: you cannot protect, monitor or delete data you have not found, and over-retained copies enlarge every breach. Discovery tools that sample may label a store clean when it was simply not scanned deeply.
The fix: run discovery across cloud, SaaS, file servers and backups on a schedule, mask or tokenise personal data before it reaches non-production, set retention per data class including exports and snapshots, and require an owner and end date for every copy. See the Data Classification Guide and the DSPM Buyer's Guide.
5. Third-party data exposure
The risk: suppliers, processors and SaaS integrations that hold copies of your data or standing tokens into your tenants, often granted years ago and never reviewed (T1199 Trusted Relationship).
Why it matters: ENISA reports criminals increasingly targeting third-party providers to make attacks more efficient, and supply chain threats at 10.6% of its threat categories. In the Klue OAuth breach, a forgotten integration credential exposed customers' Salesforce data. Under UK GDPR you "must choose a data processor that provides sufficient guarantees about its security measures", in the ICO's words.
The fix: keep an inventory of what data each supplier holds and which integrations can reach your tenants, scope OAuth grants and API keys to the minimum, set expiry on shares, require deletion at contract end and review integrations at least annually. See the Third-Party Risk Management Guide and the SaaS and OAuth App Governance Guide.
6. Data theft through exploited applications
The risk: internet-facing applications that store or process bulk data (file transfer platforms, ERP, customer portals) exploited at scale, with data taken for extortion rather than encrypted (T1190 Exploit Public-Facing Application, T1048 Exfiltration Over Alternative Protocol).
Why it matters: ENISA records vulnerability exploitation in 21.3% of initial intrusions, and only 2.8% of the data breaches it saw offered for sale were described as a direct result of ransomware: theft without encryption is now the common outcome. In the Oracle E-Business Suite exploitation, Cl0p used a zero-day and stolen mailboxes to extort customers.
The fix: an emergency patch track for internet-facing systems that hold sensitive data, minimal exposure of admin and web tiers, and short retention on those systems so a future exploit finds little. Monitor outbound volume from them. See the Zero-Day and Exploited Vulnerabilities Guide.
7. AI data exposure
The risk: enterprise assistants and retrieval systems that answer from everything the requesting identity can read, training and fine-tuning datasets containing personal data or secrets, and staff pasting sensitive data into unsanctioned AI tools.
Why it matters: AI turns latent oversharing into findable oversharing. OWASP's LLM02:2025 Sensitive Information Disclosure warns that restrictions in system prompts can be bypassed through prompt injection, so they should not be the only control. The EchoLeak vulnerability showed how a prompt injection could make an assistant leak company data it could read.
The fix: remediate organisation-wide permissions before enabling assistants, enforce the caller's entitlements at retrieval, sanitise and record provenance for training data, and apply DLP to AI prompts and uploads. See the Permission-Aware RAG Guide and the Generative AI Data Loss Prevention Guide.
8. Insider misuse
The risk: employees and contractors with legitimate access who copy, sell or leak data, whether bribed, leaving for a competitor or acting carelessly (T1078, T1567.002 Exfiltration to Cloud Storage).
Why it matters: insider access looks normal to most controls. In the Coinbase insider breach, bribed support agents exposed 69,461 customers through access their roles already had.
The fix: limit bulk export and search rights to roles that need them, log and baseline data access per identity, alert on volume spikes and uploads to personal cloud storage, and tie access removal to leaver dates. See the Insider Threat Programme Guide.
9. Weak encryption and key custody
The risk: data encrypted with keys stored alongside it, unencrypted backups and exports, keys readable by the same administrators and services that read the data, and outdated algorithms.
Why it matters: encryption only helps if the attacker cannot also get the key. In the GoTo breach, stolen encrypted backups were exposed together with their encryption key. The ICO names pseudonymisation and encryption as examples of Article 32 measures, and NIST CSF 2.0 PR.DS-11 requires backups to be "created, protected, maintained, and tested".
The fix: keep keys in a key management service or HSM with administrators separate from data administrators, encrypt backups, exports and snapshots, alert on key policy changes and decryption by unusual principals, and plan algorithm upgrades. See the Cryptographic Key Management Guide and the Backup Security and Immutable Backup Guide.
10. Accidental disclosure by people
The risk: email sent to the wrong recipient, the wrong attachment, a spreadsheet with hidden personal data, a document shared with "anyone with the link", or paperwork lost in transit.
Why it matters: these incidents need no attacker, and they still count as personal data breaches under UK and EU GDPR when they affect personal data. Article 32 asks for "organisational measures" as well as technical ones, which the ICO links to clear accountability, policy and staff training.
The fix: sensitivity labels that drive warnings and encryption, recipient checks and delayed send for external email, DLP on outbound mail and sharing, sharing defaults set to specific people, and short, role-specific training. See the Data Loss Prevention (DLP) Guide and the Email Security Guide.
Mapping to OWASP
OWASP has no data security Top 10, so this list maps partly. The OWASP Top 10:2025 covers application weaknesses that lead to data exposure, and the OWASP Top 10 for LLM Applications covers AI data exposure. Regulators and standards are the better anchor for most of these risks, so the table includes NIST CSF 2.0 and SP 800-53 Rev. 5.
| Risk | OWASP Top 10:2025 | OWASP LLM 2025 | NIST CSF 2.0 | NIST SP 800-53 |
|---|---|---|---|---|
| 1. Over-permissioned access | A01 Broken Access Control | No direct fit | PR.AA-05 | AC-2, AC-6 |
| 2. Stolen credentials | A07 Authentication Failures | No direct fit | PR.AA-03 | IA-2, IA-5 |
| 3. Cloud data exposure | A02 Security Misconfiguration | No direct fit | PR.PS-01, PR.DS-01 | AC-3, CM-6 |
| 4. Shadow data drift | A02 (weak fit) | No direct fit | ID.AM-07 | CM-8, SI-12 |
| 5. Third-party exposure | A03 Software Supply Chain Failures (weak fit) | No direct fit | GV.SC-07 | SA-9, SR-6 |
| 6. Exploited applications | A05 Injection; A06 Insecure Design | No direct fit | PR.PS-02, ID.RA-01 | SI-2, RA-5 |
| 7. AI data exposure | A01 (weak fit) | LLM02:2025 Sensitive Information Disclosure | PR.AA-05, PR.DS-10 | AC-3, AC-21 |
| 8. Insider misuse | A09 Security Logging and Alerting Failures (weak fit) | No direct fit | DE.CM-03 | AC-6, AU-6 |
| 9. Weak encryption and keys | A04 Cryptographic Failures | No direct fit | PR.DS-01, PR.DS-02, PR.DS-11 | SC-12, SC-28, CP-9 |
| 10. Accidental disclosure | No direct fit | No direct fit | PR.AT-01 | AT-2, AC-21 |
For personal data, UK and EU GDPR Article 32 sits over every row: measures "appropriate to the risk", taking account of the state of the art and costs, with a process for regularly testing them. ISO/IEC 27001:2022 Annex A controls A.5.12 (classification), A.5.15 (access control), A.8.11 (data masking), A.8.12 (data leakage prevention) and A.8.24 (use of cryptography) cover the same ground.
Where to start
The top data security risks share a root cause: data reachable by more identities and places than anyone intended. Most common data security risks shrink when that data exposure risk shrinks. If you can do only three things this quarter: close public and organisation-wide exposure on restricted data (risks 1 and 3), enforce phishing-resistant MFA or key-based authentication on every data platform account (risk 2), and inventory which suppliers and integrations hold or can reach your sensitive data (risk 5). Then turn on data access logging for restricted stores so risks 6 and 8 can be detected at all. Track five numbers monthly: restricted stores that are public or shared organisation-wide (target zero), data platform accounts without MFA or key-based authentication (target zero), identities with unused access to restricted data for 90 days, sensitive data copies past their retention date, and restricted stores without data access logging feeding the SIEM.
Standards and references
- ENISA: Threat Landscape 2025
- NIST CSF 2.0 (csf.tools rendering): PR.DS Data Security
- NIST: SP 800-53 Rev. 5, Security and Privacy Controls for Information Systems and Organizations
- ICO: A guide to data security
- NCSC: Protecting bulk personal data
- OWASP: Top 10:2025
- OWASP: LLM02:2025 Sensitive Information Disclosure
- MITRE ATT&CK: T1213 Data from Information Repositories
Related NHI Mgmt Group resources: Data Security Guide · Data Classification Guide · Data Loss Prevention (DLP) Guide · DSPM Buyer's Guide · Data Exfiltration Guide