SOC 2 Third-Party Risk: A Walkthrough with Templates (2026)

Most enterprise buyers now require proof of security before they sign a contract. They review audit reports, security questionnaires and control evidence, and they want confidence that a vendor’s partners are just as secure. When those vendors handle personal data or critical workloads, a weak third‑party can become the weakest link. In 2025 the global average cost of a data breach fell to US$4.44 million, yet U.S. breaches climbed to US$10.22 million and healthcare incidents still averaged US$7.42 million. The lesson is clear: businesses have to stay ahead of attackers and regulators. That means understanding SOC 2 Third‑Party Risk and building a vendor risk programme that meets enterprise expectations.

This article explains what SOC 2 is and how it incorporates third‑party risk, outlines key requirements for vendor management, and walks through a practical lifecycle that sellers can follow. The guidance is written from the perspective of Konfirmity, a human‑led, managed security and compliance partner that has supported more than 6,000 audits over 25 years. It includes templates for risk assessments, onboarding workflows and monitoring schedules. By the end of this article, you will know how to design and operate a programme that impresses buyers and auditors without exhausting your team.

What Is SOC 2?

‍

SOC 2 is an attestation standard created by the American Institute of Certified Public Accountants (AICPA). A SOC 2 examination evaluates how a service organisation’s controls meet the Trust Services Criteria—Security, Availability, Processing Integrity, Confidentiality and Privacy—and the auditor issues a report that buyers and regulators can rely on. SOC 2 Type I reports test whether controls are designed correctly at a moment in time; Type II reports examine whether those controls operate effectively over a period, usually three to twelve months. Because Type II reports demonstrate ongoing evidence, enterprise buyers usually require them.

A SOC 2 report shows that a service provider has mature processes for access control, incident response, change management and risk mitigation. When vendors adopt SOC 2 they signal that they take security seriously and are ready to handle sensitive data. Enterprise procurement teams trust standardized SOC 2 reports more than ad‑hoc questionnaires, so a well‑executed SOC 2 can shorten sales cycles. However, SOC 2 also extends to third‑party providers: if a sub‑service organisation affects the services you offer, the auditor will scrutinise that relationship. That’s why SOC 2 Third‑Party Risk is not an optional add‑on but a central element of your compliance story.

SOC 2 Trust Service Criteria

The Trust Services Criteria are five high‑level categories that auditors use to evaluate a system’s trustworthiness. According to Drata’s 2025 guidance, the categories are Security, Availability, Processing Integrity, Confidentiality and Privacy. The AICPA standardises these criteria and include both common controls (such as access management and monitoring) and category‑specific requirements (such as capacity planning for Availability and data disposal for Privacy). Security is always mandatory, while the other four categories are optional and should be selected based on customer commitments and regulatory obligations. Each category contains specific criteria; for example, Security encompasses nine Common Criteria (CC1–CC9) that address control environment, communication, risk assessment, monitoring, control activities, access control, system operations, change management and risk mitigation.

The criteria most relevant to SOC 2 Third‑Party Risk are:

• Risk Assessment (CC3) – The organisation must identify and analyse threats to customer data and objectives. This includes risks introduced through vendors.
  
  
• Monitoring Activities (CC4) – The organisation must continuously evaluate the effectiveness of controls, which includes vendor monitoring.
  
  
• Control Activities (CC5) – Policies must be translated into action, such as access reviews and change approvals.
  
  
• Logical and Physical Access Controls (CC6) – Vendors often access systems; restrictions and multi‑factor authentication help prevent unauthorised access.
  
  
• Risk Mitigation (CC9) – The entity must reduce risk through contingency planning and asset protection; for third‑party risk, this involves evaluating vendors and planning for failure modes.

Availability, Processing Integrity, Confidentiality and Privacy may also apply. For instance, a cloud hosting provider must meet your Availability commitments; a payment processor may affect Processing Integrity; an e‑mail marketing vendor must safeguard confidential data; and a healthcare partner must follow HIPAA and Privacy criteria. When you scope your SOC 2, decide which criteria apply to each service and vendor; adding more criteria increases audit depth but also instills greater buyer confidence.

What Is Third‑Party Risk in SOC 2 Context?

