SOC 2 testing is becoming a control validation problem

At a glance

What this is: This is a SOC 2 security testing guide that explains how audits, evidence collection, and application testing support control validation.

Why it matters: It matters to IAM and security practitioners because SOC 2 outcomes depend on access control, vendor oversight, authentication, and repeatable evidence across human and non-human identities.

👉 Read StackHawk's guide to SOC 2 security testing and API compliance

Context

SOC 2 is a control assurance framework, not a software certification, and many teams still treat it as a checklist rather than an operating discipline. For application-heavy organisations, the harder problem is proving that controls continue to work as systems, APIs, vendors, and access paths change.

That is where the identity angle becomes material. SOC 2 evidence often depends on how organisations govern human access, service accounts, API access, third-party integrations, and the audit trail around those privileges. For IAM, PAM, and NHI programmes, this makes SOC 2 as much a lifecycle and control-evidence problem as a compliance exercise.

Key questions

Q: How should security teams prepare for SOC 2 when APIs and service accounts are part of production access?

A: Treat APIs and service accounts as in-scope access paths, not technical exceptions. Inventory every credentialed integration, define ownership, log activity centrally, and require evidence for provisioning, review, and revocation. If an API can reach customer data or production systems, it should be governed with the same discipline as privileged human access.

Q: Why do SOC 2 programmes often fail at evidence rather than control design?

A: Because many teams can describe a control set but cannot prove it operated consistently over time. Evidence gaps usually appear in access reviews, change records, remediation tracking, and vendor oversight. A strong SOC 2 programme needs a repeatable evidence chain that matches the audit period, not just policy documents and screenshots.

Q: What do organisations get wrong about penetration testing and SOC 2?

A: They often assume testing itself is the objective. In practice, the value comes from finding weaknesses, remediating them, and retaining proof that the control process closed the loop. Auditors care about operating effectiveness, so the testing record should show scope, findings, remediation, and retest outcomes.

Q: Which identity controls matter most when SOC 2 covers customer-facing systems?

A: Access control, authentication, and lifecycle management matter most because they govern who or what can reach sensitive systems. That includes human users, privileged admins, service accounts, tokens, and external integrations. If those identities are over-permissioned or poorly reviewed, the SOC 2 assurance story weakens quickly.

Technical breakdown

SOC 2 trust services criteria and control design

SOC 2 testing evaluates controls against the Trust Services Criteria: security, availability, processing integrity, confidentiality, and privacy. The auditor is not certifying code quality or product maturity. The question is whether the organisation has designed controls that are suitable for its environment and can demonstrate that those controls operate effectively. That usually spans access control, change management, logging, incident handling, and vendor oversight. In identity-heavy environments, those controls often fail first at the boundaries between human users, service accounts, and third-party access paths.

Practical implication: map each Trust Services Criterion to a named control owner, evidence source, and review cadence before the audit begins.

Why API testing matters to SOC 2 evidence

APIs often carry the privileges and data paths that auditors care about most, because they mediate access to customer records, internal systems, and partner integrations. Dynamic testing helps surface unauthorised access paths, weak authentication checks, and input-handling issues that can undermine confidentiality and integrity assertions. But the testing value is not the scan itself. It is the evidence that vulnerabilities were found, triaged, fixed, and retested inside a repeatable control process. That makes API testing a governance artefact as much as a technical one.

Practical implication: treat API test results as audit evidence, with remediation tickets and retest results attached to each finding.

Type I versus Type II and the evidence gap

A SOC 2 Type I report shows that controls were designed appropriately at a point in time. A Type II report shows that those controls operated effectively over a defined period. The difference matters because many organisations can describe controls but cannot yet prove sustained execution. Evidence collection is therefore central. Teams need logs, access reviews, policy exceptions, test records, and change history that line up across the assessment window. Without that chain of evidence, strong design claims do not survive the audit.

Practical implication: build an evidence pipeline that captures control operation continuously, not just during audit prep.

Threat narrative

Attacker objective: The attacker aims to reach protected systems or data through application and API weaknesses in ways that bypass the control assurances SOC 2 is meant to demonstrate.

1. Entry typically begins through exposed web application or API weaknesses that allow unauthorised interaction with protected data paths.
2. Escalation follows when weak authentication, broken access checks, or missing input validation permit broader reach than intended.
3. Impact occurs when those control failures weaken confidentiality, integrity, or auditability, creating a SOC 2 evidence gap or actual data exposure.

NHI Mgmt Group analysis

