By NHI Mgmt Group Editorial TeamPublished 2025-06-26Domain: Governance & RiskSource: Zluri

TL;DR: SOC 2 preparation is presented as a way to harden security, improve trust, and standardise controls across employees and third-party vendors, with Zluri citing a 270% jump in US breach cases in 2020 as the backdrop. The deeper issue is that audit readiness exposes whether identity, access, and vendor governance are actually operating as controls rather than policies on paper.


At a glance

What this is: This is an audit-readiness article on SOC 2 that frames compliance as a governance discipline for securing customer data, vendors, and access controls.

Why it matters: It matters because SOC 2 readiness depends on how well IAM, IGA, and third-party access controls are working in practice across human and non-human identities.

By the numbers:

👉 Read Zluri's SOC 2 audit preparation guide for identity and compliance teams


Context

SOC 2 is an audit framework for proving that an organisation has controls in place to protect customer data, maintain availability, preserve integrity, and manage privacy and confidentiality. For identity teams, the real question is whether those controls work across employees, administrators, vendors, and the non-human accounts that often sit behind SaaS, cloud, and integration workflows.

The article treats compliance as a response to rising breach exposure, vendor risk, and weak internal process discipline. That is the right starting point: SOC 2 readiness is not only a documentation exercise, it is a test of whether IAM, IGA, and access governance can show evidence of control, review, and accountability.


Key questions

Q: How should security teams prepare identity controls for a SOC 2 audit?

A: Start by mapping every identity that can reach in-scope systems, including employees, contractors, vendors, and service accounts. Then prove who approves access, how often it is reviewed, and how removal is verified. Auditors look for evidence that access governance works continuously, not just on paper.

Q: Why do third-party identities create SOC 2 audit risk?

A: Third-party identities create risk because they often escape the normal joiner-mover-leaver process, yet still touch customer data and production systems. If ownership, purpose, and removal triggers are unclear, auditors cannot verify accountability. That gap usually shows up as weak evidence, not just weak policy.

Q: What breaks when shadow IT is inside the audit boundary?

A: Shadow IT breaks the control story because the organisation may not know which apps store data, who administers them, or whether access was ever approved. In SOC 2 terms, that means the boundary is incomplete. Discovery and classification are required before controls can be defended.

Q: Who is accountable when SOC 2 access controls fail?

A: Accountability sits with the business owner of the system, the control owner for the access process, and the security or IAM team responsible for evidence. SOC 2 expects a clear chain of responsibility, especially when third parties or outsourced operations are involved.


Technical breakdown

SOC 2 security criteria and identity controls

SOC 2 security is about preventing unauthorised access, abuse, theft, and data removal. In practice, that means authentication, access restriction, logging, and vendor oversight must be demonstrable, not implied. For IAM teams, the audit question is whether access paths are mapped, approved, and monitored across users and third parties, including privileged and shared accounts. Control design matters less than control evidence if an auditor cannot see who had access, why they had it, and how that access was reviewed.

Practical implication: tie every sensitive access path to an owner, approval, and log trail before the audit window opens.

Type 1 versus Type 2 and the evidence problem

SOC 2 Type 1 checks whether controls exist at a point in time, while Type 2 checks whether they continue to operate over a period of time. That difference matters because identity governance failures usually show up in the gap between policy and persistence. A one-time access model can look acceptable on paper, yet still fail if recertification, offboarding, or vendor removal does not happen consistently. Type 2 is where stale entitlements, inherited access, and missing evidence become visible.

Practical implication: verify that access review, offboarding, and logging evidence can be produced over time, not just for a single snapshot.

Third-party access and shadow IT exposure

The article explicitly points to outsourced vendors and shadow IT as governance weak points. That is an identity problem as much as a procurement problem, because unmanaged SaaS and external access often bypass standard review paths. When employees adopt apps outside approved channels, the organisation loses sight of what identities exist, who controls them, and whether the data they touch falls under the SOC 2 boundary. This is where identity governance and SaaS discovery intersect most clearly.

Practical implication: discover unmanaged apps and external access paths before scoping the audit, then assign ownership for each one.


Threat narrative

Attacker objective: The objective is to exploit weak governance around access and data handling until the organisation cannot reliably prove control over customer information.

  1. Entry occurs through weak access governance, unmanaged third-party vendors, or shadow IT that sits outside standard review and approval workflows.
  2. Escalation happens when unauthorised or over-broad access persists because controls such as logging, review, and offboarding are incomplete or inconsistent.
  3. Impact follows when customer data, business continuity, or regulatory posture cannot be defended during an audit, breach, or customer due-diligence review.
  • Cisco DevHub NHI breach — IntelBroker exploited exposed Cisco credentials, API tokens and keys in DevHub.
  • Snowflake breach — Snowflake breach compromised Ticketmaster, Santander and others via cloud credential abuse.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.


NHI Mgmt Group analysis

