Why Security Isn't Enough: The Evolution of Third-Party Risk

On July 19, 2024, a routine software update from CrowdStrike took down 8.5 million Windows computers worldwide. CrowdStrike is one of the most trusted names in cybersecurity. Airlines grounded flights. Hospitals canceled surgeries. Banks couldn't process transactions. Emergency services went offline.

Those of us in the industry saw the irony of the situation: a security vendor caused one of the largest operational disruptions in recent history. But here's what made it interesting for third-party risk management. CrowdStrike would have aced every security assessment.

Their security controls were excellent. Their certifications were current. Their incident response procedures were documented. Their data protection practices were industry-leading. By every traditional measure, CrowdStrike looked great.

Yet, a bad deployment process brought down critical infrastructure globally and temporarily paralyzed entire industries.

The Blind Spot in Security-Focused TPRM

The CrowdStrike incident exposed what many TPRM professionals already suspected: there’s a massive blindspot in how most organizations think about risk.

Most TPRM programs emerged from information security teams and remain heavily focused on one question, "Will this vendor protect our data?" They send security questionnaires and review SOC 2 reports. They check for adequate encryption, access controls, and incident response plans.

These things matter and data breaches are real risks. However, while we've been perfecting the art of security assessments, vendor dependencies have fundamentally changed. Vendors aren't just handling our data anymore. They're running our operations. When they fail, the impact isn't a potential data breach. It's immediate business disruption and lost revenue.

CrowdStrike wasn't compromised. No data was stolen and no unauthorized access occurred. Still, the operational impact was catastrophic. We depend on vendors not only to be secure, but also to be reliable.

What Operational Risk Actually Looks Like

Security-focused TPRM programs miss entire categories of vendor risk that can shut down your business:

• Deployment Failures (like Crowdstrike’s): These happen when vendors push bad updates that break systems. Your security assessment won't catch this because it's not a security control issue. It's about software quality, testing procedures, and deployment practices.
• Performance Degradation: A vendor can meet all security requirements while delivering increasingly poor service quality. Issues like slow response times and frequent timeouts don't show up in security assessments, but they do directly impact customer experience.
• Change Management: Change management issues arise when vendors change ownership, pivot business models, discontinue products, or shift strategic focus. These changes can strand you on deprecated platforms or leave you with inadequate support regardless of their security posture.
• Cascading Dependencies: Your vendor depends on their vendors, who depend on other vendors, and so on. When AWS has an outage, it doesn't matter how secure your SaaS vendor is. Their service goes down anyway. Security assessments rarely map these dependency chains.

And More: A vendor can become unavailable for a multitude of reasons. Other common reasons for downtime include: infrastructure failures, capacity problems, configuration errors, etc. The common thread is that none of these risks show up in traditional security assessments, yet any of them can cause immediate business impact.

How to Actually Expand Beyond Security

Recognizing that operational risk matters is easy. Actually doing something about it is hard. Here's what expanding beyond security-focused TPRM looks like:

1. Negotiate Contract Terms That Address Operational Risk

Security requirements are usually well-covered in vendor contracts. Operational risk? Not so much. Contract language needs to expand beyond data protection to include several key areas.

• Deployment and Change Controls: Require vendors to notify you of significant updates in advance. For critical vendors, negotiate the right to opt out of automatic updates or to delay deployment until you've validated stability. Include requirements for vendor testing procedures and rollback plans.
• Operational Transparency: Mandate access to real-time status pages, performance dashboards, and incident notifications. Require vendors to disclose their own critical dependencies like their infrastructure providers. Get visibility into their operational health, not just their security posture.
• Business Continuity: Don't just ask if they have a business continuity plan. Require specifics about recovery time objectives, failover capabilities, and what happens during different failure scenarios. For critical vendors, audit these plans.
• Exit provisions: Plan for what happens if you need to leave or if the vendor fails. Data export rights are standard. Also negotiate transition support, service continuity during migration, and access to historical data.

