Data Loss Prevention | The Garnet Wiki

Data Loss Prevention (DLP) is a security discipline focused on detecting and preventing unauthorized exfiltration, leakage, or deletion of sensitive data across systems, networks, and endpoints. It matters when data is at risk—during transfer, in motion, in use, or at rest—and when a single breach can expose customer PII, financial records, intellectual property, or compliance-regulated information. DLP systems monitor, classify, and protect data across email, file shares, cloud storage, databases, and applications, acting as the last line of defense against insider threats, ransomware, and targeted attacks.

Detecting Sensitive Data

The foundation of DLP is identifying what constitutes sensitive data. This begins with pattern matching and content analysis using predefined and custom rules. The system scans data for known formats, values, or linguistic patterns.

A typical rule scans for U.S. Social Security numbers (SSNs) using the pattern ^\d{3}-\d{2}-\d{4}$, and classifies any match as “PII – SSN”. The system applies rules across file contents, database columns, email bodies, and API request payloads.

To define such rules, a configuration schema is used. Rules are grouped into policies, each with a priority, a scope, and a set of triggers.

{
  "policies": [
    {
      "name": "Customer PII Protection",
      "priority": 10,
      "scope": {
        "sources": [
          "email",
          "file-share",
          "cloud-storage"
        ],
        "locations": [
          "s3://internal-data/",
          "drive://customers/"
        ],
        "fileTypes": [
          "pdf",
          "xlsx",
          "docx"
        ]
      },
      "rules": [
        {
          "name": "SSN Detection",
          "type": "regex",
          "pattern": "^\\d{3}-\\d{2}-\\d{4}$",
          "confidence": 0.9,
          "classification": "PII – SSN"
        },
        {
          "name": "Credit Card Number",
          "type": "luhn",
          "classification": "PII – Credit Card"
        },
        {
          "name": "Keyword Match",
          "type": "keywords",
          "keywords": [
            "confidential",
            "proprietary",
            "draft",
            "quarterly report"
          ],
          "minMatches": 2,
          "classification": "Internal Document"
        }
      ]
    }
  ]
}

The system evaluates data at ingestion, during scheduled scans, or on-demand. A file uploaded to s3://internal-data/2024/financials.xlsx triggers a scan, which returns a list of detected sensitive data items:

{
  "scanId": "scan-20240402-1234",
  "source": "s3://internal-data/2024/financials.xlsx",
  "detected": [
    {
      "type": "PII – SSN",
      "value": "123-45-6789",
      "context": "Employee ID: 12345, Name: Jane Doe",
      "location": "Sheet1!A5",
      "confidence": 0.98
    },
    {
      "type": "PII – Credit Card",
      "value": "4111111111111111",
      "context": "Payment details for vendor invoice #1002",
      "location": "Sheet2!B12",
      "confidence": 0.92
    }
  ]
}

Common Pitfalls in Detection

Regex patterns are not applied uniformly: A rule may match 123-45-6789 but fail on 123456789 (no hyphens), even though the pattern ^\d{3}-\d{2}-\d{4}$ includes hyphens. The solution is to add a preprocessing step that normalizes delimiters.
Case sensitivity in keyword matching: A rule for “confidential” misses “Confidential” and “CONFIDENTIAL” unless explicitly configured. Most systems default to case-sensitive matching, but this is often overlooked.
Performance degradation: Scanning large files (e.g., 100MB Excel files) on upload can delay processing by seconds. The system may miss real-time detection unless it uses asynchronous scanning with event queues.

Classifying and Tagging Data

Once detected, sensitive data is classified and tagged. Classification is not just labeling—it involves enriching data with metadata that influences downstream actions.

The system assigns a classification field to each data element, and optionally attaches labels, categories, and risk scores.

{
  "data": {
    "id": "doc-789",
    "source": "email",
    "timestamp": "2024-04-02T10:30:00Z",
    "content": "Please find attached the Q1 financials. The data is confidential. SSN: 123-45-6789.",
    "classification": [
      "PII – SSN",
      "PII – Credit Card",
      "Internal Document"
    ],
    "labels": [
      "high-impact",
      "regulatory",
      "quarterly-report"
    ],
    "riskScore": 8.7,
    "metadata": {
      "sourceSystem": "Outlook",
      "owner": "[email protected]",
      "created": "2024-04-01T09:00:00Z"
    }
  }
}

Classification rules can be hierarchical. A document with both a credit card number and an SSN is classified as “PII – Credit Card” and “PII – SSN”, and the system may merge them into a single “PII” category.

Key Failure Modes

Overlapping classifications: A document contains both an SSN and a credit card number. The system classifies it as both, but the classification field is a flat list. Without merging logic, downstream systems may apply rules independently, leading to redundant actions.
Classification drift: A rule for “confidential” keywords fails to catch “Confidential” or “confidencial” (Spanish spelling). The system does not automatically handle diacritics or synonym matching unless explicitly configured.
Label propagation failure: When a file is moved from drive://marketing/ to drive://shared/, the classification and labels are not updated in the new location. The system must maintain a sync process or use event-driven updates.

Protecting Data with Policies

After classification, DLP policies determine how data is protected. Policies are evaluated in sequence and may trigger actions such as encryption, access restrictions, alerts, or automatic workflows.

A policy is defined by a set of conditions and actions. Conditions may be based on classification, location, user, time, or metadata.

