Which Software Should Be in Your SOC 2 and ISO 27001 Vendor Management Review?

TL;DR

A vendor belongs in your SOC 2/ISO 27001 program if it impacts the security, availability, processing integrity, or confidentiality of customer data or your service. Focus on vendors that store, process, or access customer data, that impact uptime, that transform data, or that handle proprietary code. Exclude internal tools that never touch customer data or affect service delivery.

What Does "In-Scope Vendor" Mean?

An in-scope vendor is any third-party service or software provider whose operations could materially affect your ability to meet your security commitments to customers. For SOC 2 and ISO 27001, this means vendors that:

1. Handle customer data in any way (storage, processing, transmission, access)
2. Impact service availability (infrastructure, hosting, critical dependencies)
3. Access confidential information (source code, trade secrets, internal systems)

The key insight: vendor management is not about cataloging every tool your company uses. It is about identifying and managing third-party risk where that risk could affect your customers.

The Compliance Requirements

SOC 2 addresses vendor management through multiple controls within the Trust Services Criteria:

• CC9.2 (Risk Mitigation): The primary vendor management control. Requires assessing and monitoring third-party service providers whose services are part of your system or could affect the security, availability, processing integrity, or confidentiality of your systems
• CC2.3 (Communication with External Parties): Requires communicating relevant security matters to vendors and other external parties
• CC6.4 (Logical Access): Requires managing and restricting vendor access to your systems

These criteria require organizations to assess vendor security posture, document the assessment, and monitor for changes that could affect your service commitments.

ISO 27001 covers vendor management through Annex A controls, specifically A.5.19-A.5.23 (Supplier relationships) and supporting controls around information security in supplier agreements, managing information security within the ICT supply chain, and monitoring/reviewing supplier services.

Both frameworks expect you to:

• Maintain an inventory of in-scope vendors
• Assess vendor security posture before onboarding
• Review vendor security status periodically (typically annually)
• Document vendor contracts with appropriate security terms

Vendor management is a required policy for both frameworks. For the full list of policies you need, see our guides on SOC 2 policies and ISO 27001 documentation requirements.

The Decision Framework: Four Questions

For every vendor or software tool, ask these four questions. If the answer to any is "yes," the vendor is likely in scope.

1. Does this vendor impact the security of customer data?

This is the most important question. Consider whether the vendor:

• Stores customer data (databases, file storage, backups)
• Processes customer data (analytics, logging, monitoring)
• Transmits customer data (APIs, integrations, webhooks)
• Has access to systems containing customer data (support tools, admin panels)

Examples of YES:

• AWS/GCP/Azure (hosts your application and data)
• Supabase, MongoDB Atlas, PlanetScale (database providers)
• Datadog, Sentry, LogRocket (logging/monitoring that may contain PII)
• Intercom, Zendesk (customer support with access to customer information)
• Stripe, Plaid (payment and financial data)

Examples of NO:

• Figma (design tool, no customer data)
• Notion (internal wiki, assuming no customer data stored)
• Loom (internal video recordings)

2. Does this vendor impact the availability of your service?

If the vendor goes down, does your product stop working or degrade significantly? Consider:

• Infrastructure providers that host your application
• CDN and edge services that deliver your content
• DNS providers that route traffic to your service
• Critical SaaS dependencies your application calls in real-time
• Monitoring and alerting tools that detect outages

Examples of YES:

• Cloudflare, Fastly (CDN, DDoS protection)
• Route 53, Cloudflare DNS (DNS resolution)
• Twilio, SendGrid (if your app depends on messaging)
• Any API your application calls synchronously

Examples of NO:

