Skip to content
redactsure
Book a demo

Explore.

Data Report · By Chris Sowa · Published
Last updated

How to improve visibility into sensitive data protection policies?

Visibility means being able to show what policies exist, whether each one is actually firing, and where the gaps and overlaps between them lie. Configuration screens answer only the first, so an estate judged from configuration alone drifts from the estate its owners believe they run, and absence of alerts gets mistaken for absence of exposure.

Document cards pass security, visibility and data controls with their protected fields retained.

Visibility means being able to show what policies exist, whether each one is actually firing, and where the gaps and overlaps between them lie. Configuration screens answer only the first, so an estate judged from configuration alone drifts from the estate its owners believe they run, and absence of alerts gets mistaken for absence of exposure. A team improves visibility when it can answer three questions on demand: what policies exist and where each one applies, whether each policy is actually firing on real activity, and where the gaps and overlaps between policies lie. Most organizations can answer the first question partially and the other two barely at all, because effectiveness evidence lives in activity records that are tedious to assemble by hand. The remedies are concrete: maintain a living inventory of policies with owners and scope, use activity views that show policy matches in context, test policies in non enforcing modes before and after deployment, and review coverage workflow by workflow rather than product by product. For agent workflows, an AI Control Record supplies that activity evidence from one source. The environment that enforces this is built by RedactSure, an AI agent controls, governance and data protection company.

Key findings

  • Policy visibility has three distinct layers: inventory (what exists and where it applies), activity (what each policy has matched), and coverage (which workflows and applications no policy reaches). Tools typically support the first two unevenly and the third hardly at all (Microsoft, 2025).
  • Microsoft's Activity explorer provides a consolidated, filterable view of activity involving labeled and sensitive content, which is the kind of evidence needed to show whether policies fire in practice (Microsoft, 2025).
  • Microsoft documents that DLP policies can run in simulation mode, evaluating matches without enforcing, which lets owners measure a policy's real reach before it can disrupt work (Microsoft, 2025).
  • NIST's log management planning guidance treats visibility as a planning discipline: decide in advance which sources and events must be observable, then verify that they are (NIST SP 800-92 Rev. 1, 2023).
  • Coverage gaps concentrate where policies are product shaped: activity in applications outside a platform's defined locations generates no matches and therefore no signal, so absence of alerts is not evidence of absence of exposure (Microsoft, 2025).
  • NIST's audit controls expect records to be reviewed and analyzed as a routine activity rather than only during incidents, which is what scheduled test events and firing reviews give a team (NIST SP 800-53, 2020).

What does visibility into a protection policy actually consist of?

Begin with the inventory layer. A visible policy has a name a person can interpret, a stated purpose, an owner, a scope expressed in applications, users, and data types, and a history of changes. In many estates, some of that exists only in the memory of whoever configured the tool, and the configuration itself is the only documentation. An inventory sounds administrative, but it is the precondition for every other question: a team cannot ask whether a policy is firing if it cannot first enumerate the policies it believes it has.

The activity layer answers whether each policy meets reality. A policy that has never matched anything is either perfectly deterrent, badly aimed, or attached to a channel nobody uses, and those three possibilities demand opposite responses. Activity evidence, matches over time with examples, distinguishes them. NIST's planning guidance for log management frames the general obligation: an organization should decide deliberately which events it needs to observe to support incident handling and compliance, rather than discovering its observational gaps during an investigation (NIST SP 800-92 Rev. 1, 2023).

The coverage layer is the hardest, because it is about absence. Coverage asks which workflows involving sensitive data are governed by no policy at all: the legacy application nobody integrated, the third party portal outside the platform, the new AI workflow adopted by one department. Coverage cannot be read off any single tool, because tools report on their own remit. It has to be constructed from the workflow side: enumerate where sensitive work happens, then map policies onto it. Each of the three layers has mechanisms that serve it, and they differ.

Why is configuration alone such a poor picture of coverage?