SOC 2 readiness is really an identity evidence test. The article presents compliance as a standards exercise, but the practical burden falls on IAM and IGA teams that must prove who had access, why they had it, and whether that access was reviewed. If those answers cannot be produced, the organisation does not have a documentation problem, it has a control problem. Practitioners should treat SOC 2 as evidence of governance maturity, not a paperwork milestone.

Third-party access without lifecycle offboarding is the failure mode SOC 2 exposes fastest. The article’s emphasis on offshore vendors and external audits points to a familiar gap: external identities often survive the business relationship that created them. That creates audit friction, data exposure, and unclear accountability. The implication is that access lifecycle ownership must extend beyond employee joiner-mover-leaver processes to every third-party identity in scope.

Shadow IT turns SOC 2 into a discovery problem before it becomes a compliance problem. If employees can adopt unsanctioned SaaS tools outside normal procurement and security review, the audit boundary becomes unstable. That makes access governance, app discovery, and entitlement visibility inseparable. Organisations that cannot enumerate where data flows cannot credibly claim they have controlled it.

Integrity and confidentiality controls fail when identity governance is treated as a checklist instead of an operating model. SOC 2 asks whether changes are authorised, accurate, and timely, which means identity approvals, privileged access, and review workflows must actually govern change. If those processes are only episodic, the audit may pass at a point in time while the operating model remains exposed. Practitioners should design for continuous evidence, not seasonal compliance.

Audit readiness is now a vendor-risk discipline as much as an internal control discipline. The article correctly links customer trust to outsourced vendors and external assurance, which means procurement, security, and identity teams need a shared view of access boundaries. In practice, that means every vendor identity should have an owner, a purpose, and a removal trigger. Teams that cannot show that chain will struggle to defend their control environment.

From our research:

  • Only 1.5 out of 10 organisations are highly confident in their ability to secure NHIs, compared to nearly 1 in 4 for securing human identities, according to The State of Non-Human Identity Security.
  • Our research also found that 85% of organisations lack full visibility into third-party vendors connected via OAuth apps, which is a direct analogue to the visibility problem exposed by shadow IT.
  • For lifecycle governance, the NHI Lifecycle Management Guide helps teams connect provisioning, review, and offboarding to audit evidence.

What this signals

Identity governance is now part of audit defensibility, not just access administration. SOC 2 pressure will keep pushing teams toward measurable evidence of access review, offboarding, and third-party ownership. That makes the control environment harder to fake and easier to benchmark across programmes.

A practical signal to watch is whether your team can produce access evidence without manual reconstruction. If each audit requires spreadsheet recovery, the programme is operating below the maturity level expected of a modern IAM function.

The next step for many organisations is to align discovery, lifecycle, and review processes under a single governance view. That is where frameworks such as the NIST Cybersecurity Framework 2.0 and the 52 NHI Breaches Analysis become useful for pressure-testing control evidence and recurring failure patterns.


For practitioners


Key takeaways

  • SOC 2 readiness exposes whether identity controls are actually operating, not just documented.
  • Third-party access and shadow IT are the two governance weak points most likely to undermine audit evidence.
  • Teams that can produce continuous evidence for access, review, and offboarding will be better positioned for both SOC 2 and broader identity governance maturity.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST CSF 2.0 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.

FrameworkControl / ReferenceRelevance
NIST CSF 2.0PR.AC-4SOC 2 access governance maps directly to who can access what and under what conditions.
NIST Zero Trust (SP 800-207)SOC 2 control evidence depends on continuous verification of access and trust boundaries.
OWASP Non-Human Identity Top 10NHI-03Third-party and non-human access lifecycle gaps often show up as unmanaged credentials and stale entitlements.

Apply NHI-03 controls to rotation, review, and retirement of non-human and vendor credentials.


Key terms

  • SOC 2 Type 1: A point-in-time SOC 2 assessment that checks whether controls are designed and in place on the audit date. It does not prove the controls stayed effective over time, which is why identity evidence and ongoing governance still matter after the initial snapshot.
  • SOC 2 Type 2: A SOC 2 assessment that evaluates whether controls operated consistently over a defined period. For identity teams, this means access reviews, offboarding, logging, and approval workflows must be repeatable and provable across the review window, not just present in policy.
  • Shadow IT: Technology, applications, or services used without formal approval or security oversight. In identity governance terms, shadow IT matters because it creates hidden access paths, unknown data flows, and unmanaged identities that can sit outside the audit boundary and weaken compliance evidence.
  • Control Evidence: Records that demonstrate a security or governance control actually operated as intended. Evidence can include approvals, logs, review records, and removal tickets. Audits depend on evidence because policy alone does not prove that access was governed in practice.

Deepen your knowledge

NHI governance, agentic AI identity, and machine identity security are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or governance in your organisation, it is worth exploring.

This post draws on content published by Zluri: Security & Compliance Preparing for a SOC 2 Audit? All You Need To Know. Read the original.

NHIMG Editorial Note
Published by the NHIMG editorial team on 2025-06-26.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org