Preventing data leaks in a mid-sized company without a SOC: a 5-step plan

In a mid-sized company (ETI) with no SOC and no dedicated CISO, data leak prevention rests on a simple principle: protect the most exposed scope first, then prove that the controls work before adding others. The point is not to monitor everything, but to close the most likely egress paths and check regularly that they stay closed. A CIO can run this plan in a few months, with the tools already in place.

Why the “large enterprise” approach fails in a mid-sized company

Classic DLP methods assume a team that triages alerts every day. Without a SOC, those alerts pile up and nobody reads them. The result: rules left in audit mode for years, a dashboard full of false positives, and no certainty about what actually gets out.

Step 1: identify the most exposed scope

Start with two questions, not with a full inventory. Which data would do the most damage if it got out? Where does it get out most easily today?

The data that really matters

In most mid-sized companies, the list is short:

• customer files and personal data (HR, payroll, CRM);
• prices, margins, commercial offers in progress;
• drawings, formulas, source code or industrial know-how;
• sensitive legal and financial documents (contracts, transactions in preparation).

No need to launch a large classification project. Identify the three or four places where this data lives (a network share, a SharePoint site, the ERP, a cloud bucket) and note who has access to them. Data classification will come later, in a targeted way.

The most likely egress channels

The table below helps you prioritise. Exposure depends on your context, but the order is often similar.

Scroll the table →

Choose a single scope to start with: usually email and the collaboration cloud, because that is where most everyday leaks happen. The topic is covered in detail in our article on data leaks through personal cloud, Teams and Slack.

Step 2: switch on what you already own

Many mid-sized companies pay for licences that include unused DLP features. Before buying anything, check:

• the DLP policies of your office suite (Microsoft 365 or Google Workspace);
• the external sharing options on SharePoint, OneDrive or Drive;
• the web filtering categories of your firewall or proxy;
• the device control policies of your EDR.

Configure few rules, targeted at the data identified in step 1. Switch them to blocking mode as soon as possible for the obvious cases (for example: an HR export sent to an external address).

Step 3: prove that the controls block

This is the step almost every mid-sized company skips. A configured rule is not an effective rule. Gaps are common: a file format that is not inspected, a compressed archive that gets through, an exception added for a department and then forgotten. These false negatives are silent by nature.

The only way to know is to test actively: attempt, with synthetic data that looks like the real thing, to get the information out through each channel of the chosen scope. You then observe what was blocked, what was only logged and what got through without leaving a trace. The general method is described on our page about data exfiltration testing.

A concrete scenario

An industrial mid-sized company of 600 people switches on a DLP policy for files containing social security numbers. The CIO prepares a fake payroll export, filled with fictitious identities. He attempts four sends: direct attachment, zipped file, external sharing link, upload to a consumer storage service from the browser. The first is blocked. The other three raise questions. In half a day, he has a precise list of fixes, instead of a feeling of security.

This kind of test must be done in production, on the real workstations and the real flows, otherwise it proves nothing. Hence the importance of using decoys only: see testing in production with synthetic data.

Step 4: prioritise and fix

Without a dedicated team, you will not fix everything at once. Rank each finding on two criteria: the sensitivity of the data concerned and how easy the egress path is. An open channel, usable by any employee, on customer data comes before a complex technical scenario on low-sensitivity data.

For each fix, note the owner, the deadline and the test that will confirm it works. That last column changes everything: it turns an action into evidence.

Step 5: extend and measure over time

Once the first scope is closed and verified, move on to the next: browser and generative AI, then workstation, then outbound network. Replay the tests at regular intervals and after every major change (migration, new SaaS tool, policy update). A posture degrades silently.

The CIO’s monthly routine

1. Replay the exfiltration scenarios of the covered scope.
2. Compare with the previous month: new passes, regressions.
3. Review the exceptions added to the DLP rules and the firewall.
4. Deal with the two or three priority actions.
5. Report a simple metric to management: the share of scenarios blocked.

That last point matters. An executive understands “seven egress paths out of ten are blocked, here are the three remaining” far better than a volume of alerts.

Frequently asked questions