The full capability list across all four products, described in terms of mechanism rather than outcome. If you would rather read it product by product, start from the Product page.
Find sensitive data across the shares, endpoints, mailboxes and cloud stores you nominate — and see who can currently reach it.
Find out more →Apply your organisation's own categories to the data discovery found — automatically where the match is clear, with a reviewer where it is not.
Find out more →Decide what labelled data may leave, and act at the moment it tries — on the endpoint, in email, in the browser and on removable media.
Find out more →Know when a file, directory or permission changes against a baseline you set — including the bulk change that matters more as one event than as thousands of lines.
Find out more →Scans are scoped by location rather than by guesswork: you nominate the shares, mailboxes, endpoints and repositories to examine, and set how often each is revisited. Everything is read in place.
File shares, endpoints, mail stores and cloud repositories you nominate.
An inventory of findings with location, match reason and access.
Your category scheme is defined once and applied everywhere. Where a match is clear the label is automatic; where it is not, the item waits for a person rather than being guessed at.
Applied where the pattern and the context agree.
Held for a person where the evidence is mixed.
The agent evaluates policy locally at the moment of the action, which is what lets controls hold on a device that has been off the network for weeks.
Labels and rules live on the device, so offline is not a gap.
The person is told which rule acted, and why, as it happens.
Cloud storage is treated as another location to inventory and another destination to govern, using the same categories and the same rules as everywhere else.
Cloud findings are not a separate report to reconcile.
A label means the same thing wherever the data is held.
Most sensitive data leaves through a message or a browser tab. Both are inspected before the content goes, and both can warn rather than simply block, which matters when the sender is doing legitimate work.
Inspection happens at composition and upload, not after delivery.
Graduated responses keep legitimate work moving.
A first scan usually returns more findings than any team can work through. Prioritisation exists so the list is ordered by something defensible rather than by scan order.
Exposure and category decide the order, not scan sequence.
An accepted finding stays accepted across later scans.
Integrity monitoring baselines the locations you nominate and reports change against that baseline, including the kind of bulk change that matters more as one event than as thousands of separate lines.
Change is reported relative to a known good state.
Change events sit beside policy decisions, not in a separate log.
When a policy acts, Data Guard records what was inspected, which rule matched, who was involved and what happened next. That record is searchable, exportable and kept for as long as you decide.
Rather than list logos, here is what the platform exposes. If your tooling can consume a structured event stream and call an authenticated endpoint, it can work with Data Guard — and you can confirm that against your own stack rather than against a compatibility chart.
We describe what the platform exposes so your architects can judge fit.
A specific connection is confirmed against your stack, in writing.
A capability list only goes so far. Tell us which of these you need to be sure about and we will show you that part working.
