← Back to blog

Our compliance roadmap.

19 May 2026 · 8 min read

Most vendor compliance pages do a thing that is technically not lying. They list every standard the product touches in any way, mark each one with a green badge, and leave the reader to assume the green badges mean the same thing. They do not. The difference between holding a certification, operating a set of controls, mapping policies against a framework, and having engaged an auditor are four meaningfully different states. A procurement reviewer who lets those four states blur is signing a contract on the wrong evidence. We do not want our customers to be that reviewer.

This post is the long form of the Trust Center and the controls map. The short form is on those pages. The long form is here because procurement teams sometimes need to forward a single document that explains where we are, where we are going, and why we are not at the destination yet. This is that document.

The vocabulary, and what we will not say

Certified. An independent accredited body has audited the controls and issued a certificate with a validity window. Today we hold exactly one of these: Cyber Essentials, issued by IASME, valid 15 May 2026 through 15 May 2027, verifiable on the BlockMark Registry. The certificate ID is the public anchor.

Audited. An engagement letter exists, an audit window has started, and the auditor is collecting evidence. Today we hold none of these. We will not describe an audit as in progress until we have signed an engagement letter.

Operating. The controls exist in production, run today, and would survive an evidence-gathering visit. Today we have a controls pack operating against the SOC 2 Trust Services Criteria (TSC 2017 with the 2022 Points of Focus update) and a parallel mapping against ISO 27001:2022 Annex A. The controls are real; the attestation is not. We will not describe operating controls as audited.

Roadmap. Planned, with target dates, on a budget. The crypto audit, the SOC 2 examination, the ISO 27001 certification, the penetration test, and Cyber Essentials Plus are all on this list. None of them are operating or audited today.

This vocabulary is mechanical. It is the same vocabulary you will read on every page across the site, including the procurement pack. If we ever inflate a roadmap item to operating, or an operating item to audited, that is a bug; tell us at hello@deny.sh.

Why we held auditor outreach until after the engineering shipped

Drafting a SOC 2 controls pack the day a product is incorporated and engaging an auditor against it is a recognised playbook. It produces a polished controls document, monthly fees to a continuous-monitoring tool, and after a six-to-twelve month audit window, a Type II report. There is nothing wrong with that path. We chose a different path on purpose.

An auditor examines evidence. Evidence is produced by controls that are running against real traffic against real customers against real adversaries. A controls pack drafted before the controls exist in production is a document, not evidence. An auditor's findings against that document will be polite and useful and structurally weak. The auditor's job is to certify what is there; if what is there is mostly aspirational, the certification mostly certifies the aspiration. We did not want a certification of aspiration. We wanted a certification that the operating controls behind the deniability product survive an evidence-gathering visit.

So we built the six engineering controls first. Each one produces audit evidence by being run.

When the SOC 2 auditor arrives post-launch, those six controls are what they will examine. They will not have to take our word for any of it. The chain produces receipts. The dashboards expose state. The integrations are configured per tenant and write their own audit entries. The code is public at github.com/deny-sh-crypto. The reproducible builds and SRI manifest are at /verify. The evidence is the product.

The timeline

These dates are best-effort planning numbers. Engagement-letter dates depend on the auditor's calendar and our funding window opening on schedule. Audit-window starts depend on engagement letters. Report dates depend on the auditor. We publish all four states as they change.

What this means for your procurement team

If you are evaluating deny.sh today and your procurement gate is hard-blocked on a SOC 2 Type II report, we are not the right vendor for you yet. We will be in Q2 2027. Tell us anyway; we keep a list of buyers gated on attestation and notify you the day the report lands.

If your procurement gate is satisfied by Cyber Essentials Certified plus a strong operating-controls posture, with the named auditor and audit window on the public roadmap, we are usable today. Write to hello@deny.sh with the scope and your gating criteria, and we will return the procurement pack within five business days. The pack includes the SOC 2 controls documentation, the ISO 27001 Annex A mapping, the vulnerability management policy, the vendor list with locations and roles, the incident response runbook, the business continuity plan, and the data residency matrix per plan tier. The pack is shared under NDA. We do not pre-build it; the contents are tailored to the controls and jurisdictions in scope for your engagement.

If your procurement gate is somewhere in between, that is most procurement teams. The Trust Center is built for you. The controls map names every Trust Services Criterion against the control that evidences it, so your reviewer can paste lines straight into the internal vendor-risk tracker. If a control your reviewer cares about is not on the map, tell us; we will return the mapping. Most modern frameworks (HITRUST CSF, NIST CSF, CMMC, ENISA, ISMAP, IRAP) resolve to the same operational primitives the map already documents.

What we are deliberately not doing yet

Drata, Vanta, Secureframe. Continuous-monitoring SaaS tooling is on the roadmap, not on launch day. The tooling is genuinely useful once the auditor relationship is live; before the auditor exists, the tooling produces dashboards we cannot defend in front of an evidence-gathering visit. We will adopt continuous monitoring in Q3 2026 alongside the SOC 2 engagement letter, not before.

HIPAA business associate agreements, PCI DSS attestation, FedRAMP authorisation. None of these are in scope today. We are not marketed as a covered entity, a payment processor, or a US government cloud. If your use case requires one of these postures, tell us; we will scope a custom path.

A full-fat status page service with multi-region uptime tracking, per-component SLAs, and a status-changes RSS feed. On the post-launch roadmap. Today we run the lightweight /status page with a client-side health probe and the honest framing that says so.

A paid bug bounty programme. Coordinated disclosure is live at /disclosure with a published policy and GPG key. A bounty programme is post-launch on first paying-customer demand.

What we expect to be wrong about

The timeline above will move. Audit firms have queues. Crypto auditors specifically have queues that are months long, and we will not engage a firm that does not have the relevant cryptographic depth just to hit a date. The funding window for the audit budget is a function of post-launch traction, and post-launch traction is by definition not in our hands today. If a date slips, the Trust Center and the changelog will say so. We will not silently re-publish a later date over an earlier one; the prior date will be archived and the reason for the slip will be stated.

The framework versions will move too. SOC 2 is on TSC 2017 with the 2022 Points of Focus update today; if the AICPA ships a new version mid-engagement, we will state which version the controls were examined against. ISO 27001:2022 superseded ISO 27001:2013 and is the current version; any future revision lands on the controls map the same day we map against it.

The shape of the post-launch funding window depends on which customers find us first. An institutional inheritance-tier customer on a Q3 2026 procurement cycle is a different funding shape than a fleet of pro-tier developer pilots. The roadmap above assumes a mixed cohort; significant skew either way moves dates and may add or drop attestations.

A closing observation

The reason this post is long is that the alternative is a row of green badges that mean less than they look like they mean. We would rather be the vendor whose compliance page is honestly described as we hold one certification, we operate the controls behind two more, here is the roadmap, here is the evidence, here is when the auditor lands, than the vendor whose compliance page is decorated with attestations we have not earned. The first is a vendor a procurement team can defend in front of an internal review. The second is a vendor that becomes someone else's problem the first time an attestation is checked.

The launch is on Saturday 4 July 2026 at 08:00 BST. Until then, the Trust Center is the canonical view, the controls map is the procurement-grade index, and /status is the live operational read. If your compliance team would like a walkthrough before launch, tell us when you have an hour.

← More posts on the blog · deny.sh · Trust Center · Controls map