Third‑party risk refers to the security, compliance and operational hazards introduced by vendors, partners or suppliers. Any external party that stores, processes or transmits your data—or provides critical services that underpin your business—can expose you to breach, outage or regulatory fines. Third‑Party Risk Management (TPRM) is the structured process of identifying, assessing and mitigating those risks. The U.S. Federal Resources Corporation (FRC) describes TPRM as the process of “identifying, assessing and mitigating the risks presented by an organisation’s external partners” and notes that it requires a structured lifecycle that spans procurement, cybersecurity and mission‑owner perspectives.

Third‑party risk scenarios vary by industry:

• Data Breach at a Vendor: Attackers compromise a payroll provider and steal employee Social Security numbers. This scenario played out repeatedly in 2025. IBM’s 2025 breach report noted that 16% of breaches involved attackers using machine intelligence tools, and shadow machine intelligence tools (unsanctioned tools) were used in 20% of breaches. A compromised third‑party can lead to multimillion‑dollar losses and reputational harm.
  
  
• Operational Outage: A cloud provider suffers a regional outage, affecting your customers. Availability commitments under SOC 2 require contingency plans and redundancy.
  
  
• Compliance Violation: A marketing vendor sends e‑mails to individuals in a jurisdiction covered by the EU GDPR but lacks appropriate consent. This triggers fines for both the vendor and your organisation.
  
  
• Fourth‑Party Risk: A supplier subcontracts part of its service to another provider without informing you. This hidden dependency can create unknown exposures and complicate risk assessments.

The U.S. National Institute of Standards and Technology (NIST) emphasises that organisations are concerned about products and services that may contain malicious functionality, be counterfeit or be vulnerable due to poor manufacturing and development practices. These supply‑chain risks reduce visibility into how technology is developed and deployed; therefore NIST’s SP 800‑161 Rev 1 provides guidance on identifying, assessing and mitigating cybersecurity risks throughout the supply chain. Integrating such guidance into your vendor management is vital for SOC 2 Third‑Party Risk compliance.

Key SOC 2 Requirements for Vendor Risk Management

SOC 2 treats third‑party risk as part of the broader control environment. The common criteria require management to assess and manage risks associated with vendors and business partners; specifically, CC9.2 states that “the entity assesses and manages risks associated with vendors and business partners”. During an audit, the examiner will ask how you inventory vendors, evaluate their security posture, monitor their performance and integrate them into your incident response plan. Below are the core requirements.

Vendor Inventory and Classification

A programme starts with a living inventory of all vendors and sub‑service organisations. The FRC’s TPRM guide emphasises that an organisation cannot manage risk it does not see; therefore the first step is to develop and maintain an exhaustive inventory of all third‑party relationships. For each vendor, record the services provided, data types accessed and the criticality to your business. Classify vendors by risk tier: high‑impact vendors (e.g., cloud hosting, payment processors, analytics platforms) warrant deeper assessments, while low‑impact vendors (e.g., office supplies) require minimal scrutiny. Some teams use categories such as Critical, High, Medium and Low based on factors like data sensitivity, regulatory requirements, and operational dependence. The classification drives the level of due diligence and monitoring.

Risk Assessment Before Onboarding

Before signing a contract, evaluate each vendor’s security controls. FRC notes that agencies should conduct due diligence and pre‑contractual assessments, including questionnaires, review of previous audit reports, and use of security rating tools to quantify real‑time posture. For SOC 2, this means gathering evidence such as:

• Vendor SOC 2 or ISO 27001 reports to verify independent attestation.
  
  
• Security questionnaires covering policies, procedures, encryption, access management and incident response.
  
  
• Documentation of previous incidents and how they were handled.
  
  
• Mapping of vendor controls to your own controls—for example, verifying that the vendor enforces multi‑factor authentication, performs background checks and logs system access.

Assign a risk score based on the vendor’s control maturity, data access level and incident history. You might rate each category on a scale (1 to 5) and compute a weighted score. Vendors with higher scores may be approved only after remediation or may require additional contractual safeguards.

Monitoring and Review

