SOC 2 compliance hinges on access, evidence, and continuous control

At a glance

What this is: SecurityScorecard frames SOC 2 as an evidence-driven compliance discipline where scope, control operation, and continuous monitoring matter more than a one-time audit.

Why it matters: For IAM, PAM, and NHI teams, this matters because access governance, review evidence, and third-party control proof increasingly determine whether security controls are considered auditable and trustworthy.

Context

SOC 2 is a governance and assurance problem, not just a checklist exercise. The core challenge is proving that the controls covering access, monitoring, change, incident handling, and vendor oversight are actually operating over time, especially where customer data and third-party dependencies are involved.

That makes identity governance central to the audit story. Access scope, role-based permissions, multi-factor authentication, and periodic reviews are not peripheral controls in SOC 2 programs, they are part of the evidence that demonstrates whether privileged access is controlled, monitored, and defensible across human and non-human accounts.

Key questions

Q: What breaks when SOC 2 evidence is collected without control closure?

A: Audit trails can show that actions happened, but they cannot prove the underlying access was appropriate, minimum necessary, or revoked on time. That creates a gap between documented activity and actual governance. The result is compliance theatre, where evidence looks complete even though lifecycle and privilege controls remain weak.

Q: Why do identity controls matter in a SOC 2 audit?

A: Identity controls show who can access systems, how privilege is approved, and whether access is removed when it is no longer needed. Auditors care about evidence, so access reviews, revocation records, and privileged session logs help prove the control operated consistently during the reporting period.

Q: What do security teams get wrong about SOC 2 evidence?

A: They often treat evidence as a once-a-year collection exercise rather than an operating capability. That approach encourages screenshots, spreadsheet tracking, and last-minute reconciliation, which weakens confidence. A better model is to generate evidence continuously from the same posture data used to manage regulated data during the year.

Q: How should organisations scope SOC 2 readiness without overspending on controls?

A: Start with the systems, data flows, and teams that support the service you actually sell, then map only the Trust Services Criteria that apply. Tight scope reduces unnecessary control work, shortens evidence collection, and makes the audit easier to defend because each control has a clear business purpose and owner.

Technical breakdown

Why SOC 2 evidence is about control operation, not control intent

SOC 2 requires more than written policy. Auditors look for proof that controls were designed appropriately and operated consistently during the observation period, which is why evidence collection matters as much as the control itself. A Type 1 report shows point-in-time design, while Type 2 extends into months of operating effectiveness. That distinction is crucial for access governance, change control, incident handling, and vendor management because each control must leave a trace that can be examined later.

Practical implication: retain time-stamped evidence for access reviews, approvals, incidents, and monitoring so control operation can be demonstrated, not merely asserted.

Scope defines the audit boundary and the evidence burden

SOC 2 scope is not just a documentation task. It determines which systems, people, processes, and third-party dependencies are in play, and that boundary drives the amount of evidence and testing auditors will request. Over-scoping increases cost and noise, while under-scoping risks leaving gaps in production systems, logging, backup, or access paths that matter to customers. For identity teams, the scope question also determines which accounts, entitlements, and vendors fall into review.

Practical implication: map service delivery backward from customer-facing systems to every supporting identity, platform, and vendor dependency before the audit begins.

Access controls, change management, and third-party oversight are the recurring pressure points

The article repeatedly returns to three control families because they are both common audit failure points and high-value assurance signals. Access controls show who can reach in-scope systems. Change management shows whether production changes are approved, tested, and documented. Third-party oversight shows whether external dependencies are being governed rather than trusted blindly. These controls are especially sensitive in environments with SaaS dependencies, shared infrastructure, and privileged administrators because the evidence chain can break when ownership is unclear.

Practical implication: align access governance, change tickets, and vendor oversight records so auditors can follow a single control narrative across internal and external dependencies.

Threat narrative

Attacker objective: The objective is not a classic intrusion but the ability to exploit control weakness, evade evidence, or create uncertainty around whether the environment is properly governed.

1. Entry occurs through excessive or poorly governed access to in-scope systems, third-party services, or production processes.
2. Escalation happens when privileged access, weak change controls, or incomplete monitoring let issues persist without timely challenge.
3. Impact is audit failure, delayed assurance, and reduced trust when the organisation cannot prove that controls operated effectively throughout the period.

Breaches seen in the wild

