Authorization is one of the harder things to bring into a stack from outside, and security teams are right to treat it that way. It sits directly in the access-decision path. Anything that decides who can do what to which resource is, by definition, in a position to see sensitive context and to get access wrong at scale. So when a new authorization component lands on your desk for review, the questions are the obvious ones. What data does it touch. Where does that data live. What leaves our network. What is it certified against. And can we prove all of that to an auditor later.
This piece answers those questions for Cerbos in one place. The short version is that the architecture is built so most of the answers point the same way, your data stays inside your own perimeter, and the parts that do cross a boundary are limited and controllable.
Why the architecture makes the review straightforward
Most of the friction in assessing an authorization tool comes from not knowing where the sensitive data ends up. With Cerbos, the answer is that it mostly does not go anywhere.
The Cerbos PDP is the engine that makes decisions, and it runs inside your infrastructure, as a container, a sidecar, a serverless function, or at the edge. It is stateless. It decides based only on the data your application passes into a request, and it does not persist that data afterward. In the words of the docs, Cerbos instances and the data they process remain strictly inside your network perimeter. There is no call out to a Cerbos service to make a decision, so there is no path by which your users, resources, or attributes are sent to us during authorization.
That single design choice removes a large share of what a security review usually digs for. The decision path has no external dependency, so the questions about third-party data processing, cross-border transfer at request time, and vendor availability in the critical path mostly answer themselves.
What data Cerbos sees, stores, and never receives
During a decision, the PDP sees the principal, the action, the resource, and whatever attributes your application chose to include. It uses them to evaluate your policies and return an allow or deny. It does not write that request to a Cerbos-owned store, and it does not need an account or a license to run.
If you adopt Cerbos Hub, the Policy Administration Point, two things move across the boundary, and both are limited by design. Encrypted policy bundles come down to your PDPs, and if you turn on audit log collection, decision logs go up. For the logs, you can define masks so that sensitive or personally identifiable fields are stripped locally at the PDP and are never transmitted to Cerbos Hub. You decide what a log entry is allowed to contain before it ever leaves your environment.
For teams that do not want decision data leaving at all, the on-premises option keeps everything in your infrastructure, including the audit log store, which runs as a ClickHouse instance you own. You control residency, retention, and access to it.
Deployment isolation, from fully self-hosted to air-gapped
There are three postures, and you can pick the one your risk profile calls for.
Run the open source PDP on its own and there is no vendor in your decision path at all. You self-host the engine, load policies from your Git repo or filesystem, and nothing connects out. This is the model teams in the most restricted environments start from.
Add Cerbos Hub as a managed control plane and you get centralized authoring, testing, distribution, and audit, while the PDPs and their data stay in your network. The connection a PDP makes to Hub is authenticated, and the policy bundles it receives are encrypted. Nothing about Hub sits in the live request path, so if Hub is ever unreachable, your PDPs keep serving the last bundle they received and authorization keeps working. Hub is not a single point of failure for your access decisions.
For the most regulated environments, Cerbos Hub runs on premises in your own infrastructure, including air-gapped and restricted networks. You keep the full control plane, policy stores, testing, bundle distribution, audit collection, and user management, without any dependency on a hosted service. This is the deployment for teams that need data residency and full control end to end.
Certifications and the compliance frameworks Cerbos supports
Cerbos holds a SOC 2 certification, and its audit logging gives a security or procurement team the evidence a vendor assessment asks for. The current SOC 2 report and related security documents sit in the Trust Center covered below.
Beyond the company's own certifications, the audit logging is built so your use of Cerbos supports your compliance too. Every decision produces a structured record of who, what, when, and which policy, and that history is audit-ready for SOC 2, ISO 27001, HIPAA, GDPR, NIS2, DORA, and FedRAMP. When an auditor asks you to show who could access a given resource and why, the answer is a query rather than a reconstruction project.
Penetration testing and the Cerbos Trust Center
Cerbos is tested by third parties, and the current penetration test reports, security policies, and certification documents are available in the Cerbos Trust Center. Rather than restating point-in-time results in a blog post, which go stale, the Trust Center is the single source that stays current, and you can request access to the documents your assessment needs.
If your team is running Cerbos through a formal review, that is the fastest path. Request access, pull the reports and attestations, and send over any questionnaire that the documents do not already answer.
What to hand your security team
If you are the one assembling the assessment, most of it comes down to a few points you can now state plainly. The engine runs in your infrastructure and your data stays there. Only encrypted policy bundles and, optionally, locally masked decision logs cross the boundary, and on premises even that stays inside your network. The current certifications and penetration test reports are in the Trust Center. And the audit trail your policies produce is structured for the frameworks you already report against.
That is usually enough to move an authorization component from open question to approved, without the review becoming its own project.
Request the certifications and reports your assessment needs from the Cerbos Trust Center, or talk to the team to walk through your specific security and deployment requirements.
Explore:
- A CISO's benchmark for authorization maturity (eBook) for a way to gauge how mature your authorization program actually is
FAQ
Tagged in
