When your vendor becomes the entry point for ransomware operators, your incident response plan gets tested in real time. You can't control what happens inside a supplier's network, but you can control how ready you are to respond when that supplier becomes your problem.
This checklist guides you through the controls and procedures you need in place before a third-party incident forces your hand. It's built around SOC 2 Common Criteria CC9.2 (vendor management) and ISO/IEC 27001:2022 controls 5.19 through 5.23 (supplier relationships), with incident response requirements from CC7.3 and Clause 5.24.
What This Checklist Covers
This checklist is your readiness assessment for third-party security incidents. It covers the controls you need before selecting vendors, the monitoring you should run while they're active, and the response procedures you'll execute when something goes wrong. Each item maps to specific compliance requirements and tells you what "done" looks like in an audit.
Prerequisites
Before you start this checklist, ensure you have these three things in place:
A current asset inventory that identifies which systems and data flows touch third-party vendors. Without this, you can't scope the impact when a vendor reports an incident. A good setup is a configuration management database (CMDB) or similar register that shows vendor touchpoints, updated within the last 90 days.
Executive sponsorship for vendor termination authority. Your incident response team needs pre-approved authority to suspend vendor access without waiting for contract negotiations. This should include documented escalation paths with named decision-makers and response time commitments.
Baseline evidence collection for your current vendor population. You can't measure control degradation if you don't know what normal looked like. Collect SOC 2 Type II reports, ISO/IEC 27001 certificates, or completed security questionnaires for all vendors processing sensitive data, within the last 12 months.
Checklist Items
1. Document vendor data classification in your ISMS scope statement (ISO/IEC 27001 Clause 4.3) or system description (SOC 2).
Identify which vendors process confidential data, personal information, or have administrative access to production systems. This determines your due diligence depth.
Good looks like: A vendor register with data classification tags (public, internal, confidential, restricted) and access levels (read-only, write, administrative) for each supplier relationship. Your auditor should be able to trace high-risk vendors to enhanced control requirements.
2. Require third-party SOC 2 Type II reports or ISO/IEC 27001 certificates for vendors processing confidential data (CC9.2, Control 5.19).
Don't accept security questionnaires as a substitute for independent assurance. If a vendor can't produce an audit report, they're telling you something about their security maturity.
Good looks like: Current assurance reports (issued within the last 12 months) on file for every vendor in your confidential data tier. The report scope should cover the services you're actually using.
3. Review Complementary Subservice Organization Controls in vendor SOC 2 reports (SOC 2 Type II Section IV).
These are the controls the vendor expects you to operate. If you're not running them, you've got a gap.
Good looks like: A documented control mapping showing which Complementary Subservice Organization Controls you've implemented and how. For controls you're not implementing, document the compensating control or accept the risk formally.
4. Establish vendor access review procedures with segregation of duties (CC6.3, Control 5.18).
The person who approved the vendor contract shouldn't be the same person reviewing their ongoing access rights.
Good looks like: Quarterly access reviews for vendor accounts, documented in your access control logs, with approvals from data owners (not IT). Reviews should show what access was certified, what was revoked, and who approved the decisions.
5. Define incident notification requirements in vendor contracts (Control 5.23).
Your vendor needs to tell you about security incidents that affect your data. The contract should specify the timeline and the information you need.
Good looks like: Contract language requiring notification within 24 hours of incident discovery, with specific data elements (affected systems, data types, customer count, root cause summary). Include the right to audit after an incident.
6. Build vendor-specific incident response playbooks (CC7.3, Control 5.24).
Your general incident response plan won't work when the compromised system isn't yours. You need procedures for incidents you can't remediate directly.
Good looks like: Documented runbooks for third-party incidents covering: who gets notified internally, what information you request from the vendor, how you assess customer impact, when you escalate to legal/PR, and your vendor suspension criteria. Test these annually.
7. Maintain offline evidence archives for vendor assurance reports (Control 5.23).
When a vendor incident hits, you need to prove what controls were supposed to be in place. If your only copy of their SOC 2 report lives in a shared drive they can access, you've got a problem.
Good looks like: Offline or access-restricted storage for vendor security documentation, with version control showing when you received each report. Your IR team should be able to retrieve the current vendor SOC 2 report without network access.
8. Document your vendor risk acceptance decisions in your Risk Treatment Plan (ISO/IEC 27001 Clause 6.2).
If you're using a vendor without a SOC 2 report or ISO/IEC 27001 certificate, that's a risk you're accepting. Write it down.
Good looks like: Risk Treatment Plan entries for each vendor relationship that doesn't meet your baseline security requirements, with business justification, compensating controls, and risk owner signature. Update this when vendor assurance reports expire.
9. Test vendor incident communication channels quarterly (CC7.3).
You need to know your vendor's security team will answer the phone at 2 AM before you're in an active incident.
Good looks like: Documented tests of vendor security contact information (email, phone, ticketing system) at least quarterly, with response time logged. If a vendor consistently misses your SLA, escalate or replace them.
10. Establish evidence preservation procedures for third-party incidents (CC7.4).
You might need to prove what you knew and when you knew it, especially if customer notification or regulatory reporting is required.
Good looks like: Documented procedures for preserving vendor communications, incident timelines, and impact assessments. Use tamper-evident storage (write-once media, cryptographic hashing, or third-party escrow) for critical incident evidence.
Common Mistakes
Treating all vendors the same. Your office supplies vendor and your payment processor don't need the same due diligence depth. Risk-rank your vendors by data classification and access level, then apply controls proportionally.
Accepting expired SOC 2 reports. A SOC 2 Type II report that's 18 months old tells you what controls existed in a test period that ended almost two years ago. Require reports issued within the last 12 months.
Skipping the Complementary Subservice Organization Controls section. This is where vendors document the controls they expect you to run. If you're not running them, you've got a control gap that your auditor will flag.
Waiting for legal review during an active incident. Your vendor contract should pre-authorize specific response actions (access suspension, data deletion requests, forensic audits). Negotiate these before you need them.
Next Steps
Run this checklist against your current vendor population. For each item you can't check off, document it as a finding in your next management review (ISO/IEC 27001 Clause 9.3) or risk register update. Prioritize vendors processing confidential data or holding administrative access.
If you're preparing for a SOC 2 Type II examination or ISO/IEC 27001 certification audit, your assessor will test vendor management controls by sampling high-risk vendor relationships. Make sure you can produce current assurance reports, access review logs, and incident response evidence for your top-tier vendors before the audit fieldwork starts.
The US Bank situation illustrates what happens when a vendor incident becomes your incident. LockBit gave them 14 days. Your preparation window is now.
