From data risk to data control: What fixing it at the source looks like

Data security has been on a journey since the introduction of Data Security Posture Management (DSPM) and the subsequent explosion of AI. As an industry we are better than ever at finding data risk. We did not get equally good at closing it, and the gap between those two capabilities is where most programs currently live. So what actually closes findings faster than new ones arrive? 

It’s not more people, just ask the SOC. The math on that has never worked and it isn’t about to start. 

The organizations making real progress changed something more basic: they stopped treating remediation as a queue of individual tickets and started treating it as a set of controls applied once and inherited everywhere. It sounds like a semantic distinction but it’s the difference between a backlog that compounds and one that shrinks. 

In practice that comes down to three moves. 

Make discovery produce actions, not observations. A classification that carries a policy, and a policy that carries a control an analyst can apply directly, removes the handoff that caps throughput today. 

Protect the data rather than the location. Controls applied to the value itself travel with it into every copy, including the copies nobody has found yet. One action closes a category of findings instead of one. 

Delete what shouldn’t exist. Defensible disposal is the only remediation that closes a finding permanently and costs nothing to maintain. 

The rest of this post covers each in turn. 

Move one: stop closing findings one at a time 

A conventional remediation workflow processes findings serially. Scan surfaces an exposed dataset > ticket gets routed to an owner > owner applies a fix > finding closes. Repeat. Each step requires a human, a decision, and a calendar invite. Throughput is capped by the number of people willing to attend the calendar invite. 

The alternative is to make discovery produce actions rather than observations. When a scan identifies a field as regulated cardholder data, that classification should carry a policy, and that policy should carry a control that gets applied without a separate negotiation. 

This isn’t a call for entirely autonomous systems applying policy on their own. It’s a call to let the analyst who found the problem resolve it, instead of documenting it for somebody else. The ticket isn’t the work. The ticket is what we do because the tool that found the exposure can’t do anything about it. 

That’s the practical meaning of discovery-first and enforcement-native, and it’s why the distinction between a posture tool and a data security platform matters operationally rather than architecturally. A posture tool ends its job at the finding. If the platform that found the exposure can also close it, the queue stops being the bottleneck. 

OpenText™ Voltage™ Data Security Platform handles discovery and classification across structured and unstructured data, on premises and in cloud environments. What it does differently is hand its findings to controls rather than to a dashboard. 

Move two: protect the data, not the location 

This is where the arithmetic actually changes. 

Access controls govern a location. Protect the location and you’ve closed only one finding. Every copy of that data living somewhere else remains exactly as exposed as it was, and in most environments the copies substantially outnumber the originals. 

By protecting the data itself, the math inverts. When a field is encrypted or tokenized at the source, the protection stays with it everywhere it goes afterward: every replica, every extract into a warehouse, every downstream dataset somebody builds next quarter without mentioning it to anyone. One control action covers the copies you know about and the copies you haven’t found yet. You close a category rather than an instance. 

OpenText Voltage SecureData applies this using NIST FFX-mode AES format-preserving encryption, standardized under NIST SP 800-38G, alongside stateless tokenization. That last sentence is for the standards reviewers. Everyone else has two questions. 

Do the applications keep working? Format-preserving means a protected value keeps the shape of the original — a 16-digit card number stays a 16-digit card number. Schemas don’t change. Referential integrity holds across systems, so joins still join and analytics still run against protected data. 

Can clients hold their own keys? That matters for the audit conversation, and for anyone carrying data residency obligations they can’t delegate to someone else’s region. 

Both points exist for the same reason. “Just encrypt it” has historically been the recommendation that triggers a six-month application remediation project, which is a significant part of why so many findings sat open for so long. The finding wasn’t ignored. The fix was priced out of reach. Removing that cost is what makes remediation at scale plausible rather than aspirational. 

Move three: delete what shouldn’t exist 

The cheapest way to close a finding permanently is to not have the data. 

Redundant, outdated, and trivial (ROT) data makes up a meaningful share of most backlogs, and none of it needs protecting because none of it needs to exist. Everyone agrees in principle. The obstacle is that deleting records out of a live relational environment risks breaking the applications and reports that depend on them, so the safe answer becomes keeping everything indefinitely and paying to protect it. 

OpenText Voltage Structured Data Manager handles archiving, retention, and defensible deletion for structured data while maintaining referential integrity, which is what makes disposal defensible rather than merely brave. Retired applications get decommissioned with their data intact and accessible. Retention policy gets applied as policy rather than as a project. And the deletion produces an audit trail, which is the difference between telling a regulator the data is gone and demonstrating it. 

The side effect is a storage and licensing conversation that tends to fund itself. Nobody gets promoted for deleting data. It remains the highest-return remediation available. 

Which findings actually go first 

Three moves are useful. Sequencing them is what makes the program work, and the sequencing question is really a prioritization question: out of tens of thousands of open findings, which several hundred are worth acting on this quarter? 

Severity labels are a poor answer, because everything regulated is critical and a queue where everything is critical is a queue with no order in it. Financial exposure is a better one. Discovery that scores findings by the cost of the records involved changes who says yes. Forty thousand critical findings is a meeting. The same queue expressed as regulated records with a per-record exposure attached is a business case, and it identifies the two hundred findings that matter this quarter. 

The version most organizations reach for first is PCI scope reduction. Tokenizing cardholder data pulls systems out of assessment scope, which is a cost reduction the finance side can verify without taking security’s word for it. It’s a narrow use case that happens to fund the broader program. 

What about the backlog 

None of this empties the backlog. Nothing empties the backlog. Data will keep being created faster than anyone governs it, and the queue is a permanent feature of the job. 

What changes is the slope. When one control action covers every copy of a protected value, when disposal closes findings permanently, and when prioritization runs on financial exposure rather than alert volume, the line starts moving in the right direction — which is the only metric a board has ever actually wanted.  

Want the operational version? From data risk to data control: the DSPM playbook walks through the sequencing — what to discover first, what to protect, and what to delete — with the decision criteria for each stage.