May 8, 2026

Third-Party Data Breaches: A Guide for Audit Professionals

Amanda Waldmann

Increasing trust with AI for audit and advisory firms.

Third-party breaches are reshaping how audit professionals evaluate vendor risk. Clients are no longer satisfied with questionnaires alone. They expect auditors to test whether vendor controls actually operate as intended and to identify risk between reporting periods, not just at year-end.

Partners need procedures that validate vendor SOC 2 reports and continuous monitoring mechanisms rather than accepting point-in-time assessments at face value. This shift stems from third parties now accounting for a material concentration of breach risk across client vendor ecosystems.

This guide examines how audit and advisory professionals should assess vendor risk management programs, test SOC 2 controls, and advise clients on framework-aligned preventive measures.

What are third-party data breaches?

Third-party data breaches occur when threat actors compromise an organization through its vendor ecosystem rather than direct attack. They can exploit various entry points: managed service providers with privileged network access, file transfer applications processing sensitive data, or software vendors distributing compromised updates.

These breaches differ from direct attacks in both scope and impact. When a vendor is compromised, multiple client organizations may be affected at the same time. Audit teams must account for the downstream implications across the vendor’s customer base, not just a single engagement.

Why are third-party breaches surging?

Third parties account for 15% of all breaches, representing a 68% year-over-year increase. This surge stems from four converging factors that create concentrated attack surfaces across vendor ecosystems.

File transfer applications as attack vectors: Tools deployed for compliance purposes become primary targets. The CL0P ransomware group exploited a previously unknown vulnerability in MOVEit Transfer during May 2023, and tens of millions of individuals across thousands of organizations were affected.
Digital interdependence: A single compromised vendor serving multiple organizations within a sector creates systemic exposure requiring coordinated incident response at industry scale.
Asymmetric security maturity: Vendor security gaps can undermine enterprise security programs, particularly when risk assessments rely on point-in-time validation. NIST CSF 2.0 reflects this reality by elevating supply chain risk management to a core governance responsibility.
Sophisticated threat actors: Organized cybercrime demonstrates capabilities that standard security controls struggle to defend against. The SolarWinds attack required multi-year pre-positioning, code-level manipulation, and exploitation of software update mechanisms to achieve broad compromise.

These factors require audit professionals to expand vendor testing beyond annual questionnaires and point-in-time SOC report reviews.

How should audit professionals assess third-party risk?

Effective vendor risk assessment requires structured testing across the complete relationship lifecycle.

Vendor due diligence and contract testing

Begin by reviewing the organization’s vendor inventory and how vendor criticality is defined. Use risk-based judgment to focus testing on vendors with elevated access or sensitive data exposure, and validate inventory completeness using independent evidence rather than management assertions alone. Fieldguide's platform can centralize this inventory and support risk stratification.

For sampled vendors, review risk assessments, security questionnaires, and SOC 2 reports. Verify contracts align with NIST SP 800-53 Rev 5 controls and include:

Right-to-audit clauses permitting SOC 2 Type II report requests aligned with AICPA Trust Services Criteria CC9.2
Specific security requirements mapped to NIST SP 800-53 control families (SA-4, SA-9, AC-20)
Incident notification requirements with defined timeframes
Business continuity commitments with documented RTO and RPO specifications aligned with NIST CP-2 and CP-9
Termination provisions including secure data destruction procedures compliant with NIST SI-16

These contractual requirements establish baseline expectations for vendor security management and provide enforcement mechanisms when gaps emerge.

Document any missing contractual provisions as potential control gaps requiring management attention or inclusion in the management letter.

Continuous monitoring and incident response testing

Review the monitoring cadence to confirm it reflects vendor risk and covers the full vendor population. Assess how vendor issues are tracked, resolved, and reported, and verify that escalation procedures are followed when risk thresholds are exceeded.

For incident response, test alignment with NIST SP 800-53 IR-3 and applicable SOC 2 Trust Services Criteria, including CC7.3. Confirm that vendor-specific response procedures are documented, notification and response protocols operate as designed, and past vendor incidents were handled appropriately, with clear root cause analysis and defined response timelines.

What are the key warning signs of inadequate vendor risk management?

Incomplete vendor inventories represent the most fundamental control deficiency. Organizations cannot manage risks they haven't identified, so look for absence of centralized vendor registries, untracked shadow IT relationships, and missing risk classification schemes. When inventories do exist, assessment dates showing two or more years since last review for critical vendors signal inadequate monitoring frequency.

Even organizations with current inventories often lack adequate contractual protections, creating both legal and operational exposure. Missing right-to-audit clauses limit oversight capabilities, absence of specific security requirements eliminates enforcement mechanisms, and lack of incident notification requirements with defined timeframes leaves organizations dependent on vendor discretion. Contractual requirements specifying incident notification timeframes and procedures are essential controls.

Contractual gaps often extend to fourth-party relationships as well. Complete absence of vendor subcontractor inventories and missing concentration risk analysis indicate systematic underestimation of supply chain depth, a critical governance gap given how breaches like MOVEit propagated through interconnected vendor networks.

How can organizations prevent third-party breaches?

Preventing third-party breaches depends on disciplined access management, clear ownership of vendor risk, and ongoing visibility into vendor security posture. The following controls address the root causes identified in recent third-party breaches: compromised credentials, inadequate vendor oversight, and delayed detection.

Enforce multi-factor authentication for vendor access

Compromised credentials remain a primary attack vector for third-party breaches. Mandate multi-factor authentication for all vendor access without exception, requiring MFA for remote access connections and implementing phishing-resistant methods including FIDO2 or hardware tokens for privileged access.

