provides immediate alerts for any incident we detect. We send these alerts over preconfigured alert channels to ensure you and your security team are activated as quickly as possible, and able to mobilise your investigation and response procedures with the best information we can provide.

You know best how your incident response procedures should be designed, and we encourage you to have defined and practiced your incident response procedures in advance. Below are our thoughts on some common principles and actions we would expect to be present in your processes:



Bring together the correct team for the problem! This means knowing who should be involved in what scenario, having a means of contacting them and setting appropriate priorities for the incident, ensuring the team knows their roles and has the tools and access required to perform them. It also means excluding people who are not required (at least, not initially) so that triage can happen as efficiently as possible.

Specifically, we would recommend you include people who are not just technical investigators, but who can help with communications and PR, and your legal team (especially in relation to privacy matters).

Analyse our analysis

We endeavour to make the signals from to be highly qualified, low-false-positive alerts, telling you when we have observed what appears to be an incident (or not). From that point on, you should commence your own due-diligence, firstly to confirm the validity of our alert, and secondly to confirm the potential wider radius of any related events visible within your environment. Our alerts may draw your attention towards activity that previously looked entirely benign when viewed without our enrichment.

Your analysis should determine the scale and scope of the incident, stakeholders affected and the potential impact to them.

Treat the incident

This is actually three steps in one; contain, eradicate and recover. Stop the incident causing wider impact, through techniques such as network blocks, account closure and access control revocation. Remove the cause of the incident, which could be a staff dismissal or the ending of a third party contract, or the addressing of a more technical vulnerability. Then, return the business to its pre-incident state through a mixture of technical and non-technical steps such as restoration of backups.

Whilst urgency is important, be careful and methodical in your response. Whilst you don't want to be forcing all your customers to change their passwords without good cause, delaying such a response can lead to increased impacts. That said, changing passwords is often the simplest and a highly effective first step in treating many incident types.


The stakeholders of any incident are frequently wider than we may initially think. Your security team, directly-affected customers, senior management and Privacy teams are obvious, but what about the wider workforce; how would they feel if they hear about the incident for the first time on the evening news. Your suppliers and service providers (banking, insurance and so on) can be useful allies in an incident too.

Once you've established who you should talk to about the incident, remember that 'what' you say and 'how' you say it is the work of experts, not amateurs, for good reason. You would not ask your communications team to lead on cybersecurity response, so don't do the same in your comms activities; use experts where possible.

Finally, treat your comms as a dialogue, not a broadcast; provide channels for stakeholders to respond to you, or to ask questions; help them manage their concerns, and in turn this will help you manage your risk.

Contact the regulators

Most countries have legal requirements to notify their regulators when personal data is lost or stolen. The specifics of these requirements vary, and you may be subject to multiple jurisdictions (they don't just apply based on where your business is registered), so do your research in advance; many have a relatively short window for initial notifications.

Ask for help

There are many instances when using a 3rd party to help respond to the incident will make sense. It could be as simple as asking other businesses within your sector / region if they have had similar experience (cybersecurity emergencies have temporarily united many sectors that would otherwise be highly competitive), or it could be the involvement of a specialist incident response team for forensic investigations.

Don't forget that your existing team and suppliers did not prevent this incident. Whilst there's an inevitability to that (so no criticism directly), it does mean they may not be best equipped to help you recover from the incident; they may need help, and now is not the moment to skimp on your response.

Finally, as you're already in conversation with your regulators and possibly your insurers, ask them for help too. They have a vested interest in helping you bring this to a close quickly


Hindsight is a generous gift, and taking steps to ensure you don't end up in the same situation next week should be every bit as important as closing the incident down. User training, better contracts, a myriad of technical improvements and operational process changes, better monitoring, and many more improvements are possible routes. Likely, the correct answer will be adjustment across several areas, so remember to consider the complexity of introducing these changes before committing to improving everything in one go; define a measurable program of change where metrics can inform you of adequate (or inadequate) progress.

Ultimately, the better you're prepared for an incident, the better your response will be, and previous incidents are a great source of education.