Catalog / Cybersecurity / SEC-017

Sensitive data discovery, classification & AI data-loss prevention (DSPM/DLP)

Find, classify and label personal, confidential and regulated data across file shares, SaaS, cloud stores and databases, fix overexposure, and block exfiltration including pastes and uploads into public GenAI tools.

Quick win: proven, manageable effort, first results within weeks, low regulatory risk.

Most organisations do not know where their personal, confidential and regulated data lives, who can reach it, or where it leaves. Data security posture management (DSPM) scans the whole estate with pattern, ML and LLM classifiers, labels what it finds, correlates labels with access rights, and feeds data-loss prevention (DLP) controls that stop exfiltration, including copy-and-paste or upload into public GenAI tools. The most common trigger in 2026 is a Copilot or RAG rollout that would surface every overshared file.

Problem & value

  • Today: data sprawls across file shares, collaboration suites, SaaS apps, data lakes and shadow databases. Classification relies on user-applied labels and regex-based DLP rules, which produce many false positives and miss unstructured content. Sharing links and inherited permissions leave files open to "everyone in the company" or to the internet.
  • AI value: ML and LLM classifiers recognise context (a contract, a medical letter, source code, a salary table) rather than just patterns such as IBANs; trainable classifiers adapt to organisation-specific document types; findings are ranked by exposure (sensitivity x who can access).
  • GenAI driver: assistants such as Microsoft 365 Copilot respect existing permissions, so overshared data becomes instantly searchable. Fixing permissions and labels before rollout is the main prerequisite vendors and regulators point to [1][2].
  • Compliance value: GDPR Art. 5(1)(f), 25 and 32 require appropriate security and data protection by design; a current inventory also underpins records of processing (SEC-018) and NIS2/DORA risk management.

Variants

  • Sensitive data discovery & classification (DSPM): agentless scanning of cloud stores, databases and SaaS; includes Google Cloud Sensitive Data Protection (formerly Cloud DLP) for BigQuery, Cloud Storage and Cloud SQL profiling as a Path B building block [4].
  • AI data-loss prevention: endpoint, browser and network DLP that inspects prompts, pastes and file uploads to GenAI apps, plus DSPM-for-AI views of who uses which AI app with which data [1][3].
  • Oversharing remediation before Copilot/RAG: access-risk reports, label-based restrictions, automated link removal (see SEC-020 for access reviews).

How it works

  1. connectors (M365, Google Workspace, S3/Azure/GCS, DBs, SaaS, endpoints, browser/proxy)
  2. crawl & sample content (OCR for scans and images)
  3. classify (regex/checksum validators
  4. ML/NER
  5. trainable or LLM classifiers
  6. labels)
  7. enrich (data owner, location, region, lineage, retention)
  8. access-risk correlation (who/what can read it; public links; stale permissions)
  9. prioritised findings
  10. remediation (relabel, restrict, delete, move, encrypt)
  11. DLP enforcement (endpoint / browser / network / API: allow, warn, justify, block)
  12. audit log, SIEM export, reporting
  • Classification: layered. Deterministic detectors with checksum validation (IBAN, national IDs, card numbers) stay the precision backbone; ML/NER models and trainable classifiers handle context; LLMs are used for ambiguous documents, label suggestions and natural-language policy authoring. Cheap detectors run first, LLM calls only on a residual sample to control cost.
  • Access correlation: a graph of identities, groups, sharing links and data locations turns "10 million files with personal data" into "412 files readable by all staff".
  • GenAI DLP: inspection at the browser, endpoint or secure web gateway of prompts and uploads; policies differ per app (sanctioned enterprise tenant vs. public consumer app). Relates to SEC-013.
  • Human-in-the-loop: data owners confirm classifications and approve bulk remediation; DLP policies start in audit/simulation mode; an exception and justification workflow handles legitimate cases.

Data preparation

Typical sources are file shares, SharePoint/OneDrive, mail, ERP and DMS exports, cloud buckets and databases. The scanner itself needs little preparation, but its results depend on the groundwork: unknown data owners, inherited or "everyone" permissions, duplicate and abandoned (redundant, obsolete, trivial) files, scanned PDFs without text, and no agreed classification scheme. Scattered ownership is the biggest gap, because findings without an owner are never remediated.

Preparation steps: 1. Inventory the data stores and name an owner per store (PREP-001, PREP-004). 2. Define the classification scheme and the rule "what may go into which AI tool" before scanning (PREP-019, PREP-024). 3. Clean up oversharing and stale permissions in a first pass (PREP-023); remove obvious duplicates and dead data (PREP-009). 4. Run OCR on scanned archives so content can be classified (PREP-006, DOC-018). 5. Start with a pilot scope (one file share, one SaaS) and tune the detectors on real samples (PREP-018).

