How Zitadel supports SOC 2 CC6 logical access controls
This section explains how a self-hosted Zitadel deployment supports the three logical access criteria in SOC 2 CC6: CC6.1, CC6.2 and CC6.3. DeployOpen prepares the systems, controls and evidence for those criteria, but it does not issue SOC 2 reports, attestations or certifications. CC6.1 covers the security software, infrastructure and architectures that protect information assets. CC6.2 covers registering and authorizing users before credentials are issued and removing credentials once access is no longer authorized. CC6.3 covers granting, changing and removing access based on roles, responsibilities or system design, with least privilege and segregation of duties in mind.
SOC 2 examinations use the AICPA's 2017 Trust Services Criteria. Security is the category that carries CC6, and the common criteria CC1 to CC9 apply to every SOC 2, whatever other categories are in scope. Whether your controls are effective is the auditor's decision. In a Type 2 examination, that decision rests on evidence gathered over a period, and neither Zitadel nor DeployOpen makes it. Zitadel's SOC 2 Type II listing on its pricing page covers Zitadel's own operations. It does not cover your self-hosted system, your configuration, your user population or your access reviews, which your organization must describe and evidence itself.
For CC6.1 and CC6.2, the design starts with how tenants are structured. Zitadel separates instances, organizations and projects, and your team should decide which of these maps to each business unit, customer or environment before any users are created. For registration and deprovisioning, Zitadel provides a SCIM v2 service provider interface. Decide which authoritative system, such as an HR platform or directory, triggers joiner and leaver events, and confirm with the vendor how SCIM deprovisioning behaves in the version you deploy. Then test a leaver end to end and keep the test record as evidence that credentials stop working when access ends.
For CC6.3, project roles and grants are the main lever. Give administrators of the Zitadel console separate roles from the roles that applications use, and grant application roles only to the users and groups that need them. Passkeys are supported with fallback to password login, so decide whether that fallback is allowed for privileged roles, and confirm the multi-factor enforcement settings available in your version. Finally, confirm which administrative and authentication events the audit trail records, how long they are retained, and whether they can be exported to your log platform, because periodic access reviews depend on that record.
Zitadel SOC 2 requirement map for CC6.1, CC6.2 and CC6.3
This table maps each SOC 2 CC6 point to the Zitadel capability that supports it, the setting the customer must configure, and the team that owns the control. Items marked to confirm need checking in the Zitadel documentation or a test instance before you rely on them. The main takeaway is that Zitadel provides the mechanisms, while your policies and periodic reviews produce the evidence an auditor will sample.
| Requirement | Zitadel capability | Customer configuration | Control owner |
|---|---|---|---|
| CC6.1 Logical access security for information assets | Self-hosted instances with organizations and projects that keep tenant data isolated | Deploy in your infrastructure on PostgreSQL 14 to 18, with database access limited to the Zitadel service | Platform or infrastructure team |
| CC6.2 Register and authorize new users | Organizations that hold users, with federated identity providers for each customer or workforce group | Map each group to its organization and approved identity provider before granting any access | Identity administrators, with approval from the application owner |
| CC6.2 Create credentials after authorization | Passkeys based on FIDO2 and WebAuthn, with password login as fallback | Make passkeys the preferred method and set fallback rules per user population; confirm fallback limits | Security policy owner and identity administrators |
| CC6.2 Remove credentials when access ends | SCIM v2 provisioning and deprovisioning from the source system of record | Connect HR or directory to the SCIM v2 endpoint and test a leaver end to end in a test instance | HR operations with identity administration |
| CC6.2 Review credential appropriateness | Users, roles and grants viewable through the Console and management APIs | Run scheduled access reviews and export user and grant lists as dated evidence | Access review owner for each application |
| CC6.2 Block invalid credentials | To confirm: how disabled users and revoked tokens are enforced on OIDC and OAuth 2.0 endpoints | Test that a disabled user cannot obtain new tokens before go-live and record the result | Identity operations |
| CC6.3 Least privilege through roles | Projects with roles and grants for each application | Define roles per application and grant the smallest set each user group needs | Application owner approves; identity team applies |
| CC6.3 Segregation of duties | Separate projects and organizations for administrative and business functions | Keep administrator and business-user roles apart; confirm how instance administrators can be separated | Security governance and IT leadership |
| Enforced MFA and audit evidence | To confirm: enforced second-factor policy and an exportable audit log in the product documentation | Require a second factor for privileged roles and confirm log export in a test instance | Security operations |
How SCIM and organizations shape CC6.2 registration and removal
CC6.2 asks the organization to register and authorize new internal and external users before it issues credentials or grants access, and to remove credentials once access is no longer authorized. In a self-hosted Zitadel deployment, the first decision is which system is the source of truth for joiners and leavers. If an HR system or directory drives Zitadel through its SCIM v2 service provider interface, Zitadel user records follow that upstream decision, and the control depends on that upstream process being accurate. If administrators create users by hand in the console, registration is documented by people rather than by the provisioning pipeline, and the review workload grows. Confirm with your identity provider exactly which SCIM operations it sends (create, update, deactivate and delete), and how it represents a suspended user. Those behaviors vary by provider, and Zitadel's SCIM documentation does not replace that check.
Instances, organizations and projects determine where a provisioned user can land and what that user can reach. An instance is a virtual tenant with full data isolation, so it is the boundary to choose when workforce and customer identities must never share a user store. Inside an instance, organizations hold users, and projects group applications, roles and grants. A common design for a workforce places staff in one internal organization, with projects that grant them roles, while customer users sit in separate organizations. Each organization can federate to a different identity provider, so the feed or directory that governs one customer should be treated as separate from the others. Map which organization each SCIM feed writes to, and test that a feed cannot create or modify users in an organization it was not meant to reach. Keep role grants reviewable per project so that an access review can answer who holds which role.
Removal is where most gaps appear. Deactivating a user upstream must lead to Zitadel blocking that user from signing in, but that step alone does not close the control. Applications that issue their own sessions, keep long-lived refresh tokens or maintain local accounts can keep working after the identity record is disabled. Build an end-to-end test that starts with an active user holding sessions in each relevant application. Deactivate the user upstream, then check that new logins fail, that existing application sessions end or expire within the lifetime you have configured, that API tokens are rejected where the application validates them, and that any local accounts are removed or added to an inventory with an owner. Store the test record as evidence. Token and session lifetimes are configuration choices in your deployment, so confirm the values in your environment rather than assuming them.
Plan the evidence before the review period starts. Auditors typically sample joiners and leavers and ask for proof that each removal happened within the period. For each sampled person, keep the upstream request or HR event, the SCIM provisioning record from the identity source, the matching entry in the Zitadel audit trail and the result of the end-to-end removal test that covers that person's applications. Ask your SOC 2 auditor early which population, period and evidence format they expect, because the points of focus under CC6.2 are guidance and the auditor decides what is sufficient. DeployOpen can prepare these controls, the test scripts and the evidence set, but the independent auditor issues the opinion. Effort depends mainly on the number of identity sources and applications in scope, so confirm that inventory before estimating the work.
Zitadel SOC 2 evidence for access reviews
An auditor testing CC6.2 and CC6.3 will ask for proof that users were authorized before access was granted, that roles matched responsibilities, and that access was reviewed and removed when it was no longer needed. The cards below list the records that answer those questions, where each one originates in a self-hosted Zitadel deployment, and how to capture and keep it so the evidence is complete when the audit window closes.
Approved user registration records
CC6.2 expects new internal and external users to be registered and authorized before credentials are issued. Keep a record for each user that links the approval to the request, the approver and the date the account was created in Zitadel. Take the creation timestamp from Zitadel's user records and match it to the approval in your ticketing system, then check that no account exists without a matching approval. Confirm which user events your deployment exposes and how long they are retained.
Identity provider configuration snapshots
When Zitadel federates login to an external identity provider, the provider configuration determines who can sign in and how. Export the identity provider settings for each customer organization on a schedule, and store each export with its change history. Auditors will compare these snapshots with the approved configuration, so flag any change to the trusted issuer, claim mapping or auto-provisioning setting for review. Record who made each change.
Role and grant definitions per project
CC6.3 requires access to follow roles, responsibilities and least privilege. Zitadel groups roles and grants under projects, so export the role keys and the user grants for each project in a consistent format. Compare the export against the approved role model to find grants that exceed a job function or that break a segregation of duties rule. Keep dated exports so you can show how a role's permissions looked during the period under review.
Provisioning and deprovisioning event samples
Auditors commonly select a sample of joiners, movers and leavers and trace each one to a request and to a system change. For Zitadel, pull the SCIM v2 provisioning and deprovisioning activity for the sample and match it to the originating HR or ticket record. Check that removals happened within the time your access policy sets. Confirm with your deployment whether SCIM activity is logged, where those logs are stored and how long they are kept.
MFA policy settings
Access controls that depend on multi-factor authentication need evidence that the policy was in force during the audit period. Export the login policy settings for each instance and organization, including whether MFA is required, which factors are allowed and whether passkeys or password fallback are permitted. Store the export with a timestamp and the approver of any change. Compare the policy history against the control description you give the auditor so that gaps are found before fieldwork.
Signed periodic access review records
Access reviews show that owners checked who had access to their systems and acted on exceptions. Keep a dated review for each project and organization, listing the users and grants reviewed, the owner's signature or approval, and the removals that followed. Use Zitadel exports as the population for each review so the reviewer sees the actual state. Store the signed records with the exports they relied on, and agree with your auditor in advance how often reviews must occur.
What a Zitadel SOC 2 access control setup involves
This sequence turns a self-hosted Zitadel instance into a documented set of access controls that map to CC6.1 through CC6.3. Each step ends with an artifact an auditor can inspect, from the system description to the access review records.
Confirm scope and system description with the auditor
Before any configuration, the organization and its SOC 2 auditor agree which Trust Services Criteria categories are in scope and where the system boundary sits. The Zitadel team, security lead and auditor list every instance, identity source, application and administrator group that falls inside that boundary. Management then drafts the system description that CC6.1 controls will be measured against. This step is done when the auditor confirms the scope in writing and the boundary list matches the planned deployment. The artifacts are the agreed scope statement and the draft system description.
Deploy the self-hosted instance for high availability
The platform team deploys Zitadel on infrastructure the organization controls and connects it to a supported PostgreSQL version from 14 through 18. Zitadel recommends a Kubernetes cluster with the official Helm chart for high availability, so the chart is used for the production topology. The team records the PostgreSQL version, chart version, replica layout, TLS termination and backup approach. This supports CC6.1, because the access control software and its architecture are documented. The step closes with a reviewed architecture diagram and a deployment record that names the exact versions in use.
Structure instances, organizations and projects
The team maps the system boundary onto Zitadel's tenancy model. Instances provide full data isolation between virtual tenants, organizations hold users and projects, and projects group applications, roles and grants. A common pattern is to align each organization with a customer, business unit or environment that has its own access owner, then keep the number of instances as small as the isolation need allows. This structure supports CC6.3 because ownership of each protected asset is visible from the tenancy model. The artifact is a boundary map that links every instance, organization and project to an owner and to the in-scope system.
Connect the authoritative identity source
The identity team connects the system of record for workforce or customer users to Zitadel, then adds federated providers such as Entra ID, Okta, LDAP or another OIDC or SAML source as the boundary requires. Each customer organization can use a different identity provider, so the mapping is recorded per organization. CC6.2 requires that new users be registered and authorized before credentials are issued, so the authoritative source must be the place where that approval happens. The step is complete when a test user can sign in only through the approved source and the identity provider register lists every connection with its owner.
Configure SCIM provisioning and deprovisioning
The team configures the SCIM v2 service provider interface so that user creation, attribute changes and deactivation flow automatically from the authoritative source. Deprovisioning is the control that matters most for CC6.2, because credentials must be removed once access is no longer authorized. The team tests a full lifecycle with a non-production account: create, change a role-relevant attribute, deactivate, then confirm sign-in fails and sessions end. Ask the vendor or your own testing to confirm exactly how the version in use handles deactivation and token revocation. The artifact is a dated test log showing each lifecycle event and its result.
Define project roles and grants by least privilege
Access owners define the project roles that match the job functions in the system description, then grant each role only the applications and actions it needs. Administrative roles are kept separate from operational roles so that no single person can both approve and execute a privileged change, which supports the segregation of duties considered under CC6.3. Each grant is tied to an owner and a business reason. The team then checks that users inherit roles only through the approved provisioning path. The artifacts are a role and grant matrix and a segregation review signed by the control owner.
Set passkey, password and MFA requirements
The security team sets authentication policy for each organization: passkeys based on FIDO2 and WebAuthn where the user population can use them, password login as a fallback, and MFA requirements that apply to every sign-in path. Zitadel documents passkey login with fallback to password, but the exact enforcement options, lockout behavior and MFA scope depend on the version in use, so the team confirms each setting with the vendor documentation and tests it. CC6.1 and CC6.2 both depend on this step, since weak sign-in paths undermine every other control. The artifact is an exported policy configuration plus test records showing that MFA cannot be bypassed.
Schedule access reviews and capture evidence
The control owner schedules recurring access reviews for each organization and project, with a named reviewer who compares current users, roles and grants against the approved access list. Each review records who was reviewed, what was removed or changed, and when the removals took effect. The team also confirms which audit events Zitadel records for the version in use, where they are stored, how long they are retained and how they are exported to the evidence repository. Auditors will sample these records for CC6.2 and CC6.3 over the examination period, so the step is complete when a sample review can be reproduced from stored evidence.
How to prove an access review ran in a SOC 2 Type 2 period
A Type 2 report tests whether controls operated across the observation period, so an access review has to be shown as having run on schedule during that window, not just as a documented procedure. A Type 1 report covers the system description and whether controls were suitably designed as of a single date. A review that exists only as a written process, or one run once shortly before fieldwork, may support a Type 1 discussion but leaves a gap for Type 2. Ask your auditor early for the observation period length and the sampling approach. Both are the auditor's decisions, and they determine how many review cycles you must evidence and how many individual decisions will be pulled for testing.
Each review cycle needs a record that stands on its own. Define the scope as the Zitadel instances, organizations and projects in view, and capture the roles and grants in effect at the moment of the snapshot. Store that export with a timestamp and a hash in your evidence system. Name the reviewer as a project or application owner, and keep that person separate from the administrator who produced the export. Each decision (keep, change or remove) needs a reason and a date. For every removal, keep a follow-up record showing when the grant was revoked in Zitadel and, where SCIM provisioning is in use, when the downstream account was deprovisioned. Confirm which fields your Zitadel version writes to its audit events and API responses, and whether reviewers record decisions inside the platform or in a separate tool.
Every grant, role change and deprovisioning event in the window should trace to an approved ticket. Pull the change events for the full period and join them to tickets using user identifier, grant identifier and approver. Any change without a matching ticket is an exception and needs a documented explanation and a remediation record. Pay particular attention to SCIM-driven changes. Provisioning from an upstream directory or HR system can create or alter grants with no Zitadel-side request, so the ticket reference has to sit in the upstream request or the directory change record. Decide before the period starts which system is the source of approval. Also confirm that roles map to job function, reflect least privilege and keep requesting and approving duties apart, as CC6.3 expects.
Management's description of the system, prepared against the DC 200 description criteria, should state Zitadel's role precisely. In a self-hosted deployment, the description should say the client operates Zitadel in its own infrastructure, names the PostgreSQL database and its version, and explains how backups and administrator access are controlled. It should identify Zitadel as the authorization source for projects, roles and grants, while the upstream directory or HR system owns joiner and leaver events, the ticketing system owns approvals, and the evidence store holds the review exports. Do not describe Zitadel as performing the review or as providing assurance. Management supplies written representations, and the auditor forms the opinion. Confirm with your auditor how upgrades during the period should be described, and document any Zitadel version change as a change event within the window.
What Zitadel does not cover for SOC 2 access controls
Zitadel supplies technical controls for SOC 2 logical access, but several CC6 requirements depend on your people, policies and infrastructure. The six gaps below sit outside the platform, and each needs a named owner who can produce evidence for them before an examination.
Joiner, mover and leaver process
Zitadel can deprovision accounts through SCIM v2 when a source system changes, but it cannot decide when someone should join, change role or leave. HR policy, the written joiner, mover and leaver procedure and the link from HR records to your identity source belong to HR and IT. Check that leaver events reach Zitadel within the window your policy sets, and keep the timestamps as evidence for credential removal under CC6.2.
Access approval authority
Zitadel stores projects, roles and grants, but it does not decide who should hold them. Name an approver for each project and role, and record approvals in your access request or ticketing system if the platform does not hold them. This owner is accountable for registration and authorization under CC6.2 and for role-based grants under CC6.3. Privileged roles should also need security sign-off.
Privileged operator access and monitoring
Anyone with administrative access to the Zitadel instance, its database, the Kubernetes namespace or the Helm release can change users, grants and configuration. Keep operator accounts separate from everyday accounts, review who holds them on a fixed schedule, and forward operator and API activity to your own log store, where security operations reviews alerts. Owner: platform engineering with security operations.
Database backup and restore testing
Zitadel keeps its state in PostgreSQL, with versions 14 through 18 supported. Backups of that database, along with the encryption keys and configuration needed to use them, are the platform team's responsibility. An untested backup gives no assurance of recovery, so schedule restore tests into a separate environment and record the results. Owner: platform team or database administrators.
Configuration change management
Changes to instance settings, identity provider connections, login policies, role definitions and Helm values all alter who can access what. Route them through the same review and approval path as application code, keep them in version control where your deployment method allows, and link each change to a ticket. Owner: the engineering lead, working through your change advisory process.
Vendor risk and licence review
From v3.0 onward, Zitadel's core, Console and hosted login are licensed under AGPL 3.0, announced on 31 March 2025, while APIs, SDKs, Helm charts and Terraform configurations remain Apache 2.0. Legal should review what AGPL 3.0 requires if you modify these components or offer them to users over a network. Procurement should also assess each federated identity source, such as Entra ID, Okta or LDAP directories, because its outages and access decisions affect your SOC 2 scope.
Zitadel SOC 2 questions buyers ask before hiring help
Does using Zitadel make my company SOC 2 compliant?
No. SOC 2 applies to the organization and the system it describes, not to a product. Zitadel can support controls such as provisioning, deprovisioning, forced MFA and access logging under CC6.1 to CC6.3, but the organization still has to define its system boundary, write and operate its procedures, and keep evidence over time. An independent CPA firm performs the examination and issues any report. DeployOpen prepares the deployment, configuration, control documentation and evidence collection for that examination, but it does not issue audit reports, attestations or certifications. Ask any partner, including us, to state this in writing in the scope.
Zitadel's own pricing page lists SOC 2 Type II and ISO 27001 for Zitadel as a vendor. That describes the vendor's own controls, not your environment.
What drives the cost of SOC 2 access control work?
Cost depends on the work in scope, not on a fixed package. The main drivers are the number of systems in scope, the number and type of identity sources (for example, Entra ID, Okta, LDAP or existing directories), the custom integrations that feed users, roles or logs into Zitadel, how much evidence collection you want automated, the length of the observation period, and auditor fees, which the CPA firm sets and which DeployOpen does not control.
One-time costs usually include design, configuration, integration, documentation and the readiness review. Recurring costs include hosting, Zitadel licensing or support if you choose it, access reviews and retainers. DeployOpen does not publish a price list. Ask for a written scope that lists each system, identity source and integration, and separates one-time from recurring items.
How long does a Zitadel SOC 2 access control project take?
It depends on scope and readiness. A deployment with few systems, clean identity sources and existing policies will take far less time than one that must reconcile several directories, rebuild role models and collect evidence for a period of operation. Your SOC 2 timeline is also set by the audit period: a Type 2 report needs controls to operate over a period, so the access controls must be running well before the examination window starts. DeployOpen will give a timeline in the written scope once the systems, identity sources and readiness gaps are known. No duration is promised before that review.
What does my team need to provide for this work?
Expect to provide named owners, access to the systems in scope, a current inventory of applications and identity sources, your existing access and onboarding procedures, and decisions on role design. Someone must approve who can grant access, who performs access reviews and how terminations are handled. Your HR or IT team needs to confirm the source of truth for joiners and leavers, since SCIM provisioning and deprovisioning only work as well as that data.
You also need to keep the evidence. The audit trail, review records and change approvals belong to your organization and must be retained according to the auditor's requests.
Can our internal team implement SOC 2 access controls without a partner?
Yes, if you have engineers who can operate Zitadel, understand CC6.1 to CC6.3 and can run the procedures every day. Many teams do this in-house. The usual gaps are not technical: they are unclear ownership, incomplete identity inventories, access reviews that are not performed on schedule, and evidence that is hard to pull together at audit time. A partner adds the most value when those gaps need to be closed quickly or when several systems must be mapped at once.
Ask your team to list the controls, owners and evidence sources before deciding.
How does Zitadel's audit trail help with SOC 2 access reviews?
Zitadel records administrative and authentication events that can support access review evidence, but you must confirm the exact events, retention settings and export options against the version you deploy. Access reviews also need the current list of users, roles and grants, which you can pull through the API and store with each review record. Auditors will test whether reviews happen, who performed them, what they decided and how exceptions were fixed.
Design the review workflow and retention before the examination period begins.
Which Zitadel features map to CC6 logical access criteria?
Zitadel provides SCIM v2 for standardized user provisioning and lifecycle changes, project roles and grants for role-based access, passkey and password login with MFA options, and organizations and instances to separate tenants. These support CC6.2 (registering and removing users) and CC6.3 (role-based and least-privilege access). Whether each feature meets your control design depends on how your organization defines the control, so confirm the mapping with your auditor. The Zitadel documentation lists the supported SCIM and identity-provider integrations, and you should verify them against your own identity sources during scoping.
How DeployOpen scopes and delivers SOC 2 access control work
DeployOpen plans, implements, documents and supports self-hosted Zitadel inside your own infrastructure, so the identity controls behind CC6 are built where your auditors and your team can inspect them. Work is agreed as a fixed-scope engagement, with ongoing support available as a retainer once the deployment is live.
How we scope
- Map your CC6.1 to CC6.3 control statements to the Zitadel instances, organizations, projects and roles that will carry them
- List every identity source, such as Entra ID, Okta or LDAP, and every application that needs SCIM or OIDC access
- Confirm the written scope covers the PostgreSQL versions, hosting model and high availability design you have chosen
How we build
- Configure SCIM v2 provisioning and deprovisioning so access removal follows the source system of record
- Design project roles and grants around least privilege and segregation of duties, then test them against sample users
- Enforce MFA for the defined user groups and document passkey and password fallback rules
How we hand over
- Deliver a control matrix linking each CC6 point of focus to a configured setting, log source or procedure
- Document how audit trail events are exported and retained as evidence for periodic access reviews
- Run a walkthrough with your administrators so they can explain each access control to an auditor
How we support
- Agree a retainer for patching, Zitadel version upgrades and backup verification after go-live
- Review role and grant changes on a schedule you set, and record each review in the agreed evidence format
- Confirm with your auditor which evidence they expect, since DeployOpen prepares evidence but does not issue reports