Block legacy authentication protocols that cannot support MFA and include MFA requirements as non-negotiable contract terms. IBM's Cost of a Data Breach Report indicates that organizations extensively using security AI and automation saw average breach costs roughly USD 2.2 million lower than those without such tools, largely due to faster detection and response.

Implement structured service provider management

Access controls alone cannot address inadequate vendor oversight. Establish comprehensive service provider management programs that align with NIST CSF 2.0 governance and supply chain risk management (GV.SC) guidance. Conduct risk assessments before vendor onboarding using standardized criteria, define vendor risk tiers based on data access and system criticality, and use periodic security questionnaires with validation procedures.

Review vendor SOC 2 Type II reports and relevant attestations annually at minimum, and maintain a centralized vendor inventory with current risk ratings and compliance status.

Deploy automated evidence collection

Point-in-time assessments cannot detect the security posture degradation that precedes many breaches. Deploy automated evidence collection systems with API integrations to vendor security systems, establishing real-time security data feeds for continuous compliance monitoring.

Create automated workflows for evidence review and exception handling, configure alerts for security posture degradation or missing evidence submissions, and generate automated compliance dashboards with executive-level summaries.

Third-party risk management and SOC 2 compliance

Testing vendor management controls under SOC 2 engagements requires specific procedures aligned with Trust Services Criteria.

Testing CC9.2 vendor management controls

Trust Services Criterion CC9.2 focuses on how organizations identify, assess, and monitor risks associated with vendors and business partners that have access to systems or data.

In SOC 2 Type II engagements, testing is generally performed using risk-based sampling across the audit period to evaluate both control design and operating effectiveness. Auditors are not expected to test the full population or every point in time. Instead, sampling approaches should reflect the assessed level of risk and professional judgment.

Testing typically starts with an evaluation of the complete vendor inventory and how vendor criticality is defined. Sample selection should emphasize higher-risk vendors, with evidence supporting initial due diligence activities such as risk assessments, security questionnaires, and approval records. For Type II engagements, auditors should obtain evidence that vendor management controls operated consistently throughout the period and that assessment frequency aligned with documented policy for each vendor risk tier.

Sampling from multiple points in the period is generally sufficient to demonstrate consistency. Fieldguide’s evidence tracking workflows support this approach by organizing and documenting risk-based sampling without adding manual effort.

Evaluating subservice organizations and SOC reports

When vendors meet the definition of service organizations and are included in the service description and scope, current SOC 1 Type II or SOC 2 Type II reports are typically used as evidence. The report period should cover, or at least overlap with, the audit period to support reliance.

Audit evidence should also reflect management’s identification of subservice organizations, disclosure of complementary user entity controls (CUECs), and evaluation of any control gaps or exceptions noted in the SOC report. Where reliance on user entity controls is necessary, auditors should determine whether sufficient evidence exists that those controls were designed and implemented. Additional procedures may be required depending on the level of risk and the nature of any identified exceptions.

Assessing CC3.2 control activities

Trust Services Criterion CC3.2 focuses on the control activities organizations use to mitigate vendor-related risks. It aligns with COSO Principle 10 and relevant NIST SP 800-53 controls, including SA-4 and SA-9, which address acquisition and external service provider management.

Audit procedures typically consider whether these control activities address key vendor risk areas, such as financial stability, security and operational exposure, technology risk, and vendor lifecycle management. Controls should collectively support vendor selection, onboarding, contract oversight, ongoing monitoring, and offboarding in a manner that is consistent with the organization’s risk profile.

Privacy-specific testing under P6.4

Privacy engagements involve additional considerations under Trust Services Criterion P6.4, supported by vendor and business partner risk management controls in CC9.2.

Vendor contracts should reflect appropriate privacy protections, including limits on how personal information is processed, requirements for sub-processor notification and approval, support for data subject rights, and safeguards for international data transfers where required by law or customer agreements.

Evidence should demonstrate that privacy impact assessments were completed before personal information was shared with vendors. This documentation typically outlines the types of data involved, processing purposes, retention periods, and identified privacy risks.

Sub-processor oversight is another common focus area. Organizations are expected to maintain current sub-processor inventories, document notification procedures for changes, and retain evidence of approval or objection before new sub-processors are engaged.

Executed data processing agreements: Privacy-specific terms where applicable
Completed privacy impact assessments: For vendor relationships involving personal information
Sub-processor inventories: Including change notification records
Vendor privacy certifications: Such as EU-U.S. Data Privacy Framework certification

Missing or incomplete privacy documentation for vendor relationships represents a reportable deficiency requiring management attention before the engagement concludes.

Streamline vendor risk management with Fieldguide

Third-party risk management continues to evolve as threat actors develop more sophisticated supply chain attacks. Firms that move beyond point-in-time vendor assessments are better positioned to deliver higher-value advisory work and respond to client questions with confidence throughout the year.

The shift from annual vendor questionnaires to real-time security data feeds creates opportunities for firms to deliver ongoing vendor oversight rather than point-in-time assessments.

Fieldguide's engagement automation platform helps firms transition from manual vendor tracking to streamlined evidence collection. Practitioners map security questionnaires, SOC reports, and risk assessments to Trust Services Criteria and NIST control families using pre-built framework libraries, while the platform centralizes documentation and tracks completion status. Partners managing multiple concurrent SOC 2 engagements gain real-time visibility into which vendors have complete documentation and which require follow-up, enabling focus on risk analysis and client advisory rather than administrative coordination.