The Problem: Why This Matters Now
Your ISO/IEC 27001 implementation isn't wrong. It's just incomplete.
The gap isn't in your access controls or encryption standards. It's in the assumption that ransomware is a perimeter defense problem you can solve with better firewalls and endpoint detection. Security Scorecard's 2025 review found that 41.4% of ransomware attacks now begin through third-party access. Your vendor's weak patch management becomes your incident. Your cloud provider's misconfigured S3 bucket becomes your breach notification.
The Karakurt prosecution in May revealed something compliance frameworks have been quietly acknowledging: these aren't opportunistic criminals. They're state-supported networks using government databases to intimidate victims and screen recruits. When Asahi Group's September 2025 incident forced up to 30 domestic plants offline, the malware didn't touch factory floors. It didn't need to. The IT systems coordinating orders and logistics went down, and the physical operations followed.
This isn't theoretical risk. It's operational reality that your current ISMS probably categorizes as "IT security" when it should be driving your business continuity planning.
What You Need Before Starting
You can't bolt ransomware resilience onto an existing ISMS as an afterthought. You need these pieces in place first:
Documented Supplier Inventory with Security Context
Not just a procurement list. You need every third party with access to your systems, data, or operational dependencies mapped to the assets they touch. If you're already maintaining an asset register per ISO/IEC 27001 Clause 8.1, extend it to include supplier relationships.
Current Business Impact Analysis
ISO 22301 requires this for continuity planning, but most organizations treat it as a compliance checkbox. You need realistic recovery time objectives that account for interdependent systems. If your order management system goes down, what stops working downstream?
Executive Sponsorship for Cross-Functional Work
Ransomware resilience lives at the intersection of IT, procurement, legal, and operations. Your CISO can't own this alone. You need a risk owner at the executive level who can enforce supplier security obligations in contracts and fund continuity testing that disrupts normal operations.
Baseline Controls Already Implemented
This playbook assumes you've got foundational organizational controls and technological controls in place. If you're still struggling with user lifecycle management or segregation of duties, fix those first.
Step-by-Step Implementation
Phase 1: Rewrite Your Supplier Security Controls (Weeks 1-4)
Start with ISO/IEC 27001 controls A.5.19 through A.5.23. These controls require you to document security requirements in supplier agreements and monitor supplier security practices.
Action 1: Audit your existing supplier contracts for security language. Most won't have enforceable security obligations beyond generic "industry standard" clauses.
Action 2: Draft a supplier security addendum template that includes:
- Specific controls the supplier must maintain (reference ISO/IEC 27001 Annex A controls by number)
- Incident notification timelines (24 hours is standard; adjust based on criticality)
- Right-to-audit provisions
- Subprocessor disclosure requirements
Action 3: Prioritize rollout based on supplier criticality. Don't try to renegotiate 200 contracts at once. Start with suppliers who have direct access to production systems or handle sensitive data.
Phase 2: Map Third-Party Risk to Business Impact (Weeks 5-8)
Your business impact analysis probably identifies critical systems. It probably doesn't identify which suppliers can take those systems down.
Action 1: For each critical system in your BIA, document:
- Which suppliers have access
- What access they have (administrative, read-only, API integration)
- Whether they can affect availability, integrity, or confidentiality
- What your recovery options are if that supplier is compromised
Action 2: Run scenario-based risk assessments for your top 10 critical suppliers. Don't ask "what if our supplier gets breached?" Ask "what if our supplier's access credentials are compromised and used to deploy ransomware in our environment?"
Action 3: Update your risk treatment plan to address identified gaps. This might mean requiring multi-factor authentication for all vendor access, implementing just-in-time privileged access for supplier accounts, or establishing contractual requirements for vendor security logging.
Phase 3: Integrate Continuity and Security Testing (Weeks 9-12)
ISO 22301 requires you to test your business continuity plans. ISO/IEC 27001 requires you to test your incident response procedures. Most organizations do these separately. That's a mistake.
Action 1: Design a tabletop exercise that simulates a vendor-originated ransomware incident. Include participants from IT, procurement, legal, and business operations. The scenario should force decisions about:
- When to invoke business continuity procedures
- How to communicate with the affected supplier
- Whether to pay a ransom (legal and procurement need to be in this conversation)
- How to restore operations when your vendor's systems are still compromised
Action 2: Document gaps identified during the exercise. Common findings: unclear escalation paths, no pre-approved crisis communication templates, no tested failover to backup suppliers.
Action 3: Schedule a technical recovery test within 30 days. Actually restore critical systems from backup while simulating loss of vendor access. Time it. If your recovery time objective is 24 hours and the test takes 72, you've got a gap to close.
Phase 4: Establish Ongoing Supplier Monitoring (Ongoing)
Supplier security isn't a one-time assessment. It's continuous monitoring.
Action 1: Implement automated security questionnaires for suppliers on an annual cycle. Tools like OneTrust or Vanta can automate distribution and track completion.
Action 2: Monitor for supplier security incidents. Subscribe to breach notification services or require suppliers to report security events within defined timeframes per your contract addendum.
Action 3: Review supplier access logs quarterly. Look for:
- Suppliers with standing access who haven't logged in recently (revoke it)
- Unusual access patterns (off-hours activity, geographic anomalies)
- Suppliers accessing systems outside their documented scope
Validation: How to Verify It Works
You can't verify resilience in a spreadsheet. You verify it under stress.
Test 1: Supplier Access Revocation Drill
Pick a non-critical supplier. Revoke all their access credentials without warning. Time how long it takes to:
- Identify all systems they had access to
- Confirm revocation was complete
- Verify no orphaned accounts remain
- Document the change
If this takes more than 4 hours, your user lifecycle management process has gaps.
Test 2: Continuity Plan Activation Without IT
Simulate an IT department that's unavailable (they're responding to the incident). Can your business continuity team activate recovery procedures, contact suppliers, and communicate with stakeholders without IT support? If not, your plan is too IT-dependent.
Test 3: Audit Trail Review
Pull evidence for controls A.5.19 through A.5.23. Can you show:
- Documented security requirements in supplier contracts
- Evidence of supplier security assessments
- Records of supplier access reviews
- Incident response procedures that include supplier-originated threats
If you're assembling this evidence for the first time during the audit, you're not maintaining the controls. You're documenting what you wish you'd done.
Maintenance: Ongoing Tasks
Ransomware resilience isn't a project with an end date. It's an operational discipline.
Monthly: Review new supplier onboarding. Ensure security addenda are signed before access is granted, not retroactively.
Quarterly: Update your supplier risk register. Track changes in supplier security posture, new subprocessors, or changes in services provided.
Annually: Rerun your business impact analysis. Your operational dependencies change. Your critical suppliers change. Your BIA should reflect current reality, not last year's org chart.
After Any Supplier Security Incident: Conduct a post-incident review even if your organization wasn't directly affected. If your supplier disclosed a breach, document what happened, whether your data was involved, and what controls prevented (or would have prevented) impact to your operations.
The work isn't glamorous. It's contract negotiations, spreadsheet maintenance, and tabletop exercises that expose uncomfortable gaps. But it's the work that keeps your ISMS aligned with the threat environment you're actually operating in, not the one your controls were designed for three years ago.
