Skip to content

Preview Status & Roadmap

CloudTaser is in Preview. This page exists because the most common question from a serious procurement reviewer is: "When do I get SOC 2? When do I get a third-party pentest report? When do I get a reference customer I can call?" We will answer all three, in plain English, with dated milestones. If after reading this you decide CloudTaser is too early for your use case -- that is the right decision for some teams, and we'd rather you make it with facts than with marketing.

This page is the companion to the Sovereign Deployment Decision Guide and the Beacon Trust Model. Where those pages cover technical trust decisions, this page covers organisational trust -- what skipOPS Ltd has proven, and what it has not yet proven.

Current state — what we DO NOT have

As of 2026-04-21, CloudTaser has:

  • No SOC 2 Type I report. Not started.
  • No SOC 2 Type II report. Not started.
  • No published third-party penetration test report. Internal security review only.
  • No ISO 27001 certification. Not started.
  • No public production reference customers. We have design partners under NDA; none yet willing to be named publicly. (We're actively building that cohort -- tracked in cloudtaser-sales#52.)
  • No published uptime SLA for the skipOPS-operated beacon. Target is 99.9% with 3-node HA; historical uptime is not yet published.

This is a complete list. If you hear a CloudTaser-related claim that contradicts this list from any source, it is wrong. Treat this page as the single source of truth.

Current state — what we DO have

  • Open-source operator, wrapper, eBPF agent, bridge, beacon, and CLI. Auditable now by anyone, no NDA required.
  • Cosign-signed container images with SBOMs for every release.
  • Published protection score methodology.
  • Compliance mapping to GDPR, NIS2, DORA, Schrems II, German C5, French SecNumCloud, EU Data Act, Dutch DNB/BIO, PCI DSS 4.0.
  • Honest deployment guide that names silent-failure anti-patterns rather than hiding them.
  • Responsive disclosure: security issues filed via GitHub security advisories are acknowledged within 48 hours.
  • An engineering team that works in public: every PR, every CI run, every release is inspectable.

Audit & certification roadmap

The table below is the commitment, not a wish list. We will update it with actual dates and artifact links as each milestone lands. If a date slips, we will update this table and explain the slip.

Milestone Target Status Scope
Third-party security audit (narrow scope) Q2 2026 Planned eBPF agent + wrapper + beacon relay. Tier: NCC Group / Trail of Bits / Cure53.
Published pentest report (redacted) End of Q2 2026 Planned Report from the Q2 audit, redacted for customer confidentiality.
SOC 2 Type I readiness Q3 2026 Planned Scope defined, auditor engaged. Readiness = policies + controls operating, not yet audited for period.
SOC 2 Type II observation period begins Q4 2026 Planned 6-month observation window starts.
First named GA reference customer(s) 2027 Planned Design partner progression through production rollout + published reference rights.
SOC 2 Type II report (first audit period) Q2 2027 Planned Report covers Q4 2026 — Q1 2027 observation window.
Transparency report (lawful-intercept requests) End of 2026 (annual) Planned Following the Cloudflare / Mullvad model. See Beacon Trust Model.
ISO 27001 certification 2027+ Under consideration Scope and auditor TBD.
UK Cyber Essentials Plus 2026 Under consideration Lower-effort baseline cert while SOC 2 is in flight.

Why SOC 2 Type II takes until 2027

SOC 2 Type II requires a 6-month (minimum) observation window of controls operating in production. Even if we started the observation tomorrow, the report cannot land before that window closes plus auditor reporting time. The dates above are realistic, not pessimistic.

Why this order

We chose third-party audit → SOC 2 readiness → SOC 2 Type II rather than chasing SOC 2 first because:

  1. A narrow-scope security audit by a tier-one firm (NCC / ToB / Cure53) finds real bugs in the cryptography and eBPF paths. SOC 2 does not. For a product whose value proposition is cryptographic guarantee, the first thing to prove is that the cryptography and kernel enforcement actually hold.
  2. SOC 2 certifies that controls exist and operate. It does not certify that the product is secure. Leading with SOC 2 while a security audit is unfinished would be theatre.
  3. Once the audit report is public, SOC 2 readiness is mostly a policy-and-evidence exercise, which can run in parallel with scaling the design partner cohort.

What "audit" means here

"Third-party security audit" in the table above means: a paid engagement with a named, tier-one security firm, producing a written report, the redacted form of which is published to this repo and linked from this page. It is not a bug-bounty scan, not an internal review, and not a vendor-neutral compliance checklist exercise. The shortlist is NCC Group, Trail of Bits, Cure53, Doyensec, and Quarkslab. The chosen firm will be named on this page before work begins.

How customers can accelerate the roadmap

If you need CloudTaser before the roadmap dates above, the design partner program is the path. Design partners get:

  • Early access to pre-GA releases with direct engineering support.
  • Dedicated engineering hours for deployment assistance and custom integrations.
  • Locked-in pricing for GA, often at substantial discount.
  • Influence over feature priorities -- your production pain becomes our roadmap.
  • Reference rights in both directions: you can cite your use of CloudTaser; we can cite you (with per-announcement approval) when you consent.

In exchange, design partners agree to:

  • Be named as a reference customer once you're comfortable (case study, logo on website, optional quote).
  • Participate in quarterly security review calls.
  • Report material incidents and deployment friction so we can fix them before GA.
  • Accept that pre-GA means pre-GA -- bugs will happen, breaking changes are possible, and documentation will have gaps.

The program is selective. We are looking for EU enterprises (500-10K employees) with regulated workloads -- financial services, healthcare, government, regulated SaaS -- who understand that sovereign compute is a long-term architectural bet. If that describes you, reach out via cloudtaser.io and reference this page.

Should you deploy CloudTaser today?

An honest decision matrix. Pick the row that matches your situation:

Your situation Recommendation
You need a SOC 2 Type II-audited secrets platform TODAY for a procurement gate. CloudTaser is not it yet. Revisit post-Q2 2027. Talk to us anyway if you want influence over what GA looks like.
You're mandated to move off HashiCorp Vault (BSL / DPA issues) and have 6+ months to land the replacement. Design partner path. The core is production-ready, the audit and paper gap is your only blocker, and we can work that gap with you.
You run regulated workloads on US clouds and Schrems II supplementary measures are actively being audited against you. Design partner path. The cryptographic story is defensible today; the paper story catches up on the roadmap above.
You're building a greenfield platform and want to avoid the K8s Secrets exposure class from day one. Preview install is fine. Read the Sovereign Deployment Decision Guide first.
You have a narrow pilot scope (one cluster, one app, internal evaluation). Preview install is fine. Easy to undo (see Operational Readiness → backout).
You are a competitor or auditor looking at CloudTaser. The code is open, the security model is documented, the gaps are enumerated on this page. Have at it.

How this page gets updated

This page is versioned in git alongside the product. Every material change -- a milestone slipping, an audit starting, a reference customer saying yes -- produces a commit with a dated entry. The git log of docs/compliance/preview-status-and-roadmap.md IS the honesty record.

If you find this page out of date, file an issue at cloudtaser-docs. If you find it misleading, file a security advisory instead -- misleading security posture is a security bug.

For detailed phase deliverables, see Validation & Testing Roadmap.