Tools: built-in discovery of Purview or comparable DSPM products, Paperless-ngx for OCR of paper archives, scripts for ACL exports. Roughly 30-40 percent of total effort goes into inventory, owners and clean-up; see also DATA-007 and GUIDE-003.

Implementation paths

Which path for whom

  • SMB — Path A: mature DSPM/DLP products (e.g. Microsoft Purview, EU-hosted vendors) exist at SMB prices and the process is standard.
  • Enterprise — Path A: classification and DLP are commodity security functions; integrated products cover the many connectors better than a build.
  • Public sector — Path A: only with a certified (e.g. BSI C5) EU-hosted product; otherwise B on a sovereign cloud because of procurement and sovereignty rules.
  • Developer — Path B: cloud classification APIs plus own scanners fit teams that secure their own data pipelines and buckets.
  • Suite-native: Microsoft Purview (Information Protection, DLP, DSPM for AI, trainable classifiers, Data Security Investigations), Google Workspace DLP with Sensitive Data Protection. Best for SMBs already on M365 or Google Workspace; check the licence tier required for auto-labelling and endpoint DLP [1][2].
  • DSPM specialists: Varonis, Cyera, Sentra (Israel-based, EU regions), Wiz DSPM, Palo Alto Prisma Cloud DSPM, Microsoft Defender for Cloud DSPM, BigID, Securiti, Normalyze-class tools. Data-residency options vary; verify EU processing.
  • GenAI-aware DLP / SSE: Netskope, Zscaler, Palo Alto, Forcepoint, Proofpoint, Symantec (Broadcom), Island enterprise browser, plus startups for prompt-level inspection.
  • EU vendors: few at full scale; consider DRACOON-style EU secure file sharing with built-in classification, Stormshield / Atos / Thales offerings for sovereign requirements, and check EU-hosted options of BigID or Securiti. Verify claims individually.
  • Choose A when: more than a few TB of mixed data, regulated sector, or a Copilot rollout is imminent.

Path B — Build on cloud APIs

  • Detection services: Google Cloud Sensitive Data Protection (inspection, de-identification, discovery profiles for BigQuery/Storage/Cloud SQL) [4]; Azure AI Language PII detection; Amazon Macie for S3 [5]; Microsoft Presidio-style analysers on top.
  • LLM classification: frontier or EU-hosted models (Mistral, Claude/Gemini/GPT via EU regions) with structured outputs to label ambiguous documents; use for sampling, not full-estate scans.
  • Integration: event-driven scanning on object create (S3 events, Pub/Sub), labels written back as tags/metadata, findings to SIEM and ticketing; n8n or Power Automate for owner approvals.
  • Choose B when: you run a cloud-native data platform and want custom policies.

Path C — Self-host (open source)

  • Detection: Microsoft Presidio (analyser/anonymiser), GLiNER / GLiNER-PII and other small NER models, Hugging Face PII token classifiers, DataFog, scrubadub, regex libraries with validators; Apache Tika / Docling / PaddleOCR for text extraction.
  • Open-weight LLMs (Qwen, Llama, Mistral, gpt-oss families) via vLLM/Ollama for residual classification; embeddings plus OpenSearch for similarity to labelled exemplars.
  • Hardware: HW1 (CPU) for pattern and small-NER scans; HW2 only if running an LLM classifier. Operational effort is high: connectors, rate limits and permission modelling are the hard part.

Path D — Custom training

Worthwhile for organisation-specific document classes (e.g. trade secrets, patient files, source code) where trainable classifiers need a few hundred labelled examples per class. Fine-tune a small encoder (BERT-class) or use few-shot LLM labelling plus review. Labels from data-owner corrections are the natural training data.

State of the art (2026)

  • DSPM has converged with DLP and access governance: vendors position a single graph linking data, identities and AI apps; "DSPM for AI" shows prompts, responses and sensitive-data hits for Copilot and third-party AI apps [1][3].
  • LLM-assisted classification improves recall on unstructured text and supports natural-language policies, but cost, latency and non-determinism mean it is applied selectively; deterministic detectors remain the audit-friendly base.
  • Limits and failure modes: false positives on test data and synthetic numbers; missed data in images, encrypted archives and proprietary formats; label drift; sampling can miss rare records; encrypted or end-to-end protected traffic limits network DLP; users bypass controls with personal devices; LLM classifiers can themselves leak data if sent to unapproved endpoints; scanning is itself processing of personal data and needs a legal basis and minimisation.

