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

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)

Must-have table: Who does what

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

In the early days, our automation, ANSEL, while not necessarily immature, was certainly less advanced than where we are today.

Our initial focus was on developing automation to remove certain repetitive tasks from analysts, allowing them to focus on more strategic decision-making.

The first step in this journey was enabling automation to handle triage, the initial phase of incident analysis. We did this by enriching the data analysts would typically gather to understand a security event.

Once we had automation effectively managing triage, the next logical progression was enabling it to recommend outcomes based on the triage steps and the decision-making framework analysts used. As our capabilities matured, automation moved from simply providing recommendations to delivering actionable outcomes.

This meant that incidents could either be closed automatically, if deemed non-threatening or benign, or escalated to the customer when a genuine risk was identified.

In these cases, our automation not only escalated incidents but also provided clear recommendations on the next steps customers should take.

This led us to the final and most impactful stage: remediation.

ANSEL Now

Today, ANSEL is no longer the alerting tool it once was. It’s an active participant in cybersecurity operations, working alongside the SOC team. It can not only notify customers of threats but also take immediate action within their environments to mitigate and contain potential risks.

To put this into perspective, here’s the real-world impact of ANSEL:

• 67.3% of all security tickets fully automated by ANSEL
• ANSEL notified customers of threats in just 1.35 minutes on average
• Saved an average of 18 days per quarter on ticket resolution
• Reduced resolution time by up to 90% through automation

The transformation of ANSEL over the years shows a fundamental shift in how organisations can use automation to strengthen their security resilience.

The Role of Threat Intelligence in Automation

Another critical aspect of our approach has been the integration of enterprise-grade threat intelligence throughout the incident triage process.

This capability isn’t limited to automated incidents, it applies to all incidents, ensuring that every security event in our environment is enriched with high-quality intelligence. By doing so, we empower analysts with deeper insights and more context, leading to faster and more accurate decision-making.

Unlike many traditional models where enterprise-grade threat intelligence is provided on a per-customer basis, we’ve adopted a different approach.

Through our licensing model, we apply this intelligence across our entire customer base. This not only improves security effectiveness but also reduces costs, eliminating the need for you to make significant investments in standalone threat intelligence solutions.

This approach not only improves security effectiveness but also reduces costs, making advanced cybersecurity more accessible to organisations of all sizes.

What’s next for ANSEL and the future of automation in your security operations? Watch this space.