The conventional wisdom says that if you conduct thorough annual vendor assessments, maintain a supplier risk register, and collect SOC 2 reports from your critical providers, you've done your job managing third-party risk. ISO/IEC 27001 Clause 15.1 requires you to manage information security in supplier relationships. You've got the spreadsheets. You've got the signed questionnaires. Box checked.
Here's the problem: that approach was designed for a world that no longer exists.
Why Annual Reviews Are Dangerously Outdated
Your third-party risk program assumes suppliers are relatively static entities. You assess them once a year, maybe quarterly if they're critical. You review their controls documentation, verify their certifications, and move on.
But modern infrastructure doesn't work that way anymore. A supplier that looked acceptable during your yearly review can become a material operational dependency within weeks. Routing decisions change continuously. Cloud dependencies shift. API integrations proliferate. Automated remediation tools make configuration changes without human approval. The vendor-hosted control plane you assessed six months ago may route through entirely different infrastructure today.
When Verizon experienced a massive outage in January affecting millions of users, it wasn't due to a cyberattack. It was a software issue, one that internet monitoring company Cisco ThousandEyes described as one of the most significant connectivity interruptions in recent history. The root cause wasn't Verizon's core network failing. It was the interconnected ecosystem of suppliers, cloud services, software vendors, and managed infrastructure partners that modern telecoms depend on.
Your annual assessment wouldn't have caught it. Neither would your SOC 2 report review.
The Evidence: Governance Models Built for the Wrong Problem
Most organizations still lack real-time visibility across their dependencies. They're using governance models that weren't designed for this level of complexity. Consider what your third-party risk assessment actually measures:
- Point-in-time control effectiveness
- Historical incident rates
- Compliance certifications that may be 6-12 months old
- Self-reported questionnaire responses
What it doesn't measure:
- Real-time dependency chains
- Configuration drift across interconnected systems
- The speed at which automated systems can propagate failures
- Whether your supplier's supplier just introduced a critical vulnerability
The Network and Information Systems 2 Directive (NIS2) and the EU Digital and Operational Resilience Act (DORA) both recognize this gap. They require continuous oversight and stronger supplier accountability, not annual checkboxes. They demand integrated incident response across the supply chain. The regulations are catching up to the technical reality that your compliance program hasn't.
Automated systems can implement changes at speeds that leave little time for human intervention. Configuration errors or failures propagate across interconnected environments much faster than they could a decade ago. AI and automation compress the time between cause and consequence. Your annual review cycle can't keep pace with infrastructure that changes by the hour.
What to Do Instead: Continuous Visibility and Structural Control
You need to shift from periodic assessment to continuous monitoring of your critical dependencies. This doesn't mean abandoning annual reviews entirely, but it does mean acknowledging their limitations.
Map your real-time dependency chains. Not just your direct vendors, but the infrastructure those vendors depend on. If your SaaS provider runs on AWS, and AWS has a regional dependency on a specific data center provider, you need visibility into that chain. Document these relationships in your ISMS as part of your Clause 15.1 supplier controls, but update them continuously, not annually.
Implement technical redundancy at the architectural level. Multi-site deployments eliminate single points of failure. Geographic distribution of critical infrastructure provides failover capability. Hybrid models combining cloud and private infrastructure give you options when one dependency fails. These are preventive controls that reduce your exposure before an incident occurs.
Establish direct interconnection wherever possible. More direct connections between networks, cloud providers, and digital services reduce the number of intermediary points where failures can occur. Fewer hops mean fewer opportunities for cascade failures. It also enables faster communication between organizations when issues arise.
Require supplier transparency about their dependencies. Your SOC 2 Type II report should include Complementary Subservice Organization Controls that identify critical dependencies. Push for real-time status pages and incident notification channels. If a supplier can't tell you what their infrastructure depends on, they can't help you assess your actual risk.
Test your integrated incident response. ISO/IEC 27035 covers incident management, but most organizations only test internal response. Run tabletop exercises that assume a critical supplier failure. Can you identify the problem? Can you communicate with the supplier effectively? Can you fail over to redundant systems? Document these scenarios in your business continuity plans per ISO 22301.
When the Conventional Wisdom IS Right
Annual vendor assessments still have value. They establish baseline expectations. They verify certifications and compliance status. They create accountability through contractual obligations. For low-risk suppliers or those providing non-critical services, annual reviews remain appropriate and cost-effective.
ISO/IEC 27001 Clause 15.1 doesn't specify assessment frequency, which means you can tailor your approach based on criticality. Your less critical suppliers don't need continuous monitoring. Your payment processor that handles transactions twice a month doesn't require the same oversight as your authentication provider that routes every user login.
The conventional approach also works when you have genuine control over the relationship. If you're dictating security requirements and conducting regular audits with enforcement mechanisms, periodic assessment makes sense. The problem is that most organizations don't have that level of control over their critical infrastructure providers.
The shift from perimeter-based security to ecosystem-wide resilience isn't just a technical challenge. It's a compliance challenge that requires rethinking how you implement supplier risk management controls. Your ISMS needs to account for the reality that resilience is no longer measured by how robust your own network is, but by how effectively you can anticipate, withstand, and recover from disruption anywhere in your dependency chain.
The question isn't whether your third-party risk program meets the letter of ISO/IEC 27001 Clause 15.1. It's whether that program actually prevents the next outage.