SOC 2 is really a control-evidence discipline, not a badge exercise. The article correctly frames the audit as an evaluation of design and operating effectiveness, but many programmes still optimise for documentation rather than proof. That gap matters because auditors and customers are asking whether controls actually operate across changing systems, users, and integrations. Practitioners should treat SOC 2 as an evidence pipeline problem, not a one-time checklist.

Control drift is the named risk hidden inside many SOC 2 programmes. The controls that look sound during readiness often degrade once application change, vendor access, and credential sprawl enter the picture. That is where IAM, PAM, and NHI governance intersect with SOC 2 in a practical way, because access reviews and audit logs only help if identities are correctly scoped and lifecycle-managed. The discipline needed is continuous control validation, not annual reassurance.

Application security testing is most valuable when it produces audit-ready artefacts. A DAST scan by itself does not satisfy a control objective, but a test-fix-retest record can support security, confidentiality, and integrity claims. This aligns application testing with broader governance rather than treating it as a separate engineering activity. Practitioners should connect findings to named controls, owners, and evidence repositories.

Third-party and API access are where SOC 2 confidence often erodes first. The article’s emphasis on vendor management is directionally correct, because many audit failures begin in outsourced or delegated access paths. That is also where non-human identities matter most, since API keys, tokens, certificates, and service accounts are often the hidden privileges behind the control narrative. Practitioners should include NHI governance in SOC 2 scoping, not leave it outside the assurance model.

What this signals

Control evidence will become the real differentiator in SOC 2 readiness. Teams that can continuously prove access governance, test remediation, and third-party oversight will spend less time reconstructing evidence during audit season. For identity programmes, that means aligning human access reviews and NHI lifecycle controls with the same evidence model.

API security and identity governance are converging inside compliance programmes. Once service accounts, tokens, and OAuth connections sit inside the audit boundary, the old separation between application security and IAM no longer works. Practitioners should expect more scrutiny on how privilege is granted, reviewed, and revoked across both human and machine identities.

Evidence fatigue is a real control risk. Repeatedly assembling screenshots and point-in-time exports does not scale as environments and integrations grow. The better model is continuous logging, continuous access review, and continuous validation, supported by frameworks such as NIST Cybersecurity Framework 2.0 and NIST SP 800-53 Rev 5 Security and Privacy Controls.

For practitioners

• Map SOC 2 criteria to concrete control evidence Assign each relevant Trust Services Criterion a control owner, an evidence source, and a review schedule. Include logs, access reviews, change tickets, exception approvals, and retest records so the auditor can trace design and operation through the full assessment window.
• Include API and NHI access paths in the audit scope Review service accounts, API keys, OAuth integrations, and certificates alongside human access. If these identities can reach customer data or production systems, they belong in the SOC 2 control narrative and should be covered by the same evidence standards.
• Turn testing outputs into audit-ready artifacts Store scan findings, remediation tickets, validation results, and sign-off records together. The goal is to show that vulnerabilities were identified, fixed, and retested within the control process rather than treated as isolated engineering tasks.
• Strengthen third-party oversight before the assessment period Validate vendor access, review delegated credentials, and document how third-party integrations are approved, monitored, and removed. Audit teams will ask how you controlled the boundaries of your environment, not just how you tested your own code.

Key takeaways

• SOC 2 succeeds when organisations can prove controls operate, not just describe them.
• API access, vendor integrations, and non-human identities are now part of the audit story, not edge cases.
• Continuous evidence collection and retesting are the controls that make SOC 2 defensible at scale.

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 II: A SOC 2 Type II report evaluates whether a service provider’s controls operate effectively over a defined period. In identity and access contexts, it matters because it shows evidence of real control execution, not just the existence of policy language or intent.
• Trust Services Principles: The Trust Services Principles are the criteria SOC 2 uses to evaluate a service organisation’s controls. They cover security, availability, processing integrity, confidentiality, and privacy, and each organisation must determine which principles actually apply to the services and data it handles.
• 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.

What's in the full article

StackHawk's full article covers the operational detail this post intentionally leaves for the source:

• Step-by-step guidance for using DAST in SOC 2 preparation and evidence collection.
• Practical examples of how to document scans, remediation, and retesting for auditors.
• A breakdown of how StackHawk fits into CI/CD workflows for ongoing application testing.
• Specific testing considerations for web applications and APIs under SOC 2.

👉 The full StackHawk article covers audit timing, testing workflow, and practical SOC 2 prep steps.

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, the industry's only accredited NHI security programme. It is designed for practitioners who need to connect identity governance to wider security and compliance programmes.