SOC 2 is now the baseline for scaling B2B security programmes

At a glance

What this is: Drata’s SOC 2 data shows the framework has become a default baseline, and that connected systems are the strongest signal of readiness and operational maturity.

Why it matters: For IAM and governance teams, the report matters because SOC 2 readiness increasingly depends on identity, access, evidence, and control monitoring across the business.

By the numbers:

• 70% of Drata customers have SOC 2.
• The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities.

👉 Read Drata's SOC 2 By the Numbers report

Context

SOC 2 has moved from a late-stage procurement checkbox to a standing security operating requirement for many B2B businesses. The practical issue is not whether teams can draft controls, but whether they can sustain access governance, evidence collection, logging, and vendor oversight as environments and buying expectations change.

For identity and governance teams, the key shift is that SOC 2 now depends on continuously managed access and machine-readable evidence, not annual scramble work. That makes it directly relevant to IAM, PAM, and non-human identity programmes, especially where integrations, service accounts, and system ownership drive audit readiness.

Drata’s dataset reflects an already compliance-mature customer base, so it should be read directionally rather than as a market census. Even so, the patterns are consistent with what many teams experience: readiness is less about company size and more about control integration, process discipline, and operational consistency.

Key questions

Q: How should teams build SOC 2 readiness into day-to-day operations?

A: Teams should treat SOC 2 as a continuous control system, not a late-stage audit task. The practical move is to connect identity, cloud, code, ticketing, and HR systems so evidence is collected automatically, reviewed in context, and retained in a way auditors can validate. That reduces manual scramble and keeps controls aligned to real operations.

Q: Why does SOC 2 readiness depend so much on identity and access control?

A: SOC 2 relies on knowing who or what can access systems, how that access is approved, and whether it is revoked when no longer needed. Identity and access control are central because they govern approvals, ownership, logging, and review evidence. Without them, compliance teams cannot reliably prove control operation over time.

Q: What breaks when compliance evidence is collected manually?

A: Manual evidence collection breaks when the organisation cannot keep pace with configuration changes, entitlement changes, and vendor updates. The result is stale proof, missing remediation history, and incomplete audit trails, which makes it difficult to demonstrate that PCI controls were operating continuously rather than only at review time.

Q: How should security teams govern non-human identities for SOC 2 compliance?

A: Teams should inventory every machine identity, assign an owner, restrict permissions to the minimum required, rotate secrets regularly, and log access in a way that supports audit evidence. SOC 2 is easier to defend when non-human identities are treated as governed assets rather than background infrastructure.

Technical breakdown

Why integration footprint is the strongest SOC 2 maturity signal

SOC 2 maturity increasingly shows up in how many systems feed the compliance workflow. When source control, cloud, identity, HR, ticketing, and collaboration tools are connected, evidence becomes continuous rather than manual, and control drift is easier to detect. This matters because audit readiness depends on living signals from the environment, not static screenshots or quarterly cleanups. The deeper pattern is that compliance programs become more reliable when they are built on operational telemetry instead of after-the-fact documentation.

Practical implication: connect the systems that prove access, change, and monitoring activity before you try to scale reporting.

Why evidence collection fails when policy and execution diverge

SOC 2 controls often fail in the gap between written policy and day-to-day execution. Teams can document access review, incident response, or vendor oversight, but still lose evidence if the underlying systems are not consistently configured to retain logs, approvals, and review outcomes. This is especially relevant to identity governance because access decisions, account ownership, and offboarding need both process and durable records. Without that, the program looks compliant on paper while remaining hard to verify in practice.

Practical implication: tie policy controls to systems that preserve proof of execution, especially for identity and access workflows.

How compliance layers build on shared control environments

Once a team has SOC 2 in place, the next challenge is usually control reuse. Mature organisations stop standing up separate evidence streams for every framework and instead map shared controls across SOC 2, ISO 27001, PCI DSS, or privacy regimes. That approach only works when access control, logging, vendor risk, and change management are managed centrally. For IAM teams, this is where non-human identities become important because service accounts and API tokens often sit inside the same control environment as human access.

Practical implication: design the control environment once, then reuse the evidence model across frameworks and identity types.

NHI Mgmt Group analysis