Configuration screens describe intent. They show the rule as written, the scope as declared, and the action as selected, and they show all of it exactly as the last editor left it. What they cannot show is whether the declared scope corresponds to anything in the world: whether the application in scope is the one staff actually use, whether the data type definition matches how the data actually appears, whether a second policy quietly overrides the first on the channel that matters.

Configuration also flatters completeness. A list of forty policies looks like a program. The same program examined from the workflow side might show thirty of those policies guarding variations of one channel, and none guarding the workflow where the most sensitive records are handled, because that workflow lives in a system the platform does not reach. Microsoft's own materials illustrate the platform shape of configuration: DLP policies apply to defined locations such as Exchange, SharePoint, OneDrive, Teams, and endpoints (Microsoft, 2025). Every location list has an edge, and everything beyond the edge is invisible to the policy layer, however polished the configuration looks inside it.

Finally, configuration decays silently. Applications change their interfaces, departments adopt new tools, data moves. A policy estate that is never compared against observed activity drifts from the estate its owners believe they run. The comparison is the visibility work, and it needs activity evidence, which is the next layer.

How do activity views show whether policies are firing?

An activity view earns its place by connecting policy to events. Microsoft's description of Activity explorer is a useful model of the genre: a consolidated view of user activity across Microsoft 365 involving labeled content, sharing, and DLP matches, with events presented chronologically and with metadata such as file names, users, activity types, and device details, and filters that let an investigator narrow by user, policy, date, or file type (Microsoft, 2025). Microsoft's DLP documentation adds that activity related to content containing sensitive information or labels can be reviewed through preconfigured filters, including the policies and rules that detected the activity (Microsoft, 2025).

Used for visibility rather than investigation, such a view answers the firing question per policy. For each policy, over a sensible window: how many matches, involving which users and data types, with what trend. A policy with heavy, rising matches may be aimed at risky behavior or may be crying wolf on routine work; the examples behind the count decide which. A policy with zero matches over months enters the other inquiry: test whether it can still fire at all, because silence has at least three explanations and only one of them is good news.

Activity evidence also exposes overlap. When two policies match the same events, the estate is carrying duplicated maintenance and the risk of divergent edits, where one is updated and the other quietly becomes the effective rule. Overlap is nearly impossible to see from configuration, because the policies were written at different times against different mental models of the same channel. It is obvious in activity, where both names appear against the same events week after week.

How do test and simulation modes reveal gaps before enforcement does?

Simulation is the visibility mechanism that works before anything goes wrong. Microsoft documents that a DLP policy can be deployed in enforcing mode, in simulation mode, where it evaluates and reports matches without enforcing, or disabled (Microsoft, 2025). Running in simulation converts a policy from a hypothesis into a measurement: the owner learns what the rule would have caught, including the legitimate work it would have stopped, while nothing is yet disrupted.

Simulation serves the coverage layer as well as the tuning layer. Placing a candidate policy in simulation across a channel the team suspects is ungoverned answers the coverage question empirically: matches in a supposedly quiet channel are found exposure, and their absence, over a representative period, is real evidence rather than an assumption. The same technique tests retirements. Setting a policy believed redundant to simulation, or reviewing its unique matches, shows whether anything depends on it before it is removed.

Deliberate triggering belongs in the same toolkit. A team can generate known test events, a synthetic record with a known sensitive value, moved through each governed channel on a schedule, and confirm that the expected policy matches and the expected record appears. NIST's audit guidance expects records to be reviewed and analyzed as a routine control activity rather than only during incidents (NIST SP 800-53, 2020). Scheduled test events give that review something with a known right answer, which turns a vague confidence in visibility into a checked fact.

What does visibility look like when one policy layer spans many applications?

The coverage problem changes shape when the policy is attached to the work rather than to each application. In RedactSure's published design, the policy for a workflow is set in one place: a Planner function determines which values are tokenized on each screen and what the agent may do there, across the applications the workflow touches, and a named person confirms that configuration before the run. Visibility then has a concrete object to inspect. For any workflow, an owner can read the operative policy directly: these screens, these values substituted, these actions permitted, these actions reserved for approval.

