Compliance, security and AI governance.
Eleven engines, one control graph.
Compliance, consent, risk, security, AI governance, data, mapping, evidence and developer tooling, each one writing into the same graph, so a finding in one becomes evidence in all the others.
Compliance programme
Enable a framework per entity and the control set arrives with it, pre-mapped, pre-owned, and scored from live evidence rather than a spreadsheet someone updates in audit week.
- Framework enablement per legal entity
- Policy generator with versioned attestations
- Readiness scored continuously from evidence
- Scoped auditor workspace and one-click export
Consent & cookie manager
A banner people can answer and the proof that they did. Versioned notices, purpose-level choices and an append-only ledger that survives the audit.
- Proof-of-consent ledger, append-only
- Versioned notices per language
- Accept, reject, partial and withdraw
- Salted IP hashes, anonymous subject ids
Risk assessment & register
Score likelihood and impact once, attach the treating controls, and residual risk moves on its own as those controls pass or fail.
- 5×5 assessment, inherent and residual
- Mitigate · accept · transfer · avoid
- Named owner and review date
- Infrastructure, vendor, data, people, process
Deep security intelligence
Behaviour baselining, graph-based attack-path simulation and Zero Trust scoring, security that knows which controls break when it fails.
- Anomaly detection with P0–P3 SLAs
- Attack-path chaining with blast radius
- 0–100 Zero Trust score across five dimensions
- Continuous penetration testing
AI governance & evaluation
Register models, prompts and MCP servers, run judge-scored evaluations, and evidence them against the AI regimes the same way you evidence a firewall rule.
- Model, prompt and MCP server registry
- Judge-scored evaluation runs
- Drift and bias monitoring
- EU AI Act risk classification per system
Data discovery & DSAR
Find the personal data nobody remembers creating, map how it crosses borders, and answer access, correction and erasure requests on the clock.
- Discovery and classification across stores
- Cross-border data-flow mapping
- DSAR workflow with statutory SLAs
- Breach simulator and notification drafts
Cross-framework mapping
One control satisfies many regimes at once. The mapping engine shows exactly which, where the gaps are, and what a new country actually costs you.
- 45 shared controls, 700+ requirement mappings
- Overlap and gap diagnostics
- Delta view before you enable a regime
- Custom framework authoring
Automated evidence & ledger
Hash-chained, timestamped artefacts for passing controls and exceptions alike, immutable, exportable and readable by an auditor without a walkthrough call.
- Zero-screenshot collection
- Tamper-evident audit trail
- Evidence for failing controls too
- One-click audit export
Device & MDM posture
Endpoints are where most SOC 2 and ISO findings actually live. Sync your MDM and every laptop and phone arrives with its own posture, checked continuously rather than screenshotted once a year.
- Intune, Jamf and Google Workspace MDM sync
- macOS, Windows, Linux, iOS and Android
- Disk encryption, screen lock, OS version, agent health
- Compliant, at risk and non-compliant, per device
- Manual enrolment for anything the MDM cannot see
Performance & reliability
Availability is a control, not a nice-to-have. Run API load tests and frontend audits against your own thresholds, and the results land as evidence for the resilience requirements DORA and NIS2 actually ask about.
- API load tests with a full request builder
- Latency percentiles against SLO thresholds
- Lighthouse scoring for the frontend
- Status-code distribution and network phase breakdown
- Scheduled, on deploy, or on demand, with CSV export
Developer-first tooling
Compliance in the editor and the pull request, not in a quarterly meeting. Integrate once and every later capability arrives on an SDK bump.
- Node, Python and Go SDKs
- VS Code and JetBrains plugin
- Merge-blocking CI gate
- API, IaC and DAST scanners
Your next audit could be a link.
Thirty minutes. We connect one cloud account live and show you real evidence landing in the ledger before the call ends.
What 'one control graph' actually means
The phrase is doing specific work, so it is worth unpacking rather than leaving as a slogan. Every engine on this page writes into the same structure: statutory requirements map to shared controls, controls are tested by check definitions, check results roll up into live control status, and control status determines requirement status and therefore readiness.
The direction of that chain is the important part. Readiness is derived from control results rather than asserted, which means no one can mark a requirement satisfied by hand. It also means a single failing check propagates: it lowers readiness in every framework that maps to that control, raises residual risk on every register entry that control treats, and shows up in the evidence ledger with a timestamp.
| Without a shared graph | With one |
|---|---|
| A control is duplicated per requirement per framework | One control carries many requirement mappings: about 45 controls to 356 mappings |
| The same screenshot lands in four evidence folders | One test result satisfies every requirement mapped to that control |
| Adding a framework restarts the work | Adding a framework is a delta against controls you already operate |
| Readiness is a stored number somebody edits | Readiness is computed from check results and cannot be hand-set |
| Risk and compliance drift apart between audits | A failing control moves both at the same moment |
Not modelled is not the same as passing
A requirement with no control mapped to it scores as null, not zero and not satisfied. That single design decision is the reason this platform exists in the shape it does. The alternative, presenting a new customer with a framework already showing most requirements green before anything has been tested, is common in this category, and it produces a number that collapses the first time an auditor checks it.
The same rule applies everywhere. An uninstrumented service reports as uninstrumented. A skipped check reports as skipped. Empty is an honest state and we would rather show it than invent a figure that flatters you.
The things people ask us
What is a control graph?
A single structure linking statutory requirements to shared controls, controls to the checks that test them, and check results to readiness. Because the chain runs in that direction, readiness is computed from real test results rather than entered by hand, and one failing check moves compliance, risk and evidence at the same moment.
Do I have to buy all eleven engines?
No. You land on whichever one hurts today (a stuck enterprise deal, a SOC 2 request or a DPDP deadline) and expand from there. Because the controls are shared, each addition is mostly covered by controls you already operate, which is why the marginal cost of the second framework is far lower than the first.
How is this different from Vanta, Drata or Sprinto?
Two differences matter most. We run real security testing (SAST, SCA, DAST, IaC and secrets) inside your own pipeline rather than inferring posture from cloud configuration and questionnaires. And consent management, with a proof-of-consent ledger, is part of the same control graph rather than a separate tool bought and integrated on its own.
Is readiness ever pre-filled for a new customer?
Never. Every framework starts empty and a requirement with no control mapped to it scores as not modelled rather than as satisfied. A dashboard that shows a new customer thirty-four of forty-three requirements met on day one is describing nothing that was tested.
What makes the evidence ledger auditable?
It is append-only and hash-chained: each entry carries the hash of the one before it, so an altered or removed record breaks the chain detectably. Evidence is timestamped at collection, which is what lets you show a control was operating before an incident rather than after it.
Can we use the platform without deploying the SDK?
Yes, through the integrations and the API, though you lose the capabilities that depend on seeing your code: route and PII-flow instrumentation, the merge-blocking CI gate, and pipeline security testing. Those are the parts that distinguish evidence about your systems from evidence about your cloud account.