Vendor risk is not a one‑time assessment. FRC’s fifth step in the TPRM lifecycle calls for continuous monitoring: monthly or quarterly reviews of vulnerability reports, tracking remediation of open issues, and real‑time alerts for new threats. Linford & Co. emphasises that organisations should periodically assess vendor performance and review the most current SOC 2 report, perform security reviews and monitor performance against service levels. Establish a schedule based on vendor tier: high‑risk vendors may require quarterly reviews and an annual onsite assessment; low‑risk vendors may require only annual certification updates.

Monitoring should include:

• Contracted Service Level Metrics: Are uptime and support commitments being met?
  
  
• Security Incidents: Did the vendor experience any incidents? Were they promptly reported and remediated?
  
  
• Control Changes: Have there been major changes to the vendor’s systems or processes that could affect your risk? For example, new infrastructure, acquisitions or regulatory changes.
  
  
• Compliance Evidence: Are the vendor’s SOC 2, ISO 27001, HIPAA or GDPR attestations current? Do they cover the services you use?

Document each review and keep evidence ready for auditors. A centralised tool or dedicated managed service can help track reviews, findings and remediation.

Control Environment and Security Controls

Auditors will evaluate the effectiveness of your controls as they relate to vendors. A strong control environment includes policies, procedures and technical safeguards. Examples include:

• Access Control: Vendors should only access what they need. Use the principle of least privilege, multi‑factor authentication and periodic access reviews. Drata notes that logical and physical access controls (CC6) restrict who can access systems.
  
  
• Encryption: Data in transit and at rest should be encrypted, especially when shared with vendors or stored on their systems.
  
  
• Event Logging and Monitoring: Ensure that vendor activities are logged and that you receive event logs for your own analysis. System operations (CC7) cover event monitoring and incident response.
  
  
• Change Management: Vendors should follow documented processes for system changes. CC8 requires that changes follow a secure and documented process.
  
  
• Incident Response and Notification: Contracts should specify notification timelines and cooperation. The vendor must participate in drills and share incident reports.
  
  
• Risk Mitigation and Continuity: Develop contingency plans for vendor failure. Risk mitigation criteria (CC9) emphasise contingency planning and asset protection.

By mapping your vendor controls to the SOC 2 criteria and documenting evidence, you can show auditors that you manage third‑party risk systematically.

SOC 2 Third‑Party Risk Walkthrough

A real‑world vendor risk programme follows a lifecycle that aligns with procurement, security and compliance. Below is a step‑by‑step walkthrough that enterprise sellers can adopt.

Step 1: Define Vendor Security Policy

Start by documenting your organisation’s vendor security policy. This policy should specify:

• Vendor Tiers: Use your classification scheme (Critical, High, Medium, Low) and define which roles can approve each tier. For example, critical vendors require executive approval, while low‑risk ones can be approved by department heads.
  
  
• Minimum Security Requirements: List mandatory controls such as encryption, multi‑factor authentication, background checks and evidence of independent audits (SOC 2, ISO 27001, HIPAA or GDPR). These requirements should align with the SOC 2 common criteria and any regulatory obligations.
  
  
• Approval Gates: Define when a vendor can be used (e.g., after risk assessment is complete and contract is signed) and when exceptions can be granted (e.g., urgent purchase with limited data exposure).
  
  
• Documentation Requirements: Specify what documentation vendors must provide (e.g., audit reports, questionnaires, penetration test results) and where it is stored.

This policy sets the tone for consistent evaluations and reduces ad‑hoc decisions.

Step 2: Vendor Onboarding and Due Diligence

When a new vendor is proposed, follow an onboarding workflow that enforces your policy. A sample onboarding checklist might include:

1. Basic Information: Collect vendor name, services offered, points of contact, data types accessed and jurisdictions where data will be processed.
   
   
2. Compliance Documents: Request copies of SOC 2 Type II reports, ISO 27001 certificates, HIPAA Business Associate Agreements, GDPR Data Processing Agreements and any other relevant certifications. Verify the scope and observation period.
   
   
3. Security Questionnaire: Use a structured questionnaire to assess policies, incident response, encryption, access control, vulnerability management and security training. Tools can automate this process and produce scoring.
   
   
4. Risk Tiering: Based on the information gathered, assign a risk tier. High‑risk vendors may require deeper audits or onsite assessments; low‑risk vendors may move directly to contract.
   
   
5. Reference Checks: For critical providers, check references or request third‑party security ratings.
   
   
6. Internal Sign‑Off: Obtain approval from the relevant stakeholders (security, compliance, procurement and legal) before engaging the vendor.

