What Watchtower is
Compliance as structured knowledge, durable findings, and provable history.
Compliance as data, not a feature
Watchtower treats compliance as a form of structured knowledge, not as a product feature. Frameworks, checks, controls, and the mappings between them are rows in a database. A new benchmark version is a migration. Your internal policy is a pull request against your own repository. An auditor's bespoke control is a record, not a release.
Out of the box Watchtower ships the benchmarks you need on day one: industry security benchmarks for Microsoft 365, Intune, iOS and macOS, a partial mapping of the CISA ScubaGear M365 baseline and of the Microsoft Zero Trust Assessment, and a curated best-practice and Copilot-governance catalog, maintained as those benchmarks evolve. Individual checks also carry control-crosswalk mappings (MITRE ATT&CK, on a subset of checks) so a finding can be reported against an external control set, but a crosswalk is metadata on a check, not a separate runnable framework, and we describe it as exactly that. That content is where most customers start, and for most it is enough. The ones with deeper needs extend it through the same mechanism the platform uses internally: your own checks, written the same way as ours, reviewed through your own approval process, stored in the same table. Because the data is structured rather than documentary, it is machine-readable and exportable, not trapped in a proprietary island.
Findings are durable, scans are ephemeral
A compliance question is not "what did the latest scan find." It is "what is the state of every compliance-relevant condition across every tenant, right now, and how did each condition get here."
A scan is an event that produces observations. Observations update findings. Findings persist across scans and carry their own lifecycle: open, muted, accepted as risk, resolved. Most tools get this backwards and treat each scan as the truth, then bolt drift detection on later. Inverting it is what makes "how long has this been broken" a first-class question instead of a retrofit.
Provable, not tamper-proof
Every state change is recorded in an audit trail designed for independent verification: hash-chained, signed, append-only at the database level. A security-accountable customer can prove to an auditor, a regulator, or themselves that no finding was silently edited.
The claim Watchtower makes is precise. The trail is tamper-evident and any tampering is provably detectable. It is not tamper-proof: anyone with sufficient database access can destroy data, but no one can alter history undetectably. We state the claim exactly, because a compliance platform that overstates its own guarantees is asking for the faith it claims to replace.
The trail is tamper-evident and any tampering is provably detectable. It is not tamper-proof: anyone with sufficient database access can destroy data, but no one can alter history undetectably.
It runs where you need it
The data Watchtower holds (findings, audit trails, evidence) is itself sensitive compliance material, and regulation increasingly forbids entrusting it to someone else's jurisdiction. Watchtower deploys on your hardware, in your jurisdiction, inside your network boundary. Self-hosting is not a deployment convenience here; it is the data-sovereignty guarantee.
One model, two shapes of customer
A 600-tenant MSP and a five-entity enterprise are not the same product, but they run on the same schema. Tenancy, scope, and isolation mode are configuration, not forks. You do not adopt a different Watchtower because you are shaped differently.