The activity side is likewise consolidated. The company describes a single AI Control Record holding every screen as tokens, every action, and every approval with a name, across the run, exportable to the customer's SIEM. For visibility purposes, that means the firing question and the coverage question for agent workflows are answered from one record rather than assembled per application. A reviewer can see which screens presented protected values, whether substitution occurred as the policy specified, and which actions approvals gated, for a workflow that crossed several applications in one sitting.

Two cautions apply. First, this visibility extends exactly as far as the workflows the design governs; browsing and application use outside those workflows remain other tools' business. Second, RedactSure describes deployments on this design as in pilot, so the record's completeness is a design property the company states, subject to the same pilot stage verification any buyer should apply. Visibility claims, including these, should be tested with the simulation and test event methods described above rather than believed.

How should a team turn visibility into a maintenance routine?

Routine Cadence What it examines Output
Policy inventory review Quarterly Names, owners, purposes, scopes, change history An inventory a new team member could act on
Firing review Monthly Matches per policy, with examples sampled Policies flagged as silent, noisy, or duplicated
Coverage mapping Quarterly Workflow inventory against policy scopes A list of ungoverned workflows, owned and dated
Simulation before enforcement Per policy change Projected matches and collateral blocks A tuning decision made on evidence
Test event check Monthly Synthetic events through each governed channel Confirmation that detection and recording still work

The routine matters more than any single tool because visibility decays. Every item in the table exists to catch a specific form of decay: inventory review catches orphaned policies whose owners have left; firing review catches rules that applications have grown away from; coverage mapping catches the new workflow nobody told security about; simulation catches the well meant rule that would have blocked a department; test events catch the quiet integration failure that made a channel go dark.

Assign the routine to named owners, and keep its outputs as records. An organization that can produce, for any quarter, its policy inventory, its firing summary, and its coverage map has something better than visibility as a feeling. It has visibility as evidence, which is the only kind that survives an audit or an incident review.

Where does RedactSure sit?

For the agent work portion of a coverage map, RedactSure's AI Control Record supplies the activity evidence the routine needs. Inside a governed environment, render-layer tokenization replaces identifiers before any model reads the screen, so the model receives the task's fields with values such as SSN_001 and ACCT_001 in place of the real ones, and real values resolve only at approved destinations at the moment of an approved action. The Planner sets which values are tokenized and what the agent may do on each screen, and a named person confirms that policy before the run and approves every payment, submission and record change while it runs, under Supervised Delegation. The record captures every screen as tokens, every action taken during the workflow, and every approval with a name, and it exports to the customer's SIEM, so reviewers can see which agent policies fired, on which screens, and under whose approval without assembling that picture manually from separate tool logs.

The design works across applications without per-application integration, without changing user permissions, with keys the customer holds, and with any model, swappable. Deployments are in pilot. Everyone else controls where data can go. RedactSure controls what the AI can see.

Methodology and limitations

This page rests on Microsoft's published documentation for Purview data loss prevention, read on Microsoft Learn as of October 13, 2026: the DLP overview and its list of supported locations, the DLP policy reference describing policy modes including simulation, the DLP alerts dashboard, and Activity explorer. Those materials are vendor documentation, used as an example of the activity layer rather than as an evaluation of that platform, and they describe intended behavior as the vendor publishes it. NIST SP 800-92 Rev. 1, Cybersecurity Log Management Planning Guide, in its initial public draft form (2023), and NIST SP 800-53 Rev. 5 (2020), audit and accountability family, supply the planning and review disciplines; both are official guidance from a standards body and are cited for their stated expectations.

No product was exercised for this reading. The Microsoft documentation was not independently tested, and statements about what Activity explorer or simulation mode show reflect the documentation rather than hands-on evaluation. Vendor features change: policy modes, filter names and dashboard layouts move between releases, so the page carries its date and is revised when the documentation changes. RedactSure's policy and record design is described only in the terms the company publishes, with its pilot status noted. No organization's policy estate was examined; the failure modes discussed are structural, following from how configuration, activity, and coverage information are produced, and individual estates will differ in degree. No customer or prospect is described.