• Google Analytics (tracking down doesn't break your app)
• Marketing email tools (delayed marketing emails don't affect product)
• Background analytics tools

3. Does this vendor impact processing integrity?

Processing integrity matters when vendors transform, calculate, or modify your data. If incorrect processing could affect customer outcomes, the vendor is in scope:

• ETL and data pipeline tools that transform customer data
• Calculation engines that process financial or business logic
• Integration platforms that sync data between systems
• AI/ML services that make decisions affecting customers

Examples of YES:

• Fivetran, Airbyte (data pipelines that transform data)
• Segment (customer data routing and transformation)
• AI services that process customer inputs (OpenAI, Anthropic APIs if used in production)

Examples of NO:

• Analytics tools that only read data without transformation
• Reporting tools that display data without modification

4. Does this vendor impact the confidentiality of your IP or proprietary information?

This covers vendors that could expose your competitive advantages or internal operations:

• Source code repositories where your code lives
• CI/CD pipelines that build and deploy your code
• Code analysis tools that scan your repositories
• Development environments with access to production secrets

Examples of YES:

• GitHub, GitLab, Bitbucket (source code)
• CircleCI, GitHub Actions, Jenkins (CI/CD)
• Snyk, SonarQube, Semgrep (code scanning)
• Vercel, Netlify, Heroku (deployment platforms)
• 1Password, HashiCorp Vault (secrets management)

Examples of NO:

• Project management tools (Jira, Linear) unless they contain sensitive architecture details
• Documentation tools (Confluence) unless storing sensitive technical specs

Note: These four questions map to SOC 2's Trust Services Criteria: Security, Availability, Processing Integrity, and Confidentiality. Privacy is the fifth criterion, but for vendor scoping purposes, it is typically covered under "security of customer data" since vendors handling personal data are already in scope.

Vendor Categories: Always In, Usually In, Depends, Usually Out

Always In Scope

These vendors should always be part of your vendor management program:

Usually In Scope

These vendors are typically in scope for B2B SaaS companies:

Depends on Your Configuration

These vendors may or may not be in scope depending on how you use them:

Usually Out of Scope

These vendors typically do not need to be in your compliance vendor management program:

*Exception: If your HR system integrates with identity management for access provisioning, consider including it in scope.

**Exception: If customer data is shared in Slack channels or with external parties, reconsider scope.

SOC 2 vs. ISO 27001: Vendor Management Differences

While both frameworks require vendor management, the emphasis differs:

SOC 2 Approach

SOC 2 focuses on vendors that affect your Trust Services Criteria commitments. The key control (CC9.2) requires you to:

• Identify third parties whose services are part of your system or could affect your commitments
• Assess those third parties' ability to meet your security requirements
• Obtain assurance about vendor controls (SOC 2 Type II reports are common but not the only acceptable method; security questionnaires, ISO 27001 certificates, or other evidence may suffice depending on vendor criticality)
• Address any Complementary User Entity Controls (CUECs) identified in vendor reports
• For vendors using the carve-out method in their SOC 2 report, separately assess any excluded subservice organizations

Evidence auditors expect:

• Vendor inventory tied to Trust Services Criteria impact
• SOC 2 Type II reports (or equivalent assurance) for critical vendors
• Documented evidence of review showing who reviewed each vendor report, when, and conclusions (e.g., "Reviewed AWS SOC 2 Type II on 2025-03-15 by Jane Smith. No exceptions impacting our environment. CUECs addressed in our IAM policy.")
• Bridge letters (also called gap letters) when a vendor's SOC 2 report period does not fully cover your audit period
• Contracts with security clauses including incident notification requirements, right-to-audit provisions, and data handling terms

ISO 27001 Approach

ISO 27001 takes a broader supplier relationship management view through Annex A controls:

• A.5.19: Information security in supplier relationships
• A.5.20: Addressing security within supplier agreements
• A.5.21: Managing information security in the ICT supply chain
• A.5.22: Monitoring, review, and change management of supplier services
• A.5.23: Information security for use of cloud services

Evidence auditors expect:

• Supplier register with risk classification
• Supplier security assessment process
• Contractual security requirements
• Regular supplier review cadence
• Supply chain risk considerations

Practical Differences

Pro tip: If you are pursuing both certifications, build your vendor management program to satisfy ISO 27001's broader requirements, then map to SOC 2 criteria. This ensures you meet both frameworks with one process. For a detailed comparison, see our guide on SOC 2 vs. ISO 27001.

Practical Checklist: Scoping Your Vendor Program

Use this checklist when evaluating whether a vendor belongs in scope:

Initial Screening Questions

• Does this vendor store, process, or transmit customer data?
• Does this vendor have access to systems containing customer data?
• Would an outage of this vendor affect our service availability?
• Does this vendor transform, calculate, or modify customer data?
• Does this vendor have access to our source code or proprietary IP?
• Does this vendor handle authentication or identity for our users or employees?
• Is this vendor part of our software supply chain (dependencies, build tools)?

If any answer is YES, the vendor is likely in scope.

Risk Classification

Once you determine a vendor is in scope, classify the risk level based on your risk assessment methodology:

Assessment Methods by Vendor Type

Common Mistakes to Avoid

1. Over-Including Vendors

The mistake: Adding every tool your company uses to the vendor management program.

Why it is wrong: Creates assessment fatigue, dilutes focus from truly critical vendors, and makes the program unsustainable. Your security team cannot meaningfully assess 150 vendors annually.

What to do instead: Apply the four-question framework rigorously. If a tool does not impact customer data security, availability, processing integrity, or confidentiality, it does not need formal vendor management.

2. Under-Including Vendors

The mistake: Only including your primary cloud provider and ignoring other critical dependencies.

Why it is wrong: Auditors will question why your GitHub, Datadog, or authentication provider is missing. Vendor management gaps are among the most common SOC 2 audit exceptions. More importantly, these vendors represent real risk.

What to do instead: Walk through your architecture diagram. Identify every external service your application depends on for security, availability, or functionality.

3. Forgetting Shadow IT

The mistake: Only tracking officially sanctioned tools while employees use unapproved services that handle customer data.

Why it is wrong: If a support engineer exports customer data to an unapproved spreadsheet tool, that tool is effectively in scope, and you have a control gap.

What to do instead:

• Implement a vendor approval process before new tools are adopted
• Use SSO enforcement to limit which apps can authenticate
• Periodically audit OAuth grants and installed apps

4. Ignoring Subservice Organizations

The mistake: Reviewing your primary vendor but not considering their downstream providers who also handle your data.

Why it is wrong: When your logging provider hosts on AWS, or your payment processor uses a third-party fraud detection service, your data flows to those parties too. SOC 2 calls these "subservice organizations"; GDPR uses "subprocessors"; ISO 27001 refers to them as "sub-suppliers."

Critical concept - Carve-out vs. Inclusive Method:

• Inclusive method: The vendor's SOC 2 report covers their subservice organization's controls. You get assurance about both in one report.
• Carve-out method: The subservice organization is excluded from the vendor's SOC 2 scope. You need to separately obtain and review that subservice organization's SOC 2 report.

Most SaaS vendors use the carve-out method for their cloud providers (AWS, GCP, Azure), meaning you should also review those cloud providers' SOC 2 reports.

What to do instead:

• Check the "Subservice Organizations" section in vendor SOC 2 reports to identify carve-outs
• For carved-out subservice organizations, obtain their SOC 2 reports separately
• Ensure your vendor contracts flow down security requirements
• Watch for concentration risk: if multiple critical vendors all use the same cloud provider, that is a single point of failure
• Focus due diligence on vendors with many subservice organizations or complex supply chains

5. One-Time Assessment Only

The mistake: Assessing vendors at onboarding and never reviewing them again.

Why it is wrong: Vendor security posture changes. That startup you onboarded two years ago may have grown, improved security, or degraded. Annual reviews catch changes.

What to do instead:

• Set annual review cadence for critical/high-risk vendors
• Request updated SOC 2 reports each year
• Monitor for vendor security incidents or breaches

6. Missing Software Supply Chain

The mistake: Focusing only on SaaS vendors while ignoring open-source dependencies and build tools.

Why it is wrong: Supply chain attacks like SolarWinds, Codecov, and npm package compromises show that your build pipeline and dependencies are attack vectors.

What to do instead:

• Maintain a Software Bill of Materials (SBOM)
• Use dependency scanning tools (Dependabot, Snyk, Renovate)
• Include CI/CD and deployment tools in vendor scope

Building Your Vendor Inventory

A compliant vendor inventory should include:

Pro tip: Start simple. A spreadsheet works fine initially. Move to GRC tooling only when you have more than 30-40 in-scope vendors or need workflow automation.

Conclusion

Effective vendor management for SOC 2 and ISO 27001 is not about tracking every tool your company uses. It is about identifying and managing third-party risk where that risk could impact your customers.

Apply the four-question framework: Does this vendor affect security, availability, processing integrity, or confidentiality? If yes, include it. If no, document why it is out of scope and move on.

Start with your critical vendors (cloud infrastructure, databases, authentication, source control), then expand to high-risk vendors (logging, monitoring, customer support). Avoid the trap of over-inclusion that creates unsustainable programs, but do not ignore the shadow IT and supply chain risks that auditors increasingly scrutinize.

Need help building a vendor management program that satisfies your compliance requirements without creating unnecessary overhead? Talk to our team about a practical approach to third-party risk management.

Sources

• AICPA Trust Services Criteria - SOC 2 control requirements including CC9.2 on third-party risk
• ISO/IEC 27001:2022 - Information security management system requirements
• ISO/IEC 27002:2022 - Information security controls including supplier relationship guidance
• NIST SP 800-53 Rev. 5 - Security and privacy controls including supply chain risk management (SR family)
• CSA CAIQ (Consensus Assessment Initiative Questionnaire) - Standardized cloud security questionnaire
• Shared Assessments SIG - Standardized Information Gathering questionnaire for vendor assessment