Skip to main content
Should You Own Third-Party Contractor Security, or Just Audit It?Breach & Risk Assessment
3 min readFor Data Governance Teams

Should You Own Third-Party Contractor Security, or Just Audit It?

The Question at Hand

The AdaptHealth breach, which affected over 4 million individuals, began with a social engineering attack on a third-party contractor's user session. This contractor had access to AdaptHealth's cloud-based applications, including patient management systems. The breach occurred because someone at the contractor's end made a mistake.

This incident raises a critical question: Should you have direct control over contractor security practices, or is periodic auditing and contractual language enough? One view argues you can't delegate accountability for data protection. The other suggests micromanaging vendors undermines the efficiency that led you to hire them.

The stakes are high. When a contractor's compromised session leads to a breach notification to the Department of Health and Human Services (HHS), you're the one explaining it to regulators and affected individuals.

The Case for Direct Control

Advocates for direct involvement highlight that GDPR Article 28 and HIPAA's Business Associate Agreement requirements make you liable for your processor's failures. If your contractor gets phished and your patient data is compromised, you're still responsible for notifying your Supervisory Authority within 72 hours.

This approach includes:

  • Mandatory security controls in contracts. Specify requirements like multi-factor authentication (MFA) on all administrative accounts, session timeout limits, and annual penetration testing.
  • Real-time monitoring integration. Your contractor's security events should feed into your Security Information and Event Management (SIEM) system.
  • Joint incident response planning. Contractors should participate in your tabletop exercises and integrate their breach response plans with yours.
  • Continuous validation. Require quarterly vulnerability scans and monthly access reviews to ensure controls are active.

The core argument is that you can't audit your way out of a compromised session. By the time you discover a gap, the breach has already occurred.

The Case for Auditing and Boundaries

The opposing view warns that direct control can create unforeseen issues.

  • You don't scale. Real-time monitoring for every contractor means building custom SIEM connectors for various vendors.
  • You create compliance theater. Mandating specific controls may lead contractors to implement technologies they don't understand.
  • You assume you know their environment better than they do. Prescriptive requirements may not suit every contractor's unique environment.
  • You blur accountability. Dictating specific implementations can shift accountability to you if issues arise.

This camp prefers:

  • Outcome-based contract language. Require protection of confidentiality, integrity, and availability, and let contractors determine how to meet these requirements.
  • Risk-based due diligence. Reserve intensive oversight for high-risk relationships.
  • Certification and attestation. Use industry certifications like SOC 2 Type II as independent validation.
  • Clear breach notification requirements. Define "immediate" notification in hours, not days, and require specific information in initial reports.

Where Practitioners Actually Land

Most teams operate between these extremes, adjusting based on the contractor's role.

For contractors with administrative access to sensitive systems, teams often demand direct control. MFA is mandatory, and access reviews are frequent. For those with limited data access, teams rely more on certifications and contractual obligations.

The AdaptHealth breach involved a contractor with significant access, placing it in the high-risk category where direct controls are preferred.

Our Take

Focus on controlling access, not implementation.

Dictate who can access your systems, under what conditions, and for how long. Require MFA and enforce session timeouts. Use your identity provider for access provisioning and deprovisioning. Monitor authentication events and flag anomalies.

Don't dictate antivirus software or firewall configurations. Instead, limit what an authenticated contractor session can do: enforce time-bound access, least-privilege permissions, and monitor for unusual data access patterns.

You can't eliminate contractor risk, but you can contain it by treating contractor access as a privileged operation. The contractor's internal security practices matter less when their compromised credentials can't exfiltrate your data.

You Might Also Like