1. DLP is a marathon, but you get points for split times.

“[Security and Risk] pros need to approach DLP as an ongoing process, not a product or even a one-time project.”

It is important to recognize that implementing DLP affects data used in many ways by many people, inside and outside your organization. One doesn’t simply plug in a server, flip a switch and reap the benefits.

While data loss prevention is a long-term project, initial benefits (time to value) can be realized quickly and greatly enhance security. The most successful DLP programs start small and are iterative. These involve selecting the most critical data type (PCI, PHI and PII are most common according to the report), identifying it throughout your organization, and observing how the data is used. This provides immediate benefits to managers, often revealing existing activities that put data at risk. These activities can then be resolved by working with business managers to mitigate those risks.

The initial roll-out need not take a long time; enterprise-wide deployments for initial data types can often be completed in under 120 days. Subsequent rollouts with additional data types are faster. It requires, however, a reliable, tested plan for the implementation.

2. Statistics often reflect logical choices

“[PCI, PHI and PII] … use cases encompass 75% of current DLP deployments.”

This statistic should not come as a surprise to anyone. It can be difficult to justify security purchases with traditional Return on Investment (ROI) calculations, and resorting to FUD can result in vendors and security people sounding like the boy who cried wolf. Organizations must prioritize their spending in every department, and security is no different.

While DLP is on the wish list of many organizations, regulatory compliance provides the justification for many security purchases. It does not require an ROI analysis – it’s simply required. Further, the parade of breach disclosures has made this threat more tangible to executives. The release of data subject to HIPAA or PCI standards can result in monetary fines. It also garners headlines, bad publicity, lost revenues, and difficult board meetings for executives.

Helping CISOs make an initial purchase for compliance simplifies their longer-term goal of protecting other sensitive information. Compliance is also a logical place for a DLP program to start. As noted before, successful DLP programs are iterative, starting with one or two data types, building policies that work, and then adding additional data types. Personal information is often easier to classify automatically, since it means looking for social security or credit card numbers.

3. Top down approaches don’t always yield optimal results

“Half of information workers who willfully go around security policies do so because they feel it is the most efficient way to get things done, and 34% feel that the security policies are too unreasonable to start.”

There are two important points in this sentence. First, one should not assume that all violations of data protection policies are malicious. Knowledge workers may be unaware that an action adds risk, or may simply be trying to create shortcuts that make their jobs easier. Second, data loss prevention planning and rollouts should be iterative and include business owners and managers.

Some of the behavior noted by Forrester is undoubtedly the result of poor or accelerated DLP rollouts. When organizations rush to implement a program enterprise-wide before they truly understand information workflow and user behavior, problems are more likely to occur.

This gets back to a company’s data loss prevention implementation strategy. A successful DLP rollout includes four distinct stages: discovery, observation, rollout, and enforcement. This allows organizations to first identify and observe how sensitive data is used before attempting enforcement. When actions are observed that put data at risk, the initial reaction should not be to block the action. Instead, security and business managers should work together to understand why the action is taking place, if it is a necessary business activity, and if alternative behaviors can mitigate risk without hindering employee productivity.

4. Access to a device ≠ access to data

“Ensuring that the right users have access to the right data when they need it is a key part of data defense. More importantly, as mega breaches like the Korea Credit Bureau have shown, access control is critical for privileged users.”

A common perception is that data loss prevention requires a trade-off between data security and data usability. This may be true if you are taking a user-centric or device-centric approach to DLP. However, there are alternatives to break this coupling. By taking a data-centric approach to DLP, organizations can separate data rights from device and/or user rights.

The “privileged user” example in Forrester’s report is the perfect example. This is a user, often a system administrator, who must have root privileges on devices in order to do their job effectively. In a device- or user-centric scenario, their privileges would, by default, also allow access to and control over data on those devices.

In contrast, data-centric security applies data loss prevention policies to the data itself. Data usage is controlled by a combination of the user’s identity, the data classification, and the requested action. This allows privileged users to perform their tasks, without allowing them to access protected data on the system.

5. You can simplify data loss prevention by taking a different approach

“[DLP is] not a product, but an embedded function.”

Thinking of data loss prevention as a singular product leads one to address each exfiltration channel as a separate problem to be solved. Vendors offering point solutions such as USB control, email filtering, or network detection have supported this approach.

It’s true that data can be lost through many channels, including email, removable devices, cloud services, even by printing or screen capture. Instead of treating these as discrete problems looking for solutions, it’s more logical (and easier) to step back and reverse the thought process. The common denominator is the data itself. The “embedded function” is protection of that data; limiting its use based on the contents of the data, the user, and the action taking place.

Forrester offers good advice: we need to look at protecting data itself, not separate egress channels; we need to prioritize our efforts to focus on our most critical data; and we need to work with business managers to make sure that data protection does not hinder our employees.