A security platform reads everything. This page is about what we do not get to see.
On-premise, the platform runs on infrastructure you choose, so the short answer to most residency questions is that your events never leave your estate; as SaaS, they are held on infrastructure we operate. That makes the interesting questions the other ones: what the software collects about your people, what a deletion actually deletes, and whether you can verify the binaries you installed.
What we do not get to see · drawn from this page
A detector gets the join key. Not the identifier.
Device-management telemetry arrives carrying identifiers a detector does not need. This is what happens to each field on the way in, when an analyst reads it, and when a person is erased.
ArrivesKeptWhen an analyst reads it
serial number
serial numberdropped rather than stored
nothing to read
phone number
phone numberdropped rather than stored
nothing to read
SIM identifier
SIM identifierdropped rather than stored
nothing to read
hardware address
hardware addressdropped rather than stored
nothing to read
management name
management namethe device is carried by this name
management name
the person
the subjectthe person rides as the subject
••••••masked when it is read · revealing it is a separate request, approved by a different operator
sensitive values
encrypted under the person’s keywhen crypto-shredding is enabledkey destroyedpermanently unreadable — on disk, in segments, and in backups taken before the request
••••••masked above the reader’s clearance · every read auditedunreadable
Survives an erasure: the tamper-evident record of what happened, and the pseudonymous references to the person — the audit trail and the personal data are deliberately not the same thing.
Serial numbers, phone numbers, SIM identifiers and hardware addresses are dropped rather than stored. The device is carried by its management name, and the person rides as the subject, masked when it is read. When crypto-shredding is enabled, a person’s sensitive values are held under their own key; fulfilling an erasure destroys it, and the record of what happened survives.
Where your data is
On-premise: on your disks, in your jurisdiction.
On-premise, the platform runs in your environment, and the licence does not require anything to leave it — an expired licence stops forward motion rather than reaching for your data. As SaaS, your events are held on infrastructure we operate; where that is, where backups are kept and where support access comes from are described in your customer agreement, not assumed from this page.
For an on-premise deployment this is also the honest limit of our own visibility: we cannot audit your deployment for you, and we cannot recover it for you either.
Key custody
When enabled, a person's sensitive values are encrypted as they are classified on ingest, under a key root scoped to the tenant. The root is held by the platform or imported by you with a fingerprint you can recompute; holding it in your own key service, so it never enters the platform at all, is a documented interface we do not yet ship a driver for.
Rotation re-wraps every live key. Revoking a root is destruction rather than a flag, so it is held for a person's approval with the number of affected keys shown, and a tenant can require that approver to be a second person.
What the platform collects about people
Monitoring software is where privacy commitments get tested, because the useful signal and the intrusive detail often arrive in the same record. The rule we hold is that a detector gets the join key it needs and not the identifier it would be convenient to keep.
Hardware identifiers are not modelled
Where device-management telemetry arrives carrying serial numbers, phone numbers, SIM identifiers or hardware addresses, those fields are dropped rather than stored. The device is carried by its management name; the person rides as the subject, masked when it is read, which is all a behavioural join needs.
Monitoring runs against the purposes you declare
Once you declare a monitoring profile, the families that amount to worker monitoring — employee device posture most sharply — run only for the purposes it covers. A purpose it does not cover does not silently proceed: the analysis is skipped and the omission is recorded once against the declaration. Until a profile is declared, they are not constrained.
Sensitive values are masked when an operator reads them
Classification happens on the way in, so what an analyst sees in a search result or a report is masked above their role's clearance, and every read is audited. Revealing a pseudonymised employee's identity is a separate request, tied to a case and approved by a different operator.
Retention is per purpose, not one global dial
A declared purpose can carry its own window. When a person's basis for it ends and the window lapses, an erasure obligation is raised automatically, scoped to the data categories collected for that purpose — the material collected for other lawful purposes stays lawful and stays put.
What a deletion actually deletes
Most systems answer a deletion request by hiding rows. That leaves the data on disk, in segments, and in every backup taken since — which is a reasonable thing to be asked about and a difficult thing to answer honestly.
Erasure is destruction of a key
When crypto-shredding is enabled, a person's sensitive values are encrypted under a key belonging to that person. Fulfilling an erasure destroys the key, and those values become permanently unreadable — on disk, in segments, and in backups taken before the request, without anyone having to find and rewrite those backups.
The tamper-evident record of what happened, and the pseudonymous references to the person, survive, because the audit trail and the personal data are deliberately not the same thing. A restart against an old keystore re-destroys the key rather than resurrecting it.
It is irreversible, and it is treated that way
Administrator-only, behind a recorded erasure obligation, with a confirmation that says what is about to be destroyed. It refuses if no obligation has been logged, rather than obliging first and asking later.
The result is reported honestly
A person with no encrypted material on record returns "fulfilled, no key to destroy" rather than a satisfying but false confirmation that something was destroyed.
Rights never depend on a licence
Consent, erasure and grievance handling keep running past expiry, indefinitely. A commercial dispute between us cannot suspend a duty you owe somebody who is not party to it.
Verifying what you installed
You are about to run this on the machines that matter most, so the supply chain of the software itself is a fair question to ask before the security features are. No release has been cut yet, so the first three below describe what the release pipeline produces, not an artifact you can check today.
Every release is built with a bill of materials
So you can answer "are we affected" about somebody else's vulnerability without waiting for us to tell you.
Release artifacts are built to be signed, checkably
Keyless signing with public transparency, so a signature can be verified without us handing you a key to trust.
Every release is built to carry its provenance
An attestation that says which builder produced the artifact from which source, verifiable independently of our word for it.
The platform enforces this on your estate too
The same check is a detector: an artifact deployed despite broken provenance raises a finding. We are asking of ourselves what the product asks of your builds.
The regimes it works to
The rights engine implements these 8 regimes end to end — consent, access requests, erasure, correction and grievance.
NIST CSF 2.0 · NIST SP 800-171 · IEC 62443-3-3 · NIST SP 800-53 (Low) · EU AI Act · NIST AI RMF 1.0 · ISO/IEC 42001 · CNSA 2.0 · NIST PQC — each check assessed from evidence in the lake rather than from a questionnaire.
Personal data carries the law that governs it
Personal data found in events is attributed to the law that governs it, across 62 jurisdictions.
All of that is capability the platform ships. None of it is an audit this company holds.
Scope & Honest LimitsHonest limitsExpand · Full ledger →
No certifications, and no mapping dressed up as one
A control mapping exists internally. A mapping is not an audit, and we will not put a standard's name on this page until somebody independent has signed against it. The auditors' page states the path.
On-premise cuts both ways
On an on-premise deployment, your data staying with you also means the operational burden stays with you: patching, backups, key custody and availability are yours. We think that is the right trade for this kind of software, and it is a trade.
Privacy behaviour depends on your declarations
Purposes, retention windows and monitoring scope are things you declare. The platform enforces what you declare; where you have declared nothing, it does not constrain — it cannot decide on your behalf what is lawful where you operate.
No status page yet
We do not publish a status page yet — including for SaaS. An on-premise deployment is yours to watch.
Reporting a problem with the platform itself
Vulnerability reports go to the security page, which renders the disclosure programme — and any acknowledgement and publication windows it commits to — from the running deployment. Measured detection coverage, and where it stops, is on the proof page.
Next step
Verify the privacy and evidence controls on your own estate.