Shared resources & combinations

  • Same stack (text-classifier + ocr-docparse + guardrails): DOC-018 redaction, DATA-007 catalogue enrichment, SEC-018 personal-data mapping and DSAR automation, SEC-010 guardrails (PII filters on prompts/outputs).
  • Combines with: SEC-020 (least-privilege fixes for overshared data), SEC-013 (shadow-AI discovery supplies the list of GenAI apps to police), SEC-009 and SEC-022 (evidence for ISO 27001, NIS2, DORA and AI governance), SEC-001 (DLP alerts into SOC triage).

Effort, cost & KPIs

  • Path A: weeks for a first scan and audit-mode policies; 3-6 months to move DLP to blocking. Cost drivers: per-user or per-TB licensing, and the data-owner time for remediation.
  • Path B: 2-4 months for pipelines on one cloud; API cost scales with scanned volume, so use sampling and tiered detectors.
  • Path C: 3-6 months; engineering-heavy, mostly connectors and permission data.
  • KPIs: share of estate scanned; share of sensitive data labelled; overexposed sensitive items (public links, "everyone" access) trend; mean time to remediate; DLP false-positive rate and override rate; blocked GenAI exfiltration attempts; stale/ROT data removed.

People & change

Start with management (policy, budget) and the information security officer, who usually owns the project. Involve the DPO from the start, because the scanner processes personal data across the estate; an Art. 35 GDPR DPIA is likely and an AVV (Art. 28 GDPR) is needed with every processor. IT and data owners must confirm scope and clean up permissions; department leads decide what is "confidential" in their area.

Works council: yes. DLP on endpoints, browsers and network traffic logs user behaviour and is objectively suited to monitor employees, which triggers co-determination under §87(1) no. 6 BetrVG (BAG: suitability suffices); §90(1) no. 3 requires early information, and §80(3) allows an AI expert. In the public sector the staff council (Personalrat) applies. A works agreement should limit use to data protection purposes and exclude performance monitoring.

AI literacy (Art. 4 AI Act): take measures to support staff understanding, here a short briefing on classification labels and why GenAI pastes are blocked. Communicate early what is logged, who sees alerts and that warn/justify modes are used first. Pilot with IT and one willing department in monitor-only mode. Typical concerns are surveillance and false positives; address them with transparency, a human review of every alert and an appeal path. Humans stay in control of blocking rules and labelling decisions. See GUIDE-004, GUIDE-005 and GUIDE-008.

Risks, regulation & compliance

  • EU AI Act: typically minimal risk; the classifier is a security control, not an Annex III use. Becomes sensitive if DLP/classification outputs are used to profile or discipline employees (employment context may then touch Annex III and works-council rights). AI literacy (Art. 4) applies. No Art. 5 prohibition is implicated unless content inspection is used for emotion inference at work, which must not be done.
  • GDPR: scanning and monitoring process personal data, including special categories (Art. 9); need a legal basis (often Art. 6(1)(f)), transparency, minimisation, DPIA for systematic employee monitoring, and a data processing agreement; prefer EU-region processing and avoid exporting raw content to the vendor (metadata-only or in-tenant scanning). Findings repositories hold sensitive pointers and need strict access control.
  • Employee monitoring: in Germany, works-council co-determination (BetrVG sec. 87(1) no. 6) applies to DLP and endpoint monitoring; document purpose limits and avoid performance surveillance.
  • Mitigations: audit-first rollout, tiered thresholds, owner confirmation before bulk actions, override logging with justification, regular precision/recall sampling, retention limits on findings.

Getting started

  1. Define 5-10 sensitivity classes and map each to a handling rule; involve the DPO and works council early.
  2. Run a discovery scan (audit mode only) on the two highest-risk repositories, e.g. SharePoint and one data lake.
  3. Rank findings by exposure; remove public links and "everyone" access for the top sensitive items.
  4. Pilot GenAI DLP in simulation mode for sanctioned and unsanctioned AI apps; review hits weekly.
  5. Gate any Copilot or RAG rollout on remediation KPIs, then move policies from warn to block.

Sources

  1. Microsoft Learn: Data Security Posture Management for AI in Microsoft Purview - https://learn.microsoft.com/purview/ai-microsoft-purview
  2. Microsoft Learn: Microsoft 365 Copilot data protection and oversharing blueprint - https://learn.microsoft.com/copilot/microsoft-365/microsoft-365-copilot-ai-security
  3. Microsoft Learn: Purview Data Loss Prevention overview - https://learn.microsoft.com/purview/dlp-learn-about-dlp
  4. Google Cloud: Sensitive Data Protection documentation - https://cloud.google.com/sensitive-data-protection/docs
  5. AWS: Amazon Macie user guide - https://docs.aws.amazon.com/macie/latest/user/what-is-macie.html
  6. Microsoft Presidio (open source PII detection) - https://github.com/microsoft/presidio
  7. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
  8. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
  9. Regulation (EU) 2022/2554 (DORA) - https://eur-lex.europa.eu/eli/reg/2022/2554/oj