• Vercel Context.ai OAuth Supply Chain Breach: Shadow AI app Context.ai OAuth integration exposes Vercel customer data via unmanaged third-party token.
• Palo Alto Networks Salesforce data theft 2025: Stolen Drift OAuth tokens exposed Palo Alto Networks CRM data, including support notes where some customers had shared credentials.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

SOC 2 has become an access-governance problem disguised as compliance. The article makes clear that evidence, not intent, is what auditors and customers ultimately rely on. That shifts the centre of gravity toward identity control, permission scope, and review discipline across human and non-human access. For practitioners, the lesson is that audit readiness lives or dies on whether access can be defended continuously.

Continuous control, not annual preparation, is the real audit differentiator. Type 2 reporting exposes whether controls stayed effective for months, which means point-in-time cleanup is insufficient. This is where identity governance becomes operational rather than ceremonial. If access reviews, approvals, and offboarding are not recurring processes with durable records, the organisation is carrying compliance debt that will surface at audit time.

Third-party oversight is now part of the SOC 2 trust boundary. The article correctly treats vendors, hosted services, and monitoring dependencies as part of the evidence story. That reflects a broader market reality: the control perimeter is no longer internal-only, and the assurance model must account for delegated access and outsourced operations. Practitioners should assume that weak vendor governance will be read as weak control governance.

Access evidence must be generated by the control itself, not reconstructed later. This is the practical lesson for IAM, PAM, and NHI programmes. A defensible SOC 2 posture depends on systems that can show who had access, when they got it, why they had it, and when it was removed. For practitioners, the implication is to design identity workflows so evidence is a byproduct of operation, not a forensic reconstruction exercise.

What this signals

Evidence quality is the governance test SOC 2 forces on security programmes. Teams that rely on periodic clean-up tend to create brittle compliance evidence, while teams that capture approvals, reviews, and incidents as part of daily operations make audit readiness much easier to sustain. For IAM and PAM leaders, the practical shift is from assembling proof after the fact to producing it continuously through the control workflow.

Identity workflows now sit inside the audit boundary, not beside it. Access approvals, recertification cycles, and privileged account lifecycle events are no longer just internal control hygiene; they are evidence inputs for customer assurance and vendor qualification. Practitioners should treat every account change as a potential audit artefact and design the process accordingly.

For practitioners

• Define the in-scope trust boundary Map production systems, supporting services, personnel, and third-party dependencies that affect customer data or service delivery before starting audit work.
• Automate access review evidence Store review dates, approvers, exceptions, and remediation actions so quarterly or recurring certifications can be demonstrated without manual reconstruction.
• Tie change approvals to production releases Require every production change to carry an approval record, testing evidence, and release traceability that auditors can follow during the observation period.
• Extend vendor oversight into the audit trail Capture due diligence, control attestations, and issue follow-up for third-party services that can affect security, availability, or confidentiality commitments.
• Make incident records audit-ready by design Preserve incident timelines, decision logs, and restoration evidence in a format that can be retrieved quickly during SOC 2 fieldwork.

Key takeaways

• SOC 2 is fundamentally about proving that controls for access, change, incident handling, and third-party oversight operated over time, not just existed on paper.
• The most fragile parts of the programme are usually the evidence trails around permissions, approvals, and vendor dependencies, especially when systems and roles change during the observation period.
• Teams that generate evidence as part of normal IAM and governance workflows will find audits easier to defend and much less disruptive.

Key terms

• SOC 2 Type 1: A SOC 2 Type 1 audit evaluates whether controls are designed appropriately at a specific point in time. It does not prove long-term operating consistency, so it is useful for baseline assurance but weaker for showing that identity processes actually held up across normal business activity.
• SOC 2 Type 2: A SOC 2 Type 2 audit tests whether controls operated effectively over a defined period, usually six to twelve months. For identity governance, that means the organisation must show repeatable evidence for approvals, access reviews, logging, and offboarding rather than relying on a single snapshot.
• Trust Service Criteria: The five SOC 2 control categories used to evaluate a service organisation's security posture: security, availability, processing integrity, confidentiality, and privacy. They translate broad assurance goals into a testable control framework that auditors can assess against real evidence.
• Control Evidence: Control evidence is the record that shows a control exists and is operating as intended. In identity governance, it includes review records, ownership data, entitlement history, and lifecycle actions, all of which must reflect the current environment or the evidence can create false confidence.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course. It is designed for practitioners who need to connect identity governance with broader security and compliance programmes.