TL;DR: Customer authorization roles, permissions, and access rules are handled within a verified control environment, with Cerbos saying its SOC 2 Type II compliance covers the Trust Service Principles across infrastructure, software, people, data, and procedures. For IAM teams, the signal is that governance and evidence around access control must extend beyond tooling into control operation, monitoring, and auditability.
NHIMG editorial — based on content published by Cerbos: SOC 2 Type II compliance announcement and its implications for authorization governance
Questions worth separating out
Q: How should security teams prove authorization controls are operating effectively?
A: Security teams should require evidence that access controls were active, monitored, and reviewed over time, not just documented once.
Q: Why does SOC 2 Type II matter for IAM programmes?
A: SOC 2 Type II matters because it tests whether identity and access controls actually work during normal operations over a defined period.
Q: What do organisations get wrong about access control compliance?
A: They often treat compliance as proof of security rather than proof of control operation.
Practitioner guidance
- Trace authorization controls to audit evidence Document which approval, monitoring, and review steps prove that authorization rules are operating as designed across the assessment period.
- Separate policy definition from control operation Test whether the people who define access rules are also the ones who can change them, and require compensating evidence where duties overlap.
- Extend IAM assurance into application authorization Include application-level policy engines, service integrations, and runtime access decisions in your governance scope, not just directory and SSO controls.
What's in the full article
Cerbos' full announcement covers the operational detail this post intentionally leaves for the source:
- The specific controls and evidence areas included in the SOC 2 Type II assessment.
- How monitoring and intrusion detection were described as part of customer-facing security assurance.
- The service and compliance scope that Cerbos says was evaluated across infrastructure, software, people, data, and procedures.
- The customer impact language Cerbos uses to explain its authorization and compliance posture.
👉 Read Cerbos' announcement on SOC 2 Type II compliance for authorization controls →
SOC 2 Type II and authorization governance: what does it change?
Explore further
Authorization assurance is an identity governance problem, not just a compliance outcome. SOC 2 Type II matters here because it tests whether access controls operate consistently over time, which is the real governance question behind roles, permissions, and policy enforcement. When authorization becomes part of the application stack, security teams still need evidence that the control behaves as intended in production. The practitioner conclusion is simple: treat authorization evidence as part of IAM assurance, not as a separate audit artifact.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- 43% of security professionals are concerned about AI systems learning and reproducing sensitive information patterns from codebases.
A question worth separating out:
Q: How can teams decide whether to trust delegated authorization systems?
A: Teams should trust delegated authorization systems only when they can verify change control, operational monitoring, and review coverage for the rules that drive access decisions. If those three layers are missing, the system may still function, but it is not governed in a way that supports audit or accountability.
👉 Read our full editorial: Cerbos SOC 2 Type II compliance and what it means for access control