SOC 2, Access Reviews, and the Vendor List Nobody Owns

Every SOC 2 audit ends up in the same place. The auditor asks for the vendor list. Finance sends theirs. Security sends theirs. The two lists do not match, and neither includes the tool that showed up on a corporate card statement three weeks ago. The audit finding writes itself.

The vendor list is where finance, security, and compliance are all supposed to meet, and mostly they do not. This is why, and what to do about it.

What does SOC 2 actually require for vendor management?

Trust Services Criterion CC9.2 requires organizations to identify third-party vendors, assess their security posture, and monitor them throughout the relationship. This translates to four operational requirements auditors check.

1. A documented vendor list. Every tool the company uses, especially ones handling customer or employee data.
2. Access reviews on a defined cadence. Quarterly for tools handling sensitive data, annually for others.
3. Offboarding evidence. When an employee leaves, their access to every tool must be removed and documented.
4. Risk assessment for critical vendors. A written assessment of vendor security posture for anything holding sensitive data.

The auditor does not need to read every contract. They sample. If the list has 200 vendors and the auditor pulls 20 of them, all 20 need clean documentation. If the list is missing a vendor the auditor finds on a card statement, that is a finding on the completeness of the list itself.

Why do finance and security keep different vendor lists?

The lists diverge because they answer different questions.

• Finance asks: who are we paying? The list contains everything with a signed contract or a recurring invoice. Excludes free tools with user accounts.
• Security asks: who has access to our data? The list contains everything users log into via SSO or credentials, including free tools. Excludes contracts without active users (e.g., data pipelines with API-only access).
• Legal asks: who did we sign an agreement with? The list contains signed MSAs and DPAs. Excludes anything under a click-through.
• IT asks: what runs on our systems? The list contains endpoints and infrastructure vendors. Excludes SaaS with no local footprint.

Each list is correct from its own perspective. None of them is complete for SOC 2, which needs all four views merged.

Which vendors need access reviews and how often?

Not every vendor needs quarterly reviews. The tiering usually looks like this.

The tiering is the auditor's first question after the list itself. Every vendor on the list needs a tier assigned, and the assignment logic needs to be documented.

A common failure: the tiering was done once, a year ago, and never revisited. Meanwhile the tool started handling PII because the team started using it for new use cases. The auditor finds this by asking users what they store in the tool.

What does an access review actually look like?

The review has three parts. Each needs to leave evidence.

• Active user list. Pulled from the tool's admin console or the identity provider, dated, and named.
• Role review. Every user's role is confirmed as still appropriate. This means someone (usually the tool's business owner) reviews each user and confirms role and continued need.
• Sign-off. The review is signed by the business owner and the security or compliance owner. Dated, stored, retrievable.

The auditor samples reviews. If they pick a quarterly review for CRM in Q2 2026, they expect to see the active user list from that date, evidence of role review, and a sign-off. Missing any of the three is a finding.

Practical failure: reviews are done in email, not in a system. The audit trail is a Slack thread and a spreadsheet. Auditors accept spreadsheets if they are properly dated and signed, but they downgrade the control quality, which affects the report language.

Why is offboarding the most common finding?

Offboarding is the most consistent SOC 2 finding because it requires evidence of a negative: proof that access was removed, not just proof that offboarding was initiated.

The failure mode is predictable.

1. Employee leaves. HR notifies IT.
2. IT deprovisions the identity provider. SSO access closes.
3. But the employee had accounts on tools outside SSO. These still work.
4. Six weeks later, someone notices the departed employee is still receiving notifications from a marketing tool that used direct login.

The auditor samples. If they pick a departed employee and finds a tool where access was not removed, that is a finding, even if the tool was low-risk and the access was inert.

The fix is that the vendor list drives offboarding, not the identity provider. When someone leaves, HR sends the list to their manager, who confirms access is removed from every tool. If the vendor list is missing 20% of tools, the offboarding process is missing 20% of coverage.

How do you build the unified vendor list?

Three data sources merged, one owner, monthly refresh.

• Finance layer. AP export and card feed. Everything the company pays for.
• Security layer. SSO app inventory plus direct-login tools identified through user surveys or endpoint monitoring.
• Compliance layer. Signed contracts and DPAs from the contract repository.

Merge on vendor domain. Reconcile mismatches manually for the top 50 by spend or risk. Anything on any list but not on the merged list is either a data pull error or a real gap. Both need investigation.

Refresh monthly. Ownership sits with one named person, typically in finance ops or GRC, with sign-off from both the CFO and the CISO. Splitting the ownership between finance and security has never worked long-term at any company I have seen; one person owns the artifact and pulls inputs from both sides.

What is the audit prep timeline?

For a Type II audit, the vendor list needs to be clean for the full audit period, usually 6 to 12 months. Preparation happens on this timeline.

• 12 months before audit. Unified vendor list operational. Monthly refresh cadence in place.
• 6 months before. Access reviews on the tiered cadence with documented evidence.
• 3 months before. Offboarding audit: sample 5 to 10 recent departures, verify access removal across the full vendor list.
• 1 month before. Auditor kickoff. Provide vendor list, tiering logic, review evidence.
• During audit. Auditor samples. Respond with dated evidence.

Companies with a mature process usually finish audit fieldwork in 3 to 4 weeks. Companies without unified vendor lists routinely run 8 to 12 weeks because every sample requires cross-team reconciliation.

How does spend management overlap with SOC 2?

Spend management and SOC 2 need the same primary artifact: the complete vendor list. The two disciplines produce it for different reasons but the underlying data is identical.

Practical benefits when they share the list:

• Faster audit prep. The list is already complete and refreshed monthly.
• Fewer findings. Shadow tools that would otherwise appear as audit findings are already documented.
• Better offboarding. The offboarding checklist is the vendor list, not a subset of it.
• Real-time discovery. New tools appear on the list within 30 days of first payment or first login, not at annual audit.

The finance and security teams are usually surprised by how well the same discovery process serves both use cases. The disciplines converge on the same reality because there is only one reality: what the company actually uses.

The mistake to avoid

Most companies treat SOC 2 vendor management as a compliance project owned by security and vendor spend as a cost project owned by finance. That split guarantees two incomplete lists and predictable audit findings. The vendor list is one artifact used by two disciplines, and its owner needs to sit above both. Refresh monthly, feed both compliance and cost workflows from the same data, and the audit prep time drops by half while the shadow spend gets caught 90 days earlier. One list, one owner, two use cases. The rest is coordination cost.