---
title: "Cerbos security and trust: Data handling, certifications, and deployment isolation"
description: "How Cerbos handles your data, where it lives, and what leaves your network. A security and trust overview for CISOs and security teams evaluating Cerbos, covering the stateless PDP, deployment isolation, local field masking, certifications, penetration testing, and the Cerbos Trust Center."
author: "Emre Baran"
date: "2026-08-06T11:26:00.000Z"
canonical: "https://www.cerbos.dev/blog/cerbos-security-and-trust"
image: "https://stylish-appliance-1c1cc1c30d.media.strapiapp.com/Cerbos_security_and_trust_Data_handling_certifications_and_deployment_isolation_5093dddbd5.png"
tags: ["guide"]
source: "https://www.cerbos.dev/blog/cerbos-security-and-trust"
---

# Cerbos security and trust: Data handling, certifications, and deployment isolation

Authorization is one of the harder things to bring into a stack from outside, and [security teams](https://www.cerbos.dev/for-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](https://docs.cerbos.dev/cerbos/latest/) 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](https://docs.cerbos.dev/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](https://www.cerbos.dev/features-benefits-and-use-cases/self-hosted-authorization) keeps everything in your infrastructure, including the [audit log](https://www.cerbos.dev/blog/why-audit-logs-are-important) 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](https://www.cerbos.dev/blog/cerbos-hub-now-available-on-premise) 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](https://www.cerbos.dev/blog/benefits-of-on-premise-authorization) 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](https://www.cerbos.dev/blog/how-does-cerbos-help-with-compliance-audits-and-certifications) 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](https://trust.cerbos.dev/). 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](https://trust.cerbos.dev/), or [talk to the team](https://www.cerbos.dev/workshop) to walk through your specific security and deployment requirements.

Explore:

* [A CISO's benchmark for authorization maturity](https://solutions.cerbos.dev/authorization-maturity-model-a-cisos-benchmark) (eBook) for a way to gauge how mature your authorization program actually is

## FAQ

### Does Cerbos store or see my data?

Cerbos does not store your data. The Cerbos PDP runs inside your own infrastructure and is stateless, so it makes each authorization decision using only the data your application passes in the request, and it does not persist that data or send it to a Cerbos service. Cerbos instances and the data they process stay strictly inside your network perimeter.

### Is Cerbos SOC 2 compliant?

Yes, Cerbos holds a SOC 2 certification. The current SOC 2 report is available to request through the Cerbos Trust Center at trust.cerbos.dev, which is the source security and procurement teams use during a vendor assessment. The audit logging is also built to give you the evidence your own audits need, whatever frameworks you report against.

### What data leaves my network when I use Cerbos Hub?

When you use Cerbos Hub, two limited things cross the boundary. Encrypted policy bundles are sent down to your PDPs, and if you enable audit log collection, decision logs are sent up. You can mask sensitive or personally identifiable fields locally at the PDP so they are never transmitted to Cerbos Hub, and with the on-premises deployment the audit logs stay in a ClickHouse store inside your own infrastructure.

### Can Cerbos run air-gapped or on-premise?

Yes, Cerbos can run air-gapped and on-premise. The open source PDP self-hosts with no connection out at all, and Cerbos Hub is available as an on-premises deployment for enterprise customers that need data residency or operate in air-gapped and restricted networks. In that model the full control plane, including policy distribution and audit collection, runs inside your own infrastructure.

### Is Cerbos penetration tested?

Yes, Cerbos is penetration tested by third parties, and the current penetration test reports are made available in the Cerbos Trust Center rather than published in a blog post, so the information stays current. Security teams can request access to the reports and certification documents they need for a vendor assessment.

### Does using Cerbos Hub put a vendor in my authorization request path?

No, Cerbos Hub does not sit in your authorization request path. Authorization decisions are made locally by the PDP running in your infrastructure, and Hub is a control plane for authoring, distributing, and auditing policy. If Cerbos Hub is ever unreachable, your PDPs keep serving the last policy bundle they received, so access decisions continue without interruption.