Why having a plan matters
Third-party breaches are rising, and spreading faster. Did you know 98% of Europe’s largest companies have reported a third party breach? Now, if that’s happening to the big guys, the question isn’t just “Are we secure?” but “What happens when our vendors aren’t?”
On top of this, only 22% of UK businesses have a formal Incident Response plan, a significant gap in preparedness.
From DORA’s new ICT supply chain requirements to real-world breaches like MOVEit and SolarWinds, regulators and customers now expect preparedness even when the compromise happens externally.
Spotlight: Secure File Transfer Under DORA
The MOVEit breach highlighted a huge gap, where secure file transfer tools are often overlooked as third-party risks. Under DORA, financial firms must ensure the resilience of data in transit, not just at rest. This includes assessing managed file transfer (MFT) platforms, SFTP services, and cloud-based file exchanges. Many mid-sized firms use such tools daily without formal vetting, monitoring, or breach response plans, despite the fact that data transfer outages or compromises can directly impact regulatory reporting obligations and customer trust.
Key challenges for mid-sized financial firms
- Low visibility into vendor infrastructure
- Dependency on partners for updates, logs, and timelines
- Lack of predefined response workflows for third-party incidents
- Pressure to communicate quickly, without all the facts
Readiness Self-Check
Answer Yes/No:
- Do you have a documented and tested IR plan?
- Do all key responders know their roles?
- Can you isolate a compromised machine within 5 minutes?
- Is there a predefined plan for stakeholder comms?
- Have you tested the plan in the last 6 months?
Score 4–5 Yes: You’re in a good place — refine and rehearse. Score 2–3 Yes: Prioritise improvements now. Score 0–1 Yes: Start with this toolkit and build.
5-phase plan for third-party incident response
1. Detection & Awareness
- Subscribe to vendor status pages or threat intel feeds (some free ones include AlienVault & VirusTotal)
- Monitor for abnormal outbound connections or broken integrations
- Encourage staff to report unexplained vendor outages or degraded services
Red flag: MFA outage on SSO provider, SaaS tools timing out, or sudden webhook failures
2. Immediate Containment Steps
- Disable integrations or API keys to affected vendor systems
- Restrict outbound traffic/IPs related to vendor connections
- Review and rotate any shared credentials (API keys, SSO tokens)
- Force logout users and initiate session revocation if needed
Bonus: Pre-build automation to revoke shared tokens or disable integrations in one click
3. Internal Escalation & Activation
- Alert your IR lead, legal/regulatory liaison, and executive sponsor
- Review your contract or SLA for vendor breach obligations
- Determine if a regulatory threshold is crossed (see below)
📢 Regulatory Triggers (UK)
You may need to notify regulators within 72 hours if:
- Customer data was exposed (GDPR)
- Operations were significantly disrupted (FCA/PRA)
- Systems supporting payment or financial transactions were impacted
4. Coordinate Communication
- Request a timeline and impact statement from the vendor
- Draft internal FAQs for customer support and sales
- Align messaging with vendor PR and status page updates
Message template (internal):
“We’re investigating a possible security issue involving [Vendor X]. While our systems are currently stable, we’ve paused integrations and initiated our IR workflow. Please route any client questions to [Channel X].”
External Customer Update Template:
“We are aware of a potential incident involving one of our service providers. While our systems remain secure, we’ve taken precautionary measures and continue to monitor the situation closely. We will provide updates as we learn more.”
5. Post-Incident Review & Remediation
- Document timeline, vendor responsiveness, and decisions made
- Conduct a risk reassessment of the affected vendor
- Ensure recovery steps were fully executed (access, logs, tokens, backups)
- Update your vendor breach playbook accordingly
Vendor criticality matrix (simplified)
| Risk Category | Criteria | Priority Action |
|---|---|---|
| High | Access to sensitive data + operational impact | Playbook required + contract clause review |
| Medium | Access to internal systems but no PII | Alerting + response workflow needed |
| Low | No access to critical assets or data | Periodic review |
Must-have table: Who does what
| Action | Responsible Party |
| Disable integration/API | Internal IT/security |
| Communicate with vendor | Procurement or security |
| Notify regulators/customers | Legal + Compliance |
| Log incident timeline & decisions | IT / Incident Manager |
| Update customer support comms | Marketing / CX |
Third-party breach checklist
✅ Vendor contacted and response underway
✅ Shared credentials (API keys, SSO) reviewed/reset
✅ Integration disabled or traffic restricted
✅ Leadership, legal, and customer support informed
✅ Comms approved and published (if needed)
✅ Vendor’s remediation reviewed and logged
✅ Risk score and playbook updated