Document each step and keep evidence ready. FRC notes that due diligence should involve questionnaires, artifact review and security ratings.

Step 3: Risk Assessment Template

A structured risk assessment template streamlines evaluations and makes them repeatable. A typical template might include:

• Vendor Information: Name, address, contact details, services provided and regulatory obligations.
  
  
• Data Access Level: What data will the vendor access? Categories might include personal data, financial data, protected health information or intellectual property.
  
  
• Control Map: Describe the vendor’s controls across the SOC 2 common criteria. Note whether each control is Implemented, Partially Implemented or Not Implemented. If a SOC 2 or ISO 27001 report is available, reference the section and testing period.
  
  
• Risk Score: Rate each area (e.g., access control, encryption, incident response) on a scale of 1 to 5. Use a weighting system to prioritise critical controls. The overall score will inform approval decisions.
  
  
• Remediation Plan: For gaps identified, outline remediation steps and timelines. High‑risk gaps may require contract clauses or disqualification; low‑risk gaps may be accepted with monitoring.

Using a template reduces subjective assessments and ensures that every vendor is evaluated consistently.

Step 4: Contracting and Security Clauses

Contracts are the primary mechanism for enforcing security requirements. Ensure that your contracts include:

• Security Obligations: Require vendors to implement controls aligned with SOC 2 and any other applicable frameworks. Specify minimum encryption standards, access management practices, vulnerability management and training.
  
  
• Audit Rights: Reserve the right to review the vendor’s audit reports, request evidence or conduct onsite inspections. Include a clause requiring the vendor to notify you of any changes that affect compliance.
  
  
• Incident Notification: Define what constitutes a security incident and require notification within a specified timeframe (e.g., 24 hours). State that the vendor must provide a detailed incident report and cooperate in investigations.
  
  
• Data Return and Deletion: Require vendors to return or securely delete your data upon termination. Linford & Co. notes that termination procedures should ensure that all data is returned or deleted and access is revoked.
  
  
• Flow‑Down Requirements: If the vendor uses subcontractors, require them to meet the same standards. FRC emphasises that contracts should mandate that prime contractors enforce security requirements on their sub‑suppliers.
  
  
• Liability and Indemnification: Allocate responsibility for damages arising from the vendor’s negligence or security failures.

By embedding these clauses, you align legal obligations with security objectives.

Step 5: Continuous Monitoring

Once a vendor is onboarded, maintain ongoing oversight. This involves:

• Regular Reviews: Schedule reviews based on vendor tier. High‑risk vendors may require quarterly reviews; moderate‑risk vendors may be reviewed semi‑annually; low‑risk vendors annually. Review updated SOC 2 reports, vulnerability scans and compliance certificates.
  
  
• Automated Monitoring: Use tools to track security posture, watch for new vulnerabilities or breaches, and receive alerts when the vendor appears on threat intelligence feeds. Many organisations use security rating services or managed compliance platforms.
  
  
• Performance Scorecards: Maintain a scorecard showing the vendor’s current risk score, incident history, SLA performance and compliance status. Share the scorecard internally to support decisions about renewal or termination.
  
  
• Documentation Updates: Keep risk assessments, questionnaires and contracts up to date. Record any control changes or new risks.

Continuous monitoring demonstrates to auditors and buyers that you manage vendor risk proactively. It also helps catch issues before they impact your clients.

Step 6: Incident Response and Escalation

Vendors must be integrated into your incident response plan. A good incident response template should define:

• Roles and Responsibilities: Identify who at your organisation and the vendor will manage incidents, including escalation contacts and decision‑makers.
  
  
• Communication Flow: Outline how incidents are reported, escalated and communicated internally and externally. Include contact information, timeframes and any regulatory reporting requirements.
  
  
• Investigation and Containment: Define how teams coordinate to investigate the cause, contain the incident and prevent further damage.
  
  
• Remediation and Root‑Cause Analysis: After containment, require a root‑cause analysis and remediation plan. Document the lessons learned and update processes.
  
  
• Testing and Drills: Conduct joint incident drills with vendors to test procedures and improve readiness.

By aligning your incident response plan with vendors, you reduce confusion during real incidents and demonstrate operational maturity.