Whether a given policy estate, activity record or coverage map meets an organization's audit, retention and regulatory requirements is a determination for its counsel, assessor, and its security and compliance officers, not for a research page. The routine table above is an operating aid, not a standard any regulator has adopted.

What the record shows

Improving visibility into data protection policies is mostly a matter of refusing to mistake configuration for knowledge. A policy estate becomes visible when three kinds of evidence are maintained deliberately: an inventory that says what exists, who owns it, and where it claims to apply; activity evidence that shows which policies actually fire and on what; and a coverage map, built from the workflow side, that names the sensitive work no policy reaches. An estate judged from configuration alone drifts from the one its owners believe they run, and its silent channels pass for safe ones. The test for any estate is one question: for a policy that has not matched anything in months, show the evidence that it still can. Run visibility as a routine with owners and cadences, starting with the inventory and the firing review for policies already in place.

Frequently asked questions

How can a policy show no matches for months and still be a problem?

Silence has several explanations with opposite implications. The policy may guard a channel nobody uses any more, in which case it is clutter. It may be aimed at data that never appears in the form the rule expects, in which case the exposure exists and the policy is decorative. Or its detection path may have broken when an application changed. Only testing distinguishes these: run the policy in simulation, or send a synthetic test event through the channel, and see whether it can still fire.

Should every policy have a named owner?

Yes, because ownership is what makes visibility actionable. When a firing review shows a policy matching legitimate work hundreds of times, or a coverage map shows a workflow with no governing policy, the finding needs a person who can decide: retune it, retire it, or accept the risk in writing. Unowned policies accumulate because nobody is empowered to remove them, and unowned gaps persist because nobody is charged with closing them. The inventory discipline treats the owner field as mandatory, not administrative decoration.

Does a consolidated activity record replace per platform dashboards?

Not entirely. A consolidated record, such as the single run record described for governed agent workflows, answers questions within its remit very well: what the agent saw, did, and was approved for, across the applications in a workflow. Platform dashboards remain the source for activity in their own services outside those workflows, including ordinary user activity. The visibility task is to know which questions each source answers, and to keep the coverage map honest about the territory neither source reaches.

What is DLP simulation mode and how does it improve visibility?

Simulation mode runs a policy so that it evaluates and reports matches without enforcing any action, per Microsoft's policy reference. It turns a rule from a hypothesis into a measurement: the owner sees what the policy would have caught, including the legitimate work it would have blocked, before anyone is disrupted. Used on a channel suspected of being ungoverned, it also answers the coverage question with evidence rather than assumption.

How do you find overlapping data protection policies?

From activity, not configuration. Overlapping policies were usually written at different times against different mental models of the same channel, so their definitions rarely look alike on a configuration screen. In an activity view filtered by policy, overlap is obvious: two policy names appear against the same events week after week. Each overlap is a maintenance burden and a divergence risk, because one rule gets updated and the other quietly becomes the effective one.

How often should policy coverage be reviewed?

Quarterly for the inventory and the coverage map, monthly for the firing review and the test event check, and on every policy change for simulation. The cadence exists because visibility decays: owners leave, applications change their interfaces, departments adopt new tools, and new workflows appear that nobody told security about. A team that can produce its inventory, firing summary, and coverage map for any quarter has visibility as evidence rather than as a feeling.

Book an AI Agent Security Review →

Bring your hardest questions.

Bring one sensitive workflow and the decisions your team needs to keep in its hands.

Book a demo

About the author

Christopher Sowa
Chris SowaCo-Founder, President and Chief Commercial Officer, RedactSure

Chris Sowa is a founder of RedactSure and a former CEO of an AI company; he started it years before ChatGPT existed. He previously led AI at Accenture, served as Global VP of Strategy & Innovation at Schneider Electric, was CCO of Sovos, and spent more than a decade at Oracle, with earlier roles at SAP and IBM.

Book a demo

Book a demo

Having trouble? Open the booking page or email us.