Six stages that run as a loop, not a line. Each one produces something the next stage needs, and the last one changes the first.
Build an inventory of where sensitive data actually sits, not where it is supposed to sit.
Scanning runs against file shares, endpoints, mail stores and cloud repositories, in place, without relocating what it examines. Content is matched against the patterns your organisation defines rather than a fixed dictionary, and the scan reads inside archives and common document formats. Each finding is reported with its location and the permissions currently attached to it.
Apply your own categories to what discovery found, so later stages have something to reason about.
Classification weighs the surrounding document alongside the pattern match, which is what separates a customer record from a template that merely looks like one. Where a match is unambiguous the label is applied automatically; where it is not, the item goes to a reviewer rather than being guessed. Labels travel with the file, and every decision can be traced back to the rule that produced it.
Turn labels into rules about movement, written in terms of what should happen rather than what to detect.
A policy names a label, the people or groups it applies to, the destinations it covers, and what should happen when the two meet. The same label can be handled differently depending on who is acting and where the data is going, which is what keeps rules workable in practice: an internal transfer and an external upload rarely deserve the same answer. Policies are versioned, so it stays clear which rules were in force at any point.
Evaluate the rule at the moment data moves, on the device where it is moving.
Enforcement happens at the point of action: attaching a file, copying to removable media, printing, uploading through a browser, pasting into another application, writing to a network share. Because the decision is made locally, it holds when the endpoint has no connection. When a rule stops or questions an action, the person is told why at that moment rather than discovering it later, which is the difference between a control that teaches and one that only frustrates.
Reconstruct what happened from a record that was written at the time, not assembled afterwards.
Each decision is stored with the file, the person, the destination, the time and the rule version that produced it. Related events are grouped, so an incident reads as one sequence rather than a thousand separate lines. The record can be searched across users, files, channels and time ranges without exporting it first, and it leaves the platform in a structured form your own tooling can read. How long it is kept is your decision, not a fixed product setting.
Use what the record shows to change the rules, then run the loop again.
A policy that fires constantly is usually wrong about the data rather than right about the risk. Reviewing where rules trigger, which warnings people override and which justifications they give shows what needs adjusting: a category that is too broad, a destination that should have been allowed, a team doing legitimate work the policy never anticipated. Those adjustments feed back into classification and policy, and the next scan starts from a better definition than the last.
The most useful demo starts at whichever stage you are stuck on. Tell us which one, and we will start there.