Templates You Can Use

Below are sample templates that sellers can adapt. They serve as starting points and should be customized to your organisation’s needs.

Vendor Risk Assessment Template

Vendor Onboarding Checklist

Monitoring & Review Schedule

These templates provide a framework for consistent documentation. Adjust the categories and frequencies to match your risk tolerance and contractual obligations.

Best Practices for SOC 2 Third‑Party Risk

1. Align risk assessments with buyer expectations. Understand what enterprise clients expect from your security programme—access reviews, vulnerability management, incident response and vendor oversight. Map your assessments and controls directly to those expectations.
   
   
2. Use centralised tools or managed services. A central platform or a human‑led managed service like Konfirmity can track vendor inventories, assessments, evidence and remediation. This reduces manual effort, eliminates spreadsheet errors and ensures nothing falls through the cracks.
   
   
3. Maintain audit‑ready evidence. For every vendor, keep copies of questionnaires, risk assessments, signed contracts, monitoring reports and incident logs. Ensure that documents are version‑controlled and accessible. During audits, you will need to provide evidence that you conducted reviews at the stated frequency and addressed issues promptly.
   
   
4. Integrate vendor management into everyday processes. Instead of treating vendor risk as an annual exercise, embed it into procurement, engineering and legal workflows. Require vendor approvals before procurement, integrate risk scoring into purchasing systems and enforce contract clauses through legal templates.
   
   
5. Educate internal stakeholders. Train procurement, engineering and product teams on the vendor policy and the significance of SOC 2 Third‑Party Risk. When everyone understands the stakes, compliance becomes a shared responsibility rather than a bottleneck.

Conclusion

As enterprises demand stronger assurance, managing SOC 2 Third‑Party Risk becomes critical for every seller. The cost of a data breach—US$4.44 million globally, US$10.22 million in the U.S.—underscores the consequences of weak vendor oversight. A SOC 2 report is not just a certificate; it is a reflection of how well you design and operate controls across your entire service chain. By building a clear vendor security policy, performing structured risk assessments, embedding security clauses in contracts, monitoring vendors continuously and integrating them into your incident response plan, you can satisfy auditors and win the trust of buyers. Konfirmity’s experience across 6,000 audits shows that when security comes first, compliance follows naturally. Focus on real control implementation and continuous evidence instead of chasing checklists. The payoff is faster sales cycles, fewer audit findings and stronger resilience.

FAQ

1) What is an example of a third‑party risk? 

A payroll provider storing employee Social Security numbers suffers a breach. Attackers exploit weak access controls at the provider to steal sensitive data. The breach exposes your employees’ information and could result in fines, identity theft and reputational damage. IBM’s 2025 report highlighted how machine‑generated phishing campaigns and shadow machine tools were used in 16% and 20% of breaches respectively, illustrating how vendors can be exploited.

2) What are the third‑party risks of cybersecurity? 

Third‑party risks include unauthorized data access, exploitation of vulnerabilities in vendor systems, weak authentication practices, delays in incident detection, and non‑compliance with security standards. NIST warns that supply‑chain products may contain malicious functionality, be counterfeit or lack proper development practices. These risks can lead to data breaches, service outages, regulatory penalties and loss of customer trust.

3) What are the five criteria for SOC 2? 

The five Trust Services Criteria are Security, Availability, Processing Integrity, Confidentiality and Privacy. Security is mandatory; it covers control environment, risk assessment, monitoring, control activities, access controls, system operations, change management and risk mitigation. Availability focuses on capacity management and recovery; Processing Integrity ensures that systems process data accurately and completely; Confidentiality requires data classification and protection mechanisms; and Privacy governs notice, consent, collection, use, retention, disposal, access, disclosure and quality of personal data.

4) What is the NIST standard for third‑party risk management? 

NIST’s Special Publication 800‑161 Rev 1 provides guidance on Cybersecurity Supply Chain Risk Management. The publication explains that organisations are concerned about risks associated with products and services that may contain malicious functionality or be vulnerable due to poor development practices. It advises integrating supply‑chain risk management into overall risk activities by developing policies, plans and risk assessments for suppliers. Using NIST’s guidance helps organisations identify, assess and mitigate third‑party risks across all levels of the supply chain.