Auditors do not certify a platform. They certify the environment you build on it — your systems, your processes, your evidence. So the useful question is never “is the platform compliant”, it is “which controls does this platform give me, which do I have to switch on, and which stay mine”.
These pages answer that one framework at a time, for the three Ænix platforms and for Cozystack underneath them. Each separates what is enforced on a fresh installation, what ships but is off until you enable it, and what no infrastructure product can do for you.
Where these numbers come from
Every measured result in this section — the kube-bench run, the conformance runs, the verification commands — was produced against Cozystack, the open-source engine, on a reference cluster. Not against a separate proprietary Ænix build.
That is deliberate, and it is the reason the results transfer:
- There is no separate engine. The Ænix Public Cloud Platform, Ænix Private Cloud Platform and Ænix AI Platform are distributions of Cozystack. Ænix creates and maintains Cozystack — it is a CNCF project under Apache 2.0 — and the platforms ship the same releases. Nothing is forked away and re-tested behind a licence.
- So the mapping is one-to-one. A control that passes on Cozystack passes on a platform built from it. A deviation on Cozystack is a deviation on the platform. There is no gap for a marketing claim to hide in.
- What Ænix adds sits around the engine, not inside it. The Talos machine configuration applied at install time, the reference architecture, the operational runbooks, and support during the assessment. Several of the settings these pages discuss —
--encryption-provider-config, the audit policy, the authorization configuration, the time source — come from that machine configuration rather than from Cozystack itself. Where that is the case, the page says so and tells you how to verify it on your own cluster. - Which is also why your numbers may differ. The same benchmark on your installation is a different run. Treat the published figures as a reference point and a method, not as a certificate covering your environment.
The alternative framing — publishing these as results for a proprietary product — would be a claim we could not evidence and an assessor could not verify. The source is public; the manifests are on the pages.
Frameworks
- PCI DSS — a requirement-by-requirement mapping of all twelve PCI DSS v4.0.1 requirements: what is active by default, what is one setting away, what stays with you, with commands to verify each control on your own cluster.
- GDPR — the Article 32 technical measures the platform supplies, where personal data physically sits, and the parts of the right to erasure that infrastructure cannot settle.
- CIS Kubernetes Benchmark — the full kube-bench run: 54 pass, 24 fail, 53 warn, with every failure sorted into a real deviation, a control met another way, or a check that does not apply on an immutable node.
- DORA — the platform-side evidence for resilience, backup and restore, incident records and the ICT third-party risk chapter, where self-hosted open source changes the answer.
- Kubernetes conformance — CNCF conformance results for both shapes the platform is used in: self-hosted tenant clusters passing in full across five Kubernetes releases, two of them listed in the CNCF’s own record, and a hosted platform listed there as well. What a listing covers, and what it does not, is spelled out.
What we do not claim
Precision here is worth more than reassurance, because an assessor will test every sentence.
| Claim we do not make | What is true instead |
|---|---|
| “Ænix is ISO 27001 certified” | Aenix holds no ISO 27001 certificate. The platforms are built to support an ISMS — audit logging, access control, change control through declarative configuration — and Ænix supports customers’ certification work. That is a different claim. |
| “Ænix is SOC 2 attested” | There is no SOC 2 report. Where a customer needs one for their own service running on the platform, the platform supplies control evidence; the report is theirs. |
| “The platform is PCI DSS certified” | No platform is. A Qualified Security Assessor certifies a scoped cardholder data environment. The platform supplies the technical controls the assessment leans on. |
| “The platform is GDPR compliant” | Compliance belongs to the controller. The platform supplies Article 32 measures and makes them demonstrable. |
| “The platform is CIS certified” | The CIS Benchmark awards no verdict. It is a list of controls, and compliance is a judgment about a specific cluster. |
| “The platform is DORA compliant” | DORA binds financial entities, not platforms. The platform is part of the ICT estate those entities manage. |
The regulatory engagements
The pages above are evidence. If what you need is the programme around it — a gap analysis, a control-level map of what you can demonstrate today, a remediation plan — those live under solutions:
- DORA compliance — fixed-price readiness engagement for financial entities and the ICT third parties serving them: ICT third-party risk, concentration risk, exit-feasibility, resilience testing. Free DORA compliance checklist.
- NIS2 compliance — the equivalent for essential and important entities under NIS2. Free NIS2 compliance checklist.
- Data sovereignty — customer-controlled keys, customer-controlled hardware, jurisdictional residency.
The split is deliberate: the solution pages answer “what does the regulation require of us and where are we short”, these pages answer “what does the infrastructure actually do, and how was that measured”.
Reproduce it before you cite it
Nothing in this section requires trust. Cozystack is Apache 2.0 and its source, security advisories and release changelogs are public at cozystack.io. The kube-bench job manifest, the Sonobuoy invocation and the isolation probes are published on the pages that use them, with pinned tool versions, because an unpinned tool is not evidence.
If you want the control mapping reviewed against your own scope before an assessment, that is what enterprise support and the platform readiness assessment are for.
Notes
This section describes Cozystack v1.6 and v1.6.1 as observed on reference clusters in August 2026, and the Ænix platforms built from those releases. It is informational: not legal advice, not an assessment, not a certification, and not a warranty that any configuration will satisfy an assessor or a supervisory authority. Your installation may differ, particularly in the Talos machine configuration.