We Think We've Had a Security Breach. Who Do We Need to Call?

First, what do you mean by "breach"?

"Breach" is used loosely, and the word covers a wide range of situations with very different implications. Before thinking about who to involve, it helps to be clear about what is actually suspected, because the expertise required follows from that. Common situations include:

These are not equivalent. A single misdirected email and a suspected intrusion into a production environment sit at opposite ends of a very wide range, and they call for different people. It is also common at this stage not to know which of these you are dealing with, and that uncertainty is itself part of what specialist help is often engaged to resolve.

Who usually coordinates the response?

Whatever else happens, somebody has to own coordination. The most common difficulty in smaller organisations is not a shortage of technical skill but the absence of a clear owner, so information circulates without anyone holding the overall picture or making decisions.

Depending on the company, that owner may be:

• Internal security leadership, where a security function exists
• IT or engineering leadership, which is often the case in smaller technology companies
• A senior operational leader, particularly where the incident affects the business more broadly than its systems
• An external incident response lead, brought in to coordinate where the organisation has no one suitable internally
• A fractional or part-time security leader, where the company already works with one

The coordinating role is largely about ownership, communication and decision-making: keeping track of what is known and not known, deciding who else needs to be involved, and being the point of contact for leadership, advisers and, where relevant, customers. Some companies fill that role permanently through part-time security leadership rather than deciding who owns it while something is happening.

When might you need an incident response specialist?

An incident response professional or team works with organisations dealing with a suspected or confirmed security incident. At a high level, that work can involve helping to determine the nature and scope of what has happened, supporting the organisation's technical response, coordinating specialist investigation where it is needed, and helping a company understand which technical questions actually need answering.

The shape of the engagement varies considerably. Some organisations have a retainer arrangement in place before anything happens. Others engage help at the point of an incident. Some need substantial hands-on involvement; others mainly need experienced judgement alongside a capable internal team. What is appropriate depends on the situation, the systems involved and what the organisation can do itself.

When does digital forensics become relevant?

Digital forensics is the specialist analysis of systems and data to establish what took place. It tends to become relevant where an organisation needs to understand, to a standard that will hold up to scrutiny:

• What actually happened, rather than what appears to have happened
• Which systems or categories of information may have been affected
• How activity unfolded over time
• Whether the available evidence needs specialist analysis to be interpreted properly

That need often arises where there are legal, regulatory, insurance or contractual questions attached to the incident, and where an informal internal view will not be sufficient for the people who will ask about it later.

Incident response and digital forensics overlap, and the same firms frequently offer both, which is why the terms are sometimes used interchangeably. They are not always the same service. An organisation may need support managing an incident without needing detailed forensic analysis, and it may occasionally need forensic analysis of something that is no longer live. Being clear about which you are asking for makes it considerably easier to find appropriate help.

Do you need legal or privacy advice?

Security incidents can raise questions that are not technical at all. Contracts with customers or suppliers may contain security and notification terms. Privacy and data protection regimes may apply where personal data is involved. Some sectors have their own regulatory expectations. These are legal and regulatory questions, and they are answered by appropriately qualified advisers rather than by security specialists or by a general article.

Because the relevant variables differ between organisations, where an incident may touch any of these areas, the practical point is simply that legal or privacy input may need to be part of the picture, and that it is worth establishing early who would provide it.

What role can cyber insurance play?

If your organisation holds a cyber insurance policy, that policy may shape how the response is organised. Some policies set out notification expectations, specific contacts, or panels of approved providers for incident response, forensics and legal support. Engaging specialists independently without understanding those terms can complicate matters later.

Cover, requirements and processes vary between policies and insurers. The useful general point is narrow: if a policy exists, understand what it requires of you, and involve your broker or insurer in that question rather than assuming.

When might communications expertise matter?

Some incidents create communication questions alongside technical ones. Customers may need to be told something. Employees will usually notice that something is happening. Partners, regulators, investors or the media may become involved depending on the scale and nature of the incident.

Communications expertise, whether internal or external, becomes relevant where an incident is significant enough to require structured and consistent messaging rather than ad hoc updates, and where what is said interacts with legal, contractual or regulatory considerations. Many incidents never reach that point, and most do not need a public relations agency. The judgement is about whether the incident genuinely requires coordinated communication, not about treating every incident as a reputational event.

What if the breach involves a specific technology?

General incident response experience is not the same as deep familiarity with the particular environment involved. Where an incident centres on one platform or system, organisations often need someone who genuinely understands that environment alongside whoever is coordinating the response. Depending on what is affected, that might mean expertise in:

• Cloud environments such as AWS, Azure or Google Cloud
• The application itself, where the product or codebase is involved
• Identity and access systems, where accounts or authentication are central to what happened
• Microsoft environments and productivity platforms
• Specific SaaS platforms that hold significant company or customer data
• Operational technology, where an organisation runs industrial or physical systems

This is a question of choosing the right expertise rather than a technical exercise in itself. Where cloud configuration is central, someone with cloud security experience will interpret what they see far more quickly than a generalist. Where the product is central, application security expertise is more likely to be relevant.

Do you need a penetration tester?

This is worth stating plainly, because the assumption is common: being attacked does not automatically mean you need a penetration test. Penetration testing is a planned, scoped assessment that looks for weaknesses in a defined part of your environment. It is forward-looking. It does not establish what happened during a suspected incident, and it is a different discipline from both incident response and digital forensics.

Testing can be genuinely useful later. Once an organisation understands its situation and has decided what it wants to improve, a test can help assess particular areas. Treating it as the first response to a suspected breach usually means spending money on the wrong question.

When does outside security help make sense?

External support is not mandatory, and plenty of organisations handle smaller incidents internally. It tends to become worth considering where:

• There is no internal security team, and technology responsibility sits with people whose main job is something else
• The suspected incident falls outside the experience of the internal team
• Specialist investigation appears to be needed to answer questions the organisation cannot answer itself
• The affected technology requires expertise nobody internally has
• Independent technical input would carry more weight with customers, insurers or advisers
• The internal team is already fully occupied keeping the business running

How do you choose the kind of help you need?

The aim here is modest but valuable: to avoid engaging the wrong kind of specialist. A short conversation about the following usually clarifies what you are actually looking for.

• What kind of incident is suspected, and how confident anyone is about that
• Which systems, platforms or categories of information may be involved
• What expertise already exists internally, and what it does not cover
• Whether legal, insurance or contractual considerations affect who should be engaged and in what order
• Whether the situation calls for specialist technical knowledge of a particular environment

That means when you approach someone for help, you can describe the situation in terms they can act on, and you are more likely to end up with expertise matched to the problem rather than to the first available label. If the incident later leads to customer questions, our guide to customer security reviews covers what those conversations tend to involve.

Common questions