Why Third-Party Risk Is a First-Party Problem
Organizations increasingly depend on vendors, managed service providers, SaaS platforms, and contractors who have access to their systems, networks, and data. When any of these vendors is compromised, the attackers potentially have access to every customer of that vendor. The SolarWinds attack affected thousands of organizations because a trusted software update mechanism was compromised. MSP-targeting ransomware campaigns have encrypted networks of dozens of businesses simultaneously through a single compromised MSP tool. Your security posture is only as strong as the weakest link in your supply chain.
Third-Party Risk Assessment Framework
- Inventory your vendors: Identify every third party with access to your systems, data, or networks. This is harder than it sounds; most organizations discover vendors during an assessment that they had forgotten about.
- Classify by risk level: Tier vendors based on the access they have and the data they can reach. A SaaS tool for expense reports is lower risk than an MSP with domain administrator access.
- Collect security documentation: Require SOC 2 reports, penetration test attestation letters, or completion of a security questionnaire from high-risk vendors. For critical vendors, consider independent assessment.
- Contractual protections: Security requirements, breach notification timelines, right to audit, and data handling obligations should be in vendor contracts.
- Limit access: Third parties should have the minimum access needed to perform their function. Broad network access for a vendor who needs to reach two servers is a liability, not a convenience.
- Review regularly: Vendor relationships change. Access that was granted for a specific project should be revoked when the project ends. Annual vendor access reviews prevent accumulation of unnecessary third-party exposure.
Asking Your Vendors About Penetration Testing
For high-risk vendors, asking whether they conduct annual independent penetration testing, and requesting the attestation letter as evidence, is reasonable due diligence. Vendors who cannot demonstrate a current security testing program represent elevated risk. Organizations subject to NYDFS specifically must address third-party service provider risk as part of their cybersecurity program.
Building a Vendor Assessment Cadence
Third-party risk is not a one-time review. Tier your vendors by the access and data they hold, assess the highest-risk ones before onboarding and on a regular cycle after, and require evidence of their own security testing rather than a checkbox self-attestation. Contract language should reserve the right to review controls and require breach notification. A repeatable cadence keeps the vendors most able to hurt you under continuous, proportionate scrutiny.
Frequently Asked Questions
What is third-party risk management?
Third-party risk management is the process of identifying, assessing, and monitoring the security of vendors and partners who access your data or systems. A breach at a vendor becomes your breach, so their controls are effectively part of your risk.
What should I ask vendors about penetration testing?
Ask whether they perform independent penetration testing at least annually, request an attestation or summary as evidence, and confirm how they remediate findings. A vendor that cannot show current testing is a risk you are inheriting.
Why is third-party risk a first-party problem?
Attackers target the weakest link, and that is often a smaller vendor with access to your environment. When their compromise exposes your data, your organization bears the regulatory, financial, and reputational cost, so their security is your concern.
Demonstrate your own security posture to your clients.
Grid32 provides the penetration testing and attestation documentation that your clients and partners may require as part of their vendor due diligence process.
Get a Quote →