M0803: Data Loss Prevention
Data Loss Prevention (DLP) technologies can be used to help identify adversarial attempts to exfiltrate operational information, such as engineering plans, trade secrets, recipes, intellectual property, or process telemetry. DLP functionality may be built into other security products such as firewalls or standalone suites running on the network and host-based agents. DLP may be configured to prevent the transfer of information through corporate resources such as email, web, and physical media such as USB for host-based solutions.
Analyst context for executives and security teams
Data Loss Prevention is an ICS-relevant mitigation for reducing the chance that sensitive operational information leaves the organization through email, web channels, or removable media. Its business value is not just “blocking files”; it helps protect engineering plans, recipes, trade secrets, process telemetry, schedules, diagrams, and other operational artifacts that could affect competitive position, incident response, and future adversary planning if stolen.
Executive priority
Leaders should treat DLP as a control that supports operational resilience, intellectual property protection, and compliance evidence for IEC 62443 requirements referenced by ATT&CK. Priority questions include: which operational information is most sensitive, where it is stored, which corporate transfer paths can move it, and whether DLP policy decisions are reviewed with operations so controls do not disrupt legitimate production support.
Technical view
For SOC, IR, and detection engineering teams, validate whether DLP coverage exists across the data movement paths named in the ATT&CK description: email, web, network security controls such as firewalls with DLP functionality, host-based agents, and physical media such as USB where host-based controls are deployed. Use the related techniques as validation context: Theft of Operational Information and Data from Local System. DLP policy should be tested against operational documents and telemetry-like artifacts, while incident playbooks should define how alerts are triaged without assuming every policy match is malicious.
Likely telemetry
- DLP alerts and policy match logs
- Email transfer and attachment inspection logs
- Web upload or outbound transfer logs
- Firewall or network security product DLP events
- Host-based DLP agent events
Detection direction
- Confirm that DLP policies identify the specific operational information types named by ATT&CK, including engineering plans, trade secrets, recipes, intellectual property, process telemetry, schedules, rotational data, specifications, schematics, and control system layout diagrams.
- Validate coverage across permitted business channels, not only perimeter egress: email, web, network controls, endpoints, and removable media may each create different blind spots.
- Tune for operational false positives by coordinating with engineering and operations teams; legitimate support, maintenance, or reporting workflows may resemble data movement of sensitive artifacts.
- Use DLP events as investigative leads, not standalone proof of adversary behavior, because ATT&CK provides no official detection guidance for this mitigation object.
- Map DLP alert handling to related ICS techniques T0882 and T0893 so analysts can connect suspicious transfer attempts with earlier local collection or access to operational files.
Mitigation priorities
- Start by classifying high-value operational information and identifying where it resides and how it legitimately moves.
- Apply DLP controls to the corporate resources and transfer paths specified by ATT&CK: email, web, network security products where applicable, host-based agents, and USB or removable media controls where deployed.
- Define prevention versus alert-only actions based on operational criticality to avoid disrupting legitimate production or engineering workflows.
- Create escalation paths for DLP matches involving operational data so SOC and incident response teams can quickly determine whether the event is authorized, accidental, or suspicious.
- Maintain audit-ready evidence that DLP supports IEC 62443-3-3 SR 4.1 and IEC 62443-4-2 CR 4.1 labels referenced in the ATT&CK object.
Analyst notes and limits
This is a mitigation object, not a technique, and ATT&CK does not list platforms, tactics, or official detection content for it. The strongest relationship-driven context is that DLP mitigates Theft of Operational Information and Data from Local System in the ICS domain. Glexia teams should use this object to drive control validation, DLP telemetry review, and incident handling readiness around operational information loss.
The supplied ATT&CK fields do not specify platforms, product types beyond general DLP deployment models, detection logic, severity, implementation requirements, or evidence of active exploitation. Local architecture, data classification, operational workflows, and DLP product capabilities are required to determine actual coverage and risk reduction.
Data Loss Prevention
Data Loss Prevention (DLP) technologies can be used to help identify adversarial attempts to exfiltrate operational information, such as engineering plans, trade secrets, recipes, intellectual property, or process telemetry. DLP functionality may be built into other security products such as firewalls or standalone suites running on the network and host-based agents. DLP may be configured to prevent the transfer of information through corporate resources such as email, web, and physical media such as USB for host-based solutions.
How security teams should use this page
Treat this object as behavior context, not an attribution claim. Validate the related groups, software, data sources, and mitigations against official ATT&CK relationships and your own telemetry before making control-coverage decisions.
Techniques used
This mirrors the MITRE pattern of making group, software, campaign, and technique relationships scannable. Relationship notes come from mirrored ATT&CK relationship text when available.
| Domain | ID | Name | Relationship / procedure |
|---|---|---|---|
| ICS | T0893 | Data from Local System | Data loss prevention can restrict access to sensitive data and detect sensitive data that is unencrypted. |
| ICS | T0882 | Theft of Operational Information | Apply DLP to protect the confidentiality of information related to operational processes, facility locations, device configurations, programs, or databases that may have information that can be used to infer organizational trade-secrets, recipes, and other intellectual property (IP). |
All related ATT&CK context
Object version and sync metadata
The fields below describe the current mirrored snapshot. When Glexia retains multiple ATT&CK source imports, you can open the table to compare the same object across releases (hashes and MITRE timestamps). For MITRE’s own release notes and roadmap, see ATT&CK resources — Updates .
Imported snapshots across ATT&CK releases (1)
| Release | Bundle imported | Object version | Modified | Status | Raw hash |
|---|---|---|---|---|---|
| 19.1 | 1.0 | Current bundle | b792bff4ac4b… |
Mirrored ATT&CK source object
The raw object is retained through the mirrored ATT&CK source bundle and object hash. The raw endpoint returns the exact object from the mirrored bundle when available.
External references and citations
MITRE external references are preserved separately from Glexia analysis so citations remain traceable to their original source records.
-
[1]
mitre-attack M0803Open source URL
Source: MITRE ATT&CK®. © 2026 The MITRE Corporation. This work is reproduced and distributed with the permission of The MITRE Corporation. MITRE ATT&CK and ATT&CK are registered trademarks of The MITRE Corporation. Glexia is not affiliated with or endorsed by MITRE.