Skip to main content
Ankra is a delivery and management plane, not a hosting provider. Your clusters run on infrastructure you own or rent, in accounts you hold, under contracts you signed. Ankra provisions, configures and reconciles them - it does not host them and does not sit in the path of your production traffic. Your application data stays in your clusters, apart from the specific paths listed under Ankra is not in your data path. The exception is Ankra Cloud (closed beta): a cluster you run there sits on infrastructure the Ankra team operates, so for that cluster Ankra is also your hosting provider. That distinction is what keeps Ankra’s footprint in your compliance programme small, and it is the first thing to establish with an assessor.

​
The boundary

For fully self-hosted deployments the split shifts further toward you, because the control plane itself runs on your infrastructure. Talk to us about the on-premise specification if that is your requirement.

​
What this means for your certification

The common assumption is that adding a platform vendor drags a large new area into audit scope. For Ankra that is not the case, for three specific reasons.

​
Ankra is not your hosting sub-service organisation

Your cloud or hosting provider remains the sub-service organisation for infrastructure controls - physical security, environmental controls, hypervisor isolation, hardware disposal. Ankra does not replace them, does not sit underneath them, and does not inherit their control set. Adding Ankra does not change which infrastructure provider your assessor examines, and does not add a second one. The exception is a cluster on Ankra Cloud, where Ankra is the hosting provider for that cluster. Ankra enters your programme as a supplier providing a management service, assessed the same way you would assess a CI/CD vendor or an infrastructure-as-code tool.

​
Ankra is not in your data path

The agent is a control-plane client, not a proxy or sidecar. It does not terminate your application traffic, mount your application volumes, or connect to your databases, so your regulated data does not flow through Ankra in the normal course of things. Four paths can still surface it, which is why Agent Compliance rates this Conditional:
  • Pod logs and terminals - log views and terminal sessions show whatever your workloads print, and Ankra keeps a recording of each terminal session for 90 days.
  • Secrets in the console - anyone who can browse a cluster’s resources in Ankra can open a Secret there and read its values.
  • AI features - what the AI reads to answer a question is sent to the organisation’s model provider and kept in the chat transcript, with detected secret values redacted.
  • Backups - restore points carry volume and database contents, written to a backup vault bucket you own rather than to the platform.
Everything Ankra receives and keeps, with its retention, is listed in What leaves your cluster.

​
Ankra is not in your availability path

If the Ankra control plane is unreachable, your clusters keep running and keep serving traffic. Workloads are unaffected, the Kubernetes control plane is unaffected, and the agent buffers what it cannot send and replays it when the connection recovers. What pauses is reconciliation and platform visibility, not your service. This matters for availability-related criteria: an Ankra outage is a management outage, not a production one, and it does not belong in the same category as your hosting provider going down.

​
Where Ankra appears in your audit

Rather than a broad scope expansion, expect Ankra to surface at these specific points.
Most SOC 2 reports treat a management vendor like Ankra under the carve-out method - the vendor’s controls are excluded from the report and handled through vendor management instead. That is usually the right choice here, and it is the least work for you.

​
What Ankra does not do for your compliance

Being explicit about the limits is more useful than a long list of claims.
  • Ankra does not certify your environment. The platform produces evidence about your clusters. An assessor still decides whether your controls are effective.
  • Ankra does not make your workloads compliant. Application-layer controls, data handling inside your services, and your own SDLC remain yours.
  • Ankra does not replace your hosting provider’s attestations. You still collect those separately.
  • Ankra is not a substitute for your ISMS. The platform is one control among many, and the compliance report is input to your programme, not the programme itself.
  • Using Ankra does not by itself satisfy any control. It gives you the mechanism and the evidence; you still need the policy and the review cadence around them.

​
Ankra’s own security programme

Ankra runs its own information security management system, and the honest status of that work - certifications held, controls implemented, and what is still in progress - is published and kept current at ankra.ai/trust. Sub-processors and hosting providers are listed there too.
Do not treat this documentation as an attestation of Ankra’s certification status. Where your procurement process needs a current statement, take it from ankra.ai/trust or ask us directly - that page is the single source of truth and it changes as the programme progresses.

What Ankra Can See and Do

What leaves your cluster, where it is stored, and how to restrict it.

Agent Compliance Posture

Control-by-control scope determination for the cluster agent.

Roles & Access

The permission matrix for every built-in role.

Compliance Management

Generate the evidence an assessor asks for.