Guide · 9 min read
How to design GenAI DLP controls with a control matrix
Why per-application DLP rules stop scaling once you have more than a handful of AI tools, and how a governance-category × data-family matrix replaces them with a model you can defend and reuse.
The problem
Per-application rules stop scaling almost immediately.
The first GenAI control most organisations write is per-application: someone asks about ChatGPT, so a rule gets written for ChatGPT. Then Copilot arrives, and a rule gets written for Copilot. Then a team adopts a niche transcription tool nobody has heard of, and the pattern repeats.
This works for about five applications. Past that it produces three specific failures. Rules drift apart — two applications with identical risk end up with different treatment because they were assessed months apart by different people. Nobody can answer “what happens to an application we haven’t assessed yet?”, which is the case that actually matters, because unassessed is the default state of every new tool. And when an auditor asks why a particular control exists, the honest answer is that someone decided it once and didn’t write down why.
The underlying mistake is treating the application as the unit of decision. It isn’t. The application is one input to a decision whose real subject is what data is allowed to move where, and under what conditions.
The model
Two axes, and every cell is a decision you can defend.
A control matrix replaces the per-application list with a grid. One axis is the governance category the application falls into. The other is the family of data somebody might put into it. Every cell holds the enforcement action for that combination.
Four governance categories are usually enough, and the fourth is the important one:
Approved and Supported
Enterprise agreement in place, admin controls available, DLP can actually inspect the traffic. The tools you want people using.
Approved with Conditions
Fit for defined use cases with limits attached — scoped to certain teams, certain data, or certain activities.
Restricted / Unassessed
The default. Not evaluated yet, or evaluated and found wanting. This category does the most work in practice.
Prohibited
Blocked outright at the network level. Reserved for genuine unacceptable risk, because every entry here generates support tickets.
The other axis is data families rather than individual detectors — credentials and secrets, regulated data, source code, customer and employee data, security and infrastructure detail, and ordinary public content. Families, not detectors, because a matrix keyed to individual regex patterns has hundreds of rows and changes every time someone writes a new detector. A matrix keyed to families has a few dozen cells and changes only when your risk appetite changes.
Why it holds up
The default cell is the one that saves you.
The reason to build the grid this way is that it answers the unassessed case structurally. A new AI tool appears in your traffic on a Tuesday. Nobody has reviewed it. With a per-application list, it is governed by nothing until someone notices. With a matrix, it lands in Restricted / Unassessed and inherits that row’s treatment immediately — coaching on access, blocking on secrets, justification on regulated data, whatever you decided that row should mean.
You made that decision once, calmly, in advance. You did not make it under pressure on the Tuesday. That is the entire value of the model, and it is why the Restricted row deserves more argument than the Prohibited one.
Making it real
A matrix is a design, not a control.
The gap most teams hit next is that a matrix is still a decision artifact. Something has to turn each cell into configuration in the platform that actually enforces: detection profiles, application groupings, policy order, user and group conditions, notification templates, and a defined fallback for traffic that matches nothing.
Policy order matters more than people expect. A permissive rule sitting above a restrictive one silently disables it, and nothing in the console warns you. This is the step where a good design quietly becomes a broken deployment, and it is worth treating as engineering work rather than admin.
Then it has to be proven. For each cell that matters, a test with a known input, an expected outcome, and a captured result — otherwise you have a control you believe in rather than a control you have evidence for.
Start here
A practical first pass.
- 01List your data families first, before looking at a single application. Six is usually right; ten is too many.
- 02Decide the Restricted / Unassessed row before any other. It is your actual default posture.
- 03Fill Prohibited sparingly — every entry is a support ticket and a workaround waiting to happen.
- 04Only then sort your known applications into categories. Most will be Approved with Conditions.
- 05Write the test for each cell you care about at the same time as the cell, not months later.
More guides in this series are in preparation, covering vendor policy structure and mapping regulation to specific controls.
Uraikkal builds this matrix for you — and everything downstream of it.
Governance categories, the control matrix, the vendor policy architecture that implements it, the deployment sequence, and the test evidence that proves it works.