One Monday morning, an IT administrator at a manufacturing company discovers that for the past three weeks, one of the sales department employees had been sending compressed CSV files to a private Gmail address. The files contained the full customer database with order history and commercial terms. The employee was not a malicious actor — they were just finishing up their tenure and preparing to leave for a competitor. The company had never formally classified that data. Nobody knew anything was happening until it was too late.
This is not a textbook scenario. Similar situations occur regularly — according to IBM’s Cost of a Data Breach Report 2024, the average cost of a data breach is $4.88 million globally, and in Europe a significant portion of breaches originate from inside the organization. Data Loss Prevention (DLP) is not just another security product to buy and forget. It is a strategic approach that combines data classification, policies, processes, and technologies into one coherent system. In this article, I describe how to build that strategy in practice — step by step.
What is DLP (Data Loss Prevention) and why is it becoming a necessity?
Data Loss Prevention is a set of technologies, policies, and processes designed to detect and prevent the unauthorized transfer, disclosure, or destruction of an organization’s sensitive data. It is not solely about blocking malicious attacks from outside — DLP protects data both from internal threats (intentional and accidental) and from external vectors that exfiltrate data through a compromised account.
The term “Data Loss Prevention” is sometimes confused with “Data Leak Prevention” — both are used interchangeably, but in implementation practice we distinguish between loss of data (loss — data becomes unavailable, e.g. through ransomware) and leakage of data (leak — data reaches unauthorized parties). DLP systems primarily address the second scenario, although many solutions combine both approaches.
Why is DLP becoming a necessity right now? Several phenomena are converging simultaneously. First, the work environment has become radically more distributed — data moves between corporate devices, personal laptops, the cloud, and SaaS services. Second, legal regulations — GDPR, the NIS2 directive, and sector-specific requirements such as PCI DSS or HIPAA — impose specific data protection obligations on organizations with very specific financial consequences for non-compliance. Third, the threat model is evolving: an increasing number of ransomware attacks combine file encryption with prior data exfiltration, which changes the risk calculus.
Key point: DLP is not a product you “buy and it just works.” It is a program — a combination of technology, policies, processes, and training that must be built iteratively and actively maintained.
In implementation practice, I encounter organizations that purchased licenses for advanced DLP solutions, and after 18 months still have them deployed in “monitor only” mode with no blocking policies in place. The reason? They did not first do the foundational work — data classification and defining what they actually want to protect.
📚 Read the complete guide: OT/ICS Security: Bezpieczeństwo systemów OT/ICS - różnice z IT, zagrożenia, praktyki
What data leak channels do attackers — and employees — most commonly exploit?
The answer to this question is critical for prioritizing the implementation. Data leak channels are divided into those associated with intent (deliberate leak) and those resulting from carelessness or human error. Both categories are equally dangerous and require a DLP response.
Among network channels, the most commonly exploited are: email (sending attachments to external mailboxes, both private Gmail/Outlook.com addresses and competitor inboxes), cloud file-sharing applications (OneDrive/SharePoint shared publicly, Google Drive, Dropbox, WeTransfer), instant messaging (Slack, Teams, WhatsApp — particularly private versions), and browser-based uploads to unauthorized services. A less obvious but very active channel is printing — documents taken out physically, scanned with a phone, or photographed.
Implementation statistic: In the DLP projects I have carried out, email and cloud services (SharePoint/OneDrive used outside policy) together account for over 70% of detected incidents during the monitoring phase. Printing and USB devices account for a further 20%.
USB drives and removable storage remain a classic yet still active vector. In organizations without a policy governing external devices, employees copy data onto USB drives for convenience — to work from home, to hand over a file at a meeting, or to create a “local backup.” The scale of these incidents is often surprising to management.
Data leak channels specific to technical environments include code repositories (GitHub, GitLab, Bitbucket — particularly public ones), remote access (RDP, SSH without appropriate controls), and APIs. Developers frequently commit files containing secrets, API keys, or test data with real customer records to public repositories. Tools such as GitGuardian or GitHub Advanced Security detect these cases — it is worth integrating them with DLP.
Finally, the analog channel should not be overlooked — photographing a screen with a smartphone, dictating data over the phone, drawing diagrams on paper. These scenarios are harder to detect technologically and require a procedural approach (policies, training, zone control).
It is also worth paying attention to a channel that tends to be ignored in classic DLP models: data sent to large language models (LLMs) and generative AI. Employees paste confidential content — customer emails, contract drafts, financial data — into tools such as ChatGPT or Microsoft Copilot, often without realizing that this data may be used for model training or stored by the provider. Modern DLP platforms (Netskope, Zscaler, Microsoft Purview) are beginning to address this category of channels with a dedicated policy — AI Egress Control. This is an area that will become a standard component of every DLP strategy within the next two years.
How to classify data in an organization — the foundation of effective DLP?
Data classification is step zero of any DLP strategy. Without it, policies cannot be defined — because it is not known what is sensitive and what is not. In implementation practice, classification is one of the most difficult stages, because it requires the involvement not just of IT, but of the entire business.
The standard classification model for a commercial organization operates on four levels: Public (data intended for publication, e.g. marketing materials), Internal (data available to employees, with no internal restrictions, but not for external disclosure), Confidential (data requiring restricted access, e.g. commercial documents, strategies, customer personal data), and Strictly Confidential (data of the highest sensitivity — trade secrets, financial data for auditing, sensitive data as defined under GDPR).
Step by step: Start with an inventory of data assets, not with policies. A list of systems (ERP, CRM, SharePoint, email, code repository, databases) and the types of data they process is the starting point. Then assign data owners — business stakeholders responsible for each category, not IT.
Classification methods in DLP tools fall into three categories. Content-based classification — the system analyzes the file’s contents and, based on rules (regular expressions, dictionaries, fingerprints), assigns a category. For example: a file containing a social security number pattern or credit card numbers is automatically marked as confidential. Context-based classification — takes into account metadata: who created the file, in which system, when, and which applications have opened it. Manual classification (user-driven) — the employee assigns a label themselves when creating a document; this model works in combination with Microsoft Purview Information Protection or Forcepoint.
In practice, the most effective approach is a hybrid one: automatic classification as a safety net, manual classification as the priority for documents intentionally created by employees. Automatic classification of existing assets is a project in itself — in an organization with 500 employees and several years of history in SharePoint, we are talking about hundreds of thousands of documents to be analyzed.
Do not overlook structured data (databases, tables in ERP, CRM records) — these are often the organization’s most valuable data, and their protection through DLP requires a different approach than files. This is where Database Activity Monitoring (DAM) mechanisms and SQL query controls combined with DLP policies at the data export level prove useful.
What DLP approaches exist — endpoint, network, cloud?
In implementation practice, we distinguish three main planes on which DLP is implemented. Each addresses different leak channels and requires different technologies. An effective DLP strategy covers all three — but not all organizations need to deploy them simultaneously and with the same depth.
Endpoint DLP is an agent installed on employees’ workstations and laptops. It monitors and controls operations at the operating system level: clipboard copying, saving to USB devices, printing, browser-based transfers (HTTPS upload), and file operations. Endpoint DLP is the most granular — it sees exactly what the user is doing with a file — but it is also the most intrusive and the hardest to manage at scale. It requires maintaining an agent on every device, which generates operational costs and potential conflicts with other security agents (EDR, antivirus).
An important practical point: Endpoint DLP works correctly only on devices managed by the organization. For employees using personal laptops (BYOD) or mobile devices, you need a different approach — Mobile Device Management (MDM) and conditional access policies.
Network DLP (also called inline DLP or Network Traffic Analysis with DLP elements) analyzes network traffic for sensitive data. Placed at the network perimeter (inline proxy, ICAP, integration with next-generation firewalls), it can block or log data transfers over network channels. It is less intrusive for the end user, but has limitations: it cannot see end-to-end encrypted traffic (e.g. WhatsApp Web), it does not work for users outside the corporate network (remote work without VPN), and it does not control local operations (USB, printing). In the era of ubiquitous HTTPS, effective Network DLP requires SSL inspection, which raises additional technical and legal challenges.
Cloud DLP (API-based DLP) connects directly to cloud services via their APIs and analyzes data stored in the cloud — Microsoft 365 (SharePoint, OneDrive, Exchange), Google Workspace, Salesforce, Box, Slack. The advantage is that there is no need to route traffic through a proxy — the “out-of-band” solution introduces no latency. Limitation: it only works with services that have mature APIs; not all SaaS applications are supported by all DLP vendors.
A fourth, complementary approach is CASB (Cloud Access Security Broker) — an intermediary layer between users and cloud services that can combine cloud traffic visibility with DLP policies. Many vendors (Microsoft Defender for Cloud Apps, Netskope, Zscaler) integrate CASB and DLP in a single product.
How to implement DLP without paralyzing employee productivity?
This is the question that comes up at every DLP meeting — and rightly so. Overly aggressive DLP policies are one of the main reasons implementations fail. Employees find workarounds (shadow IT), complain to management, and the project loses political support. Step by step, I will describe an approach that delivers results in practice without triggering a revolt.
First principle: start in monitoring mode (monitor only), not with blocking. For the first 2–4 months of the implementation, collect logs and analyze what is actually happening. This will allow you to calibrate policies — to understand what data transfers are a normal part of work (e.g. the marketing department regularly sends large graphic files via WeTransfer to an external agency) and what is genuinely suspicious. Blocking without this calibration phase causes an avalanche of helpdesk tickets and frustration.
In implementation practice, the rule is simple: DLP policies should reflect the actual working model of the organization, not the idealized model from a security document. If the standard sales process requires sending PDF proposals to clients by email, your DLP must allow for this — with control, but without blocking.
Second principle: communicate and train before deployment. Employees who understand why DLP is being implemented and what the system monitors are less inclined to seek workarounds. Internal communication should explain the purpose (protecting company and client data), the scope (what is monitored), and the consequences (the procedure in the event of an alert). Training need not be lengthy — a 20-minute e-learning module explaining the classification policy and prohibited transfer channels is sufficient.
Third principle: build exceptions and justification workflows before implementing blocking. Effective DLP must have a mechanism by which a user can justify a transfer that the system would flag as suspicious. For example: an employee attempts to send a file with customer data to an external auditor — the system asks for a justification, the employee enters “Q4 financial audit, approved by CFO,” and the transfer is logged with that context. This eliminates the majority of false alarms and teaches the system real working patterns.
Fourth principle: implement policies gradually, starting with the highest-classification data. First, protect strictly confidential data — trade secrets, financial data, cryptographic keys. Only when those policies are calibrated and tested should you extend coverage to confidential data. Attempting to bring all data categories under DLP policies all at once is a straightforward path to chaos.
How do NIS2 and GDPR affect data leak protection requirements?
The NIS2 Directive (implemented in Poland as an amendment to the National Cybersecurity System Act, entering into force in stages) and GDPR create a specific regulatory context for DLP implementations. These are not regulations that explicitly mandate the implementation of a DLP system — but they are ones that are very difficult to comply with in full without DLP.
GDPR imposes on data controllers the obligation to implement appropriate technical and organizational measures to ensure the security of personal data (Art. 32). It also requires reporting personal data breaches to the supervisory authority (in Poland: UODO) within 72 hours of becoming aware of them, and in the case of high risk to individuals — also notifying those individuals. A DLP system is a key element in this context: first, it helps prevent breaches; second, it provides the logs necessary to assess the scope of a breach and fulfil the notification obligation.
An important legal aspect: The implementation of a DLP system that monitors employee activity must be preceded by an appropriate procedure. In Poland, this requires consultation with the workplace trade union (if one exists) or prior notification to employees (Art. 22(3) of the Labour Code). Employees must be aware that their data transfer activity is being monitored.
NIS2 expands the circle of entities subject to obligations (essential and important entities across 18 sectors) and raises the requirements for risk management. Article 21 of the NIS2 Directive requires entities to implement cybersecurity risk management measures, including human resource security policies, access controls, and asset management. DLP directly fits into these requirements — it documents that the organization actively protects access to information and monitors data flows.
For sectorally regulated industries (finance — KNF, insurance, healthcare, defense industry), requirements may be even more specific. PCI DSS requires protection of payment card data and controls, which translates directly into DLP policies for environments processing card data. HIPAA (for entities operating in the US market) requires equivalent controls for PHI (Protected Health Information).
It is worth remembering that regulations represent the minimum level of requirements. In the event of an incident, supervisory authorities and courts assess not only whether you complied with the letter of the law, but whether you acted as an entity employing “appropriate” technical measures. DLP, properly implemented and actively managed, is a strong argument in that assessment.
What DLP tools work well in mid-sized organizations?
The DLP tools market is highly varied — from full-featured enterprise platforms (Microsoft Purview, Forcepoint, Symantec DLP) to solutions dedicated to SMEs (CoSoSys Endpoint Protector, Digital Guardian). In implementation practice, the key question is not “which tool is best,” but “which solution best fits the environment of this specific organization.”
For organizations with 100–500 users that use Microsoft 365 (SharePoint, Exchange, Teams, OneDrive), the natural starting point is Microsoft Purview Information Protection with DLP policies integrated directly into the Microsoft platform. The advantage is that the license is often already available as part of Microsoft 365 Business Premium or E3/E5. Built-in label-based classification (Sensitivity Labels) and DLP policies cover email, SharePoint, OneDrive, Teams, and Edge. The limitation is weaker endpoint control for non-Microsoft scenarios (e.g. transfers via other browsers, USB, printing) — here, Microsoft Purview DLP for endpoints requires integration with Microsoft Defender for Endpoint.
Practical tip: If your organization uses Microsoft 365 E3 or E5 and has no DLP yet, start with Microsoft Purview. You already have a paid license, the integration is native, and the learning curve for administrators familiar with the Microsoft environment is shallow.
Forcepoint DLP is a mature enterprise solution with strong content policies (content fingerprinting, exact data matching — EDM) and granular channel control. It supports mixed environments (not just Microsoft) and is particularly effective in organizations with extensive compliance requirements (finance, healthcare). Higher cost and implementation complexity make it a choice for organizations with 500+ users and a dedicated security team.
CoSoSys Endpoint Protector (now part of Netwrix) is a particularly interesting option for organizations with heterogeneous environments (Windows + macOS + Linux) and a priority on USB device control and endpoint-level DLP. Good Cloud/SaaS options for smaller organizations, with a lower barrier to entry than enterprise solutions.
Netskope and Zscaler are SASE (Secure Access Service Edge) platforms that combine CASB, SWG (Secure Web Gateway), and DLP in a single cloud solution. Ideal for organizations that have moved to a cloud-first model and have a distributed team — all internet transfers are analyzed without the need to maintain an on-premises proxy.
When selecting a tool, it is worth evaluating: integration with the existing stack (Microsoft vs. Google Workspace vs. mixed), capacity for EDM (exact data matching) for structured data, licensing model (per user/per device), reporting capabilities for compliance purposes, and the quality of technical support available locally.
How to detect and respond to data leak incidents?
Implementing DLP policies is one thing. Equally important is building a process that handles the alerts generated by the system. A DLP alert without a response process is useless noise — or, worse, a false sense of security.
The first step is classifying DLP alerts by priority. Not all alerts are equivalent. An alert about a document labeled “Confidential” being sent to an external email address by a department director is a different incident from a receptionist accidentally attaching a customer data scan to a message instead of an invoice. DLP systems should generate alerts with context: user, device, time, channel, content, file classification. On that basis, an analyst can quickly assess whether this is an incident requiring immediate response or a false positive.
Alert triage in a well-functioning DLP environment looks as follows: high-risk alerts (strictly confidential class data, external recipient, outside working hours) → immediate response, escalation to CISO/SOC; medium-risk alerts (confidential data, known internal recipient, working hours) → analyst verification within 4 hours; low-risk alerts (internal data, permitted channel, typical user pattern) → log, weekly review.
In implementation practice: DLP systems in the monitoring phase can generate thousands of alerts per day. This is normal and expected at the outset. The goal of triage and policy tuning is to reach a state where the SOC or security administrator has a few dozen alerts to handle per day — the majority of which are genuine events requiring attention.
Responding to data leak incidents should be described in the Incident Response Plan (IRP). DLP-specific elements include: the user isolation procedure (do we block the account immediately, or gather evidence first?), the log preservation procedure (DLP logs have evidentiary value — they must be secured against the possibility of modification), and the procedure for assessing the scope of the breach (did the data reach an external recipient? did the recipient open it? is there a basis for filing a GDPR breach notification?).
Integrating the DLP system with a SIEM (e.g. IBM QRadar, Microsoft Sentinel, Splunk) enables the correlation of DLP alerts with other security events — e.g. a login from a new country + a DLP alert about a large file transfer = high-priority incident. This correlation is impossible to achieve without integration between tools.
What does a DLP implementation roadmap look like?
The table below presents a typical DLP implementation roadmap for a mid-sized organization (200–500 users) spread across four phases. The duration of each phase depends on the complexity of the environment and the resources committed.
| Phase | Timeline | Activities | Tools / Methods | Success Criteria |
|---|---|---|---|---|
| Phase 1: Foundations | Weeks 1–6 | Data asset inventory; identification of systems processing sensitive data; definition of classification schema (4 levels); assignment of Data Owners for each category; legal analysis (GDPR, NIS2, sector-specific); baseline risk assessment | Data discovery tools (Microsoft Purview Scanner, Varonis DatAdvantage); process documentation; workshops with business units | Complete data asset map; assigned Data Owners; approved classification schema; risk assessment |
| Phase 2: Pilot and calibration | Weeks 7–14 | DLP deployment in monitor-only mode for a selected department (preferably one with high risk, e.g. sales or finance); configuration of basic content policies (card numbers, social security numbers, banking data); log analysis; identification of normal work patterns; policy tuning; reduction of false positives | Selected DLP tool (Microsoft Purview / Endpoint Protector / Forcepoint); SIEM for log aggregation; workshops with pilot users | False positive rate reduced below 30%; documented normal transfer patterns; accepted pilot policies |
| Phase 3: Rollout and blocking | Weeks 15–24 | Expansion of deployment to the entire organization (monitor-only); employee communication; data classification training; deployment of labels (Sensitivity Labels) in Microsoft 365 or equivalent; gradual activation of blocking policies for strictly confidential class data; building an exception management process; SIEM integration | DLP on endpoint + email + cloud; Microsoft Information Protection or equivalent; e-learning training platform; ticketing system for exceptions | Full organizational monitoring coverage; effective communication confirmed by survey; first blocking policies for “strictly confidential” class active |
| Phase 4: Maturity and optimization | Months 7–12+ | Activation of blocking policies for “confidential” class data; deployment of Exact Data Matching (EDM) for customer/employee databases; IR (Incident Response) integration; regular policy reviews (quarterly); compliance reporting for audits; building DLP effectiveness metrics; consideration of extending to structured data DLP (DAM) | EDM in DLP tool; regular policy effectiveness testing; compliance dashboards; DLP+SIEM+SOAR integration | Confirmed incident indicator < 20 per month; incident response time < 4h; readiness for GDPR/NIS2 audit |
The roadmap is a starting point, not a rigid schedule. Organizations in regulated sectors (finance, healthcare) may need to shorten the pilot phase and accelerate the rollout of blocking policies. Organizations with fewer IT resources may extend the timeline or deploy phases with the help of an external partner.
How does nFlo help organizations protect sensitive data?
At nFlo, we build DLP strategies from the ground up — from data classification and risk assessment, through tool selection and implementation, to integration with the existing security stack and operational processes. We work with organizations in the financial, industrial, healthcare, and public administration sectors — environments where effective data protection is not an option, but a regulatory and business requirement.
Our approach to DLP implementations is based on several principles. First, we start by understanding the client’s business model — what data it processes, what the circulation processes look like, and where the real risks lie. Without this, even the best DLP system generates more problems than it solves. Second, we operate iteratively — we do not try to implement full DLP in four weeks; we build a program that the organization is able to maintain and develop.
With over 500 projects delivered for 200+ clients and a 98% retention rate, we deliver not just technology — we deliver competencies and processes. Our incident response time is under 15 minutes, and the level of risk reduction for our clients reaches 90%. These are numbers backed by concrete implementations — including DLP implementations that genuinely work.
If your organization faces the challenge of protecting sensitive data — whether due to NIS2, GDPR, contractual requirements, or simply because you want to be certain that data stays where it should — we invite you to a conversation about how to build a DLP strategy tailored to your context.
A first step could be a free preliminary data leak risk assessment — an analysis of key transfer channels, the state of data classification, and gaps in policies. Based on that, we can jointly decide where to begin the implementation in order to achieve maximum effect with the available resources and time.
FAQ — frequently asked questions about DLP
Is DLP necessary in a small company (10–50 people)?
A full-featured enterprise DLP system is rarely justified in a company of fewer than 50 people. However, the fundamental elements of a DLP strategy — data classification, policies governing the use of devices and cloud services, USB control, encryption — are important regardless of size. In small companies, the built-in mechanisms of Microsoft 365 (Sensitivity Labels, basic DLP policies) or simple USB control tools, supplemented by good policies and training, are often sufficient.
Does DLP block remote work?
A poorly configured DLP can impede remote work — particularly if employees use personal devices or connections without a VPN. A well-designed DLP strategy accounts for the remote work model from the outset: conditional access policies, identity-based DLP (rather than network-based), and cloud applications with DLP control via CASB. The key principle is: DLP protects data, it does not block work.
How long does a DLP implementation take?
For an organization of 200–500 users, a full DLP implementation (from data classification to active blocking policies for all data classes) takes 9–12 months with internal resources engaged. If you focus first on the highest-class data and critical channels, you can have the first blocking policies active within 3–4 months.
Does DLP detect all leaks?
No — no DLP system is 100% effective. Photographing a screen with a phone, memorizing data and dictating it over the phone, optical media — these are channels that DLP does not cover technologically. DLP significantly reduces the risk of leakage through electronic channels, but it must be supplemented by policies, training, and physical controls.
What to do when DLP detects a real incident?
Activate the procedure from the Incident Response Plan (IRP). Preserve the DLP logs (they have evidentiary value), assess the scope of the breach (what data, how many recipients, is there a basis for an external leak?), decide on actions regarding the user account (monitoring/blocking), and assess the GDPR notification obligation (72 hours from determining the breach to UODO). When in doubt about the scope of the breach — proceed cautiously and consult with the DPO or a legal advisor.
Does DLP replace encryption?
No — DLP and encryption are complementary, not competing mechanisms. DLP controls data flows and blocks unauthorized transfers. Encryption protects data at rest and in transit — even if data leaks, without the key it is useless. An effective DLP strategy includes both elements: DLP policies prevent leakage, encryption minimizes the impact of a leak that occurs nonetheless.
Sources
- IBM Security. (2024). Cost of a Data Breach Report 2024. IBM Corporation. Available at: https://www.ibm.com/reports/data-breach
- Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (GDPR). Official Journal of the EU, L 119.
- Directive (EU) 2022/2555 of the European Parliament and of the Council of 14 December 2022 on measures for a high common level of cybersecurity across the Union (NIS2). Official Journal of the EU, L 333.
- Act of 5 July 2018 on the National Cybersecurity System (Poland). Journal of Laws 2018, item 1560, as amended.
- Act of 26 June 1974 — Labour Code (Poland). Journal of Laws 1974, No. 24, item 141, as amended (Art. 22(3) — employee monitoring).
- National Institute of Standards and Technology. (2022). Cybersecurity Framework 2.0. NIST. Available at: https://www.nist.gov/cyberframework
- Gartner Research. (2024). Magic Quadrant for Data Loss Prevention. Gartner, Inc.
- Microsoft. (2025). Microsoft Purview Information Protection documentation. Microsoft Learn. Available at: https://learn.microsoft.com/en-us/purview/information-protection
- Payment Card Industry Security Standards Council. (2022). PCI DSS v4.0. PCI SSC. Available at: https://www.pcisecuritystandards.org/
Related concepts
Explore key terms related to this article in our cybersecurity glossary:
- Cybersecurity — Cybersecurity is a set of techniques, processes, and practices for protecting IT systems…
- Encryption — Encryption is the process of converting data into encrypted text that is unreadable without a key…
- GDPR — GDPR is the EU regulation on the protection of personal data, in force since 2018…
- Insider Threat — Insider threat — the risk of data leakage or breach by employees or collaborators…
- CASB — Cloud Access Security Broker — a security layer intermediating between users and cloud services…
Learn more
Explore related articles in our knowledge base:
- IT Security Audit — a complete guide
- Privileged Access Management (PAM) — why administrator accounts are the primary attack target
- NIS2 and the National Cybersecurity System Act — what do the new obligations mean for Polish companies?
- Supply chain audit and NIS2 — how to manage supplier risk?
- Zero Trust — a security architecture for modern organizations
Check our services
Do you need cybersecurity support? See:
- Security audits - comprehensive security posture assessment
- SOC as a Service - round-the-clock security monitoring
- Vulnerability management - proactive infrastructure protection