2. Build SLAs That Protect Business Operations

SLAs typically focus on uptime percentages. But 99.9% uptime is meaningless if the vendor is down during your peak business hours or if "uptime" ignores performance problems.

• Customer Experience Metrics: Include metrics that reflect customer experience, not just technical availability. For example, response times, transaction completion rates, and error rates.
• Business-Adjusted Measurement: Include peak period guarantees with higher availability requirements during your critical business hours or seasonal peaks.
• Notification Requirements: Include incident notification requirements that specify how quickly vendors must notify you of issues and what information they must provide. Make incident transparency an SLA requirement.
• Measurement Transparency: Don't accept vendor-only measurement. Negotiate the right to independently monitor service quality or require third-party validation of SLA compliance.
• Meaningful Remedies: Service credits are nice, but they don't compensate for business impact. For critical vendors, negotiate graduated penalties and termination rights for repeated violations.

3. Monitor Continuously

Trying to manage operational risk with annual, or even quarterly assessments is a losing strategy. By the time you review a vendor's performance quarterly, you've already experienced three months of potential issues. Operational risk management requires continuous visibility.

• Real-time Monitoring: Track whether vendor services are actually up and performing acceptably with real-time availability monitoring. Don't wait for vendors to tell you there's a problem. Detect it yourself.
• Early Detection: Monitor latency, error rates, and service quality over time with performance tracking. Catch gradual degradation before it becomes critical.
• Trend Analysis: Collect and analyze vendor incidents to identify outage patterns. Three small outages per month signals a different risk profile than one major incident per year, even if total downtime is similar.
• Critical Dependency Mapping: Understand not just your direct vendors, but their critical dependencies through dependency mapping. When CrowdStrike went down, knowing they were critical to your operations wasn't enough. You needed to know how many of your vendors depended on them.

4. Partner with Vendors on Risk Mitigation

The best vendor risk management isn't adversarial. It's collaborative. Structure the partnership so both sides can identify risks early and fix them quickly.

• Shared Monitoring: Give vendors visibility into how their service performs in your environment. Share synthetic checks, SLOs, and error budgets so you are looking at the same facts.
• Continuous Feedback Loops: Track action items from reviews, verify fixes in monitoring, and adjust risk ratings based on observed performance.
• Capacity and Resilience Planning: Co-plan for growth, seasonal peaks, and failover. Run joint game days and pre-production update testing for critical changes.
• Preferred supplier programs (PSP): Formalize the collaboration for your most critical or strategic vendors. Define eligibility requirements for preferred suppliers, such as demonstrated SLA performance, transparent dependency mapping, and continuous telemetry sharing. Reward high-performing vendors with fast-tracked security reviews and onboarding.

The Cross Functional Shift

Security teams are great at assessing security risks, but effectively managing operational risk requires cross-functional collaboration.

Business owners ****understand which vendor services are critical and what constitutes acceptable performance. Operations teams are often responsible for monitoring vendor performance and addressing vendor issues. Procurement and legal negotiate the contracts and help put contractual protections in place.

Expanding beyond security means TPRM becomes cross-functional. Security still leads, but they're coordinating with stakeholders who have operational visibility.

Looking Beyond CrowdStrike

The CrowdStrike outage was a wake-up call. Many organizations learned a valuable lesson: security assessments are important, but they’re not sufficient.

Vendors need to be SORT: Secure, Operationally Resilient, and Transparent.

Traditional TPRM programs assess whether vendors are secure before you start using them. SORT TPRM programs monitor whether vendors are delivering reliable service once you’re critical business operations are already dependent on them.

That's the shift. From point-in-time security assessment to continuous operational risk management. From asking "are they secure?" to asking "will they keep my business running?"

The vendors that will take down your operations probably won't do it through security breaches. They'll do it through bad deployments, capacity problems, infrastructure failures, or cascading dependencies. The question is: Will your TPRM program catch those risks?

‍