{
  "policy": {
    "name": "Export to External Share",
    "conditions": [
      {
        "field": "classification",
        "operator": "contains",
        "value": "PII – SSN"
      },
      {
        "field": "source",
        "operator": "equals",
        "value": "cloud-storage"
      },
      {
        "field": "metadata.owner",
        "operator": "in",
        "value": [
          "[email protected]",
          "[email protected]"
        ]
      }
    ],
    "actions": [
      {
        "type": "encrypt",
        "algorithm": "aes-256-gcm",
        "keyId": "key-123",
        "scope": "file"
      },
      {
        "type": "add-tag",
        "tag": "external-share-ready"
      },
      {
        "type": "send-alert",
        "channel": "email",
        "template": "external-share-ready",
        "recipients": [
          "[email protected]",
          "[email protected]"
        ]
      },
      {
        "type": "apply-retention",
        "days": 365,
        "label": "long-term-retention"
      }
    ],
    "enforcement": {
      "mode": "enforce",
      "trigger": "on-upload",
      "delay": "30s"
    }
  }
}

When a file is uploaded to cloud-storage with an SSN and owned by Jane Doe, the system evaluates the policy and executes all actions in sequence.

Sharp Edges in Enforcement

Policy evaluation order matters: A policy with classification contains PII – SSN and another with classification contains PII – Credit Card both match a file, but if the first policy modifies the classification, the second may not detect the new value. The system must either evaluate policies in parallel or provide a “re-evaluate” step.
Asynchronous enforcement: When a policy is set to mode: enforce with trigger: on-upload, the system may enqueue the evaluation and apply actions later. During this delay, the file may be accessed, modified, or shared—leading to inconsistent states.
Action failure propagation: If the encrypt action fails (e.g., key not available), the system must either halt the policy or continue with a fallback. A common failure is missing the key-123 key, resulting in unencrypted files and silent policy misses.

Monitoring and Alerting

DLP systems generate logs and alerts to track data flow and policy effectiveness. Events are emitted on every classification, policy execution, and action completion.

A typical event log entry:

{
  "eventId": "event-20240402-001",
  "timestamp": "2024-04-02T10:31:15Z",
  "eventType": "policy-execution",
  "policy": "Export to External Share",
  "status": "success",
  "details": {
    "input": {
      "file": "s3://internal-data/2024/financials.xlsx",
      "classification": [
        "PII – SSN",
        "PII – Credit Card"
      ],
      "owner": "[email protected]"
    },
    "actions": [
      {
        "type": "encrypt",
        "status": "success",
        "output": {
          "encryptedFile": "s3://internal-data/2024/financials.xlsx.enc",
          "keyId": "key-123"
        }
      },
      {
        "type": "add-tag",
        "status": "success",
        "tag": "external-share-ready"
      },
      {
        "type": "send-alert",
        "status": "failed",
        "error": "SMTP connection timeout",
        "recipients": [
          "[email protected]",
          "[email protected]"
        ]
      }
    ]
  }
}

Alerts are sent via email, Slack, or webhook. A failure in the send-alert action triggers a secondary alert with details.

Common Alerting Failures

Alert deduplication failure: Two policy executions on the same file produce similar alerts. The system does not deduplicate them, leading to spam.
Alerting based on incomplete data: A policy runs on a file, but the classification is done before the file is fully uploaded. The system may miss a key field, causing the alert to be inaccurate.
Missing alert thresholds: An alert is sent when a policy fails, but no threshold is set for frequency. A spike in failed policy executions goes unnoticed until manually reviewed.

Integrating with Existing Systems

DLP is not a standalone system. It integrates with identity providers, file systems, databases, and application platforms.

Authentication integration: User identity is used to determine access rights. A file classified as “Confidential” requires authentication via SSO, and users must be part of the “Finance” group to access it.
Database integration: DLP scans database tables for sensitive data. A query on customers table returns a list of detected sensitive columns:

SELECT customer_id, name, email, ssn, credit_card, address
FROM customers
WHERE created_at >= '2024-01-01';

-- Output:
--   ssn: 123-45-6789 (PII – SSN)
--   credit_card: 4111111111111111 (PII – Credit Card)
--   address: 123 Main St, Anytown, CA 90210 (PII – Address)

File system integration: When a file is moved or copied, the DLP system updates its classification and applies policies. A file copied from drive://internal/ to drive://external/ triggers a policy for external sharing.

Integration Pitfalls

Delayed policy evaluation: A file is copied to an external share, but the DLP system scans only on upload. The policy is not evaluated until the next scan, leading to delayed protection.
Metadata inconsistency: A file is classified in one system (e.g., SharePoint), but the metadata is not synced to the DLP system. The DLP system may miss classifications or apply outdated policies.
Cross-system data propagation failure: A file is updated in a database, but the DLP system does not detect the change. The system must either poll for changes or subscribe to change feeds (e.g., via Kafka, RabbitMQ, or database triggers).

Summary: What You Must Know

DLP starts with detecting sensitive data using pattern matching and content analysis.
Classification is not just tagging—it involves metadata, labels, and risk scores.
Policies define how data is protected, with conditions and actions that can be chained and executed asynchronously.
Monitoring and alerting are essential for detecting failures and tracking policy effectiveness.
Integration with identity, file systems, and databases ensures that DLP is embedded in the data lifecycle.

The system fails silently when it does not propagate classification changes, when actions are not retried on failure, and when policies are evaluated with stale data. A DLP system is not just a scanner—it is a data protection engine.

This page was rewritten on 16 October 2026. It replaced a templated version that was not specific to its own title. How these pages are written and checked. If anything here is wrong, tell us at [email protected] and we will correct it.