SOC 2 has become an operating model, not a report. The report’s strongest signal is not the adoption rate itself, but the way compliance now depends on continuous evidence, integrated systems, and repeatable control ownership. That shifts SOC 2 from a finite project to a sustained governance layer. For identity teams, that means access reviews, service account ownership, and logging cannot sit outside the compliance system.

Integration depth is a proxy for governance maturity. Organisations that connect identity, cloud, code, HR, and ticketing systems gain a much clearer audit trail than teams relying on manual evidence pulls. This is a control-design issue, not just an automation issue. The named concept here is evidence-connected compliance: programs become easier to defend when the proof of control lives in the systems where work actually happens.

The biggest SOC 2 risk is not absence of controls, but control drift. The report points to vulnerabilities and production configuration hygiene as recurring weak spots because those areas change faster than policy updates. That is a familiar failure mode across IAM and NHI governance too: controls exist, but the operational state changes underneath them. Teams should treat drift detection as a core compliance function, not a separate security task.

SOC 2 now behaves like a shared control plane for multiple standards. Mature teams are using one evidence and control environment to support SOC 2, ISO 27001, PCI DSS, and privacy obligations rather than duplicating work. That favours organisations that can reconcile human identity, machine identity, and system access in one governance model. Practitioners should assume framework convergence, not framework isolation.

What this signals

Evidence-connected compliance: SOC 2 programmes will keep moving toward machine-readable evidence flows, and that same pattern will shape how teams govern secrets, access reviews, and non-human identities. The practical test is whether your control environment can prove itself without manual reconstruction.

Identity teams should expect SOC 2 work to converge with lifecycle governance. Service accounts, API tokens, and access approvals increasingly need to sit in the same monitoring and ownership model, otherwise compliance and security drift apart.

The next maturity step is not more documentation, but tighter linkage between operational systems and control signals. Teams that can trace access, evidence, and exception handling across the stack will scale frameworks more cleanly than teams that still depend on screenshots and spreadsheets.

For practitioners

• Standardise your control evidence pipeline Connect source control, cloud, identity, ticketing, and HR systems into a single evidence flow so reviews, approvals, and changes are captured where they happen.
• Tie access governance to audit-ready records Make sure access reviews, ownership changes, and offboarding events leave durable records that can be reused for SOC 2 and adjacent frameworks.
• Track control drift in production systems Prioritise monitoring for configuration changes, failed tests, and control exceptions in the environments that change most often.
• Map human and non-human access into one model Include service accounts, API tokens, and other non-human identities in the same control ownership and review workflow as employee access.

Key takeaways

• SOC 2 has shifted from a point-in-time audit goal to a persistent operating requirement for B2B security teams.
• Integration depth, not organisation size, is the clearest indicator of whether a compliance programme can scale without losing control evidence.
• Identity governance, including non-human identities, now sits inside the SOC 2 control model rather than alongside it.

Key terms

• Evidence-Connected Compliance: A compliance model in which control proof is generated automatically from the systems where work happens. It reduces manual evidence pulls and makes audit readiness more durable because logs, approvals, and ownership records are captured as part of normal operations.
• Control Drift: Control drift is the gradual weakening or inconsistency of a control over time as systems, workflows, or business rules change. It often appears as different interpretations, missed exceptions, or uneven enforcement across applications, and it usually becomes visible only when monitoring spans the full process.
• SOC 2 Readiness Assessment: A readiness assessment is the pre-audit review that compares current controls against SOC 2 criteria and identifies where evidence or process maturity is missing. In practice, it is a gap analysis that tells teams what they must formalise before an auditor will accept the control environment.
• Non-Human Identity (NHI): A digital identity assigned to a non-human entity such as a software application, service account, API key, bot, machine, or AI agent that enables it to authenticate and interact with systems without direct human involvement. NHIs now outnumber human identities in most enterprises by 25 to 50 times.

What's in the full report

Drata's full report covers the operational detail this post intentionally leaves for the source:

• Segment-by-segment readiness patterns across company size, region, and industry.
• The integration mix behind the strongest SOC 2 programmes, including the systems most commonly connected.
• The control areas where teams fail most often, with more context on vulnerability remediation and production configuration hygiene.
• The way first-report teams expand into adjacent frameworks such as ISO 27001, HIPAA, and PCI DSS.

👉 Drata's full report covers the segment breakdown, readiness patterns, and control correlations behind the findings.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management. It is designed for practitioners who need to connect identity controls to broader security and compliance programmes.