Incident Response
We complement your detection & response at the two points where things regularly get stuck. In an emergency, we bring calm and structure to a hectic situation, drawing on our own experience with ransomware and insider incidents, and take over the threat picture, containment and the notifications. In day-to-day operations, we handle your alerts when your team cannot: at peak times, on weekends and at night. If things are on fire right now, you can reach us via Urgent Help at the top right.
Alerts don’t arrive during office hours
Detection without response is a smoke detector without a fire brigade. Most organizations that call us do not have a detection problem: the alerts arrive. The problem is who handles them when they come in at 7 p.m. on a Friday, when two out of three people are on vacation, or when an alert suddenly turns into a real incident.
That is exactly when the requirements shift. Alert handling is about triage and speed. An incident is also about decisions under uncertainty, about internal and external communication and about deadlines that run in parallel with the technical response. Both need people who are available and who already know your environment beforehand.
Six phases, and two of them are decisive
The real problem in an incident is that everything happens at once. That is why we do not work by gut feeling but along a process that practitioners have used for years: the six phases of the SANS Institute, which also underpin the GCIH certification. Their value lies less in completeness than in the sequence.
Two transitions decide the outcome, and neither can be settled in advance in a document. The first lies between identification and containment. Shut things down too early, and you lose the information about what the adversary is actually doing and how far they have already got. Watch too long, and you let them keep working. This trade-off needs someone who makes it in the situation and takes responsibility for it, with the mind of someone who is not seeing something like this for the first time.
The second lies between eradication and recovery. Recovering too early is the most common reason why the same incident happens a second time. That is why it always includes a phase of heightened monitoring in which you look specifically for exactly the technique the adversary used to get in. And that is why the lessons learned at the end are not busywork but the point at which an expensive incident at least turns into progress.
Three reporting obligations, three different clocks
Running in parallel to these six phases is something that has nothing to do with technology. From identification onward, several reporting deadlines may be ticking at the same time, depending on which rules apply to you, and they do not start at the same point:
| Regime | Clock starts at | First notification | Then | Final |
|---|---|---|---|---|
NIS2 Section 32 BSIG | Awareness of the incident | 24 hrs early warning | 72 hrs confirmation with assessment | 1 month after the 72-hr notification |
GDPR Art. 33 | Becoming aware of the breach | 72 hrs to the supervisory authority | always documentation, even without notification | n/a no final report |
DORA Art. 19 | Classification as major, max. 24 hrs after awareness | 4 hrs after classification | 72 hrs after the initial notification | 1 month after the intermediate report |
There are two traps in this. First, the starting point: the BSIG counts from awareness of the incident, the GDPR from becoming aware of the breach, DORA from classification as major. Second, the final deadline, which refers to the previous notification and not to the incident. Anyone who mixes this up reports too late on paper, even though everything was dealt with technically long ago.
The practical core: the first notification is a decision under uncertainty. After four or 24 hours, nobody knows exactly what happened, and nobody expects you to. What is required is a sound initial assessment that may be corrected later. That requires criteria defined in advance and a person who is authorized to make this decision.
Two ways to bring us in
We do not turn this into a product landscape. There are two ways to work with us, and they can be combined:
Which alerts we handle and when to escalate are things we define together in advance, based on the adversaries and techniques that are realistic for you. That way, the decision is not made by the gut feeling of whoever is on duty but by a criterion you agreed to beforehand.
What we do not do
We do not do IT forensics. Not because we are unfamiliar with the subject, but because legally sound evidence preservation requires dedicated equipment, suitable rooms and an unbroken chain of custody. Anyone who offers this on the side jeopardizes precisely the admissibility it is all about. If you need robust evidence afterwards, for example for law enforcement, insurance or employment law, that belongs in specialized hands.
What we do instead: during an ongoing incident, we make sure traces are not destroyed before someone can secure them. We bring in forensic service providers, steer them and translate their results into decisions. And we keep your back free while that is going on.
Nor do we replace your SOC or your detection & response. If you have no detection at all yet, incident response is not your first problem, and we talk about that first. And we do not sell standby services to organizations where it is foreseeable that no alert will ever arrive because nobody is looking.
Frequently asked questions about incident response
Do you also do forensics?
No. Legally sound evidence preservation requires dedicated equipment, suitable rooms and an unbroken chain of custody. We do not provide that, and we do not claim to. What we do: during an ongoing incident, we make sure traces are not destroyed, bring in specialized forensic service providers, steer them and translate their results into decisions.
Have you handled incidents yourselves?
Yes, complex ones. They include ransomware situations as well as insider incidents in which the technical response, employment law questions and communication all run at the same time. That is exactly where the part of our service comes from that is hard to put into a service description: setting a sequence in a hectic situation and sticking to it.
What process do you follow to handle an incident?
The six phases of the SANS Institute: preparation, identification, containment, eradication, recovery and lessons learned. This model comes from incident handling practice and describes the order in which decisions are actually made in an emergency. Two transitions are decisive: from identification to containment and from eradication to recovery.
Do you replace our SOC or our detection & response?
No, we complement them. Detection stays with you or with your service provider. We step in where capacity is lacking: with alerts outside office hours, at peak times and in a real incident, when decisions, communication and reporting deadlines suddenly come on top of the technology.
How quickly does a security incident have to be reported?
That depends on the regime, and the clocks start differently. Under Section 32 BSIG, an early warning is due within 24 hours and a confirmation with an initial assessment within 72 hours, each from awareness of the incident, and the final report within one month after the 72-hour notification. In Article 33, the GDPR requires notification within 72 hours of becoming aware. For financial entities, DORA sets the shortest deadline: four hours after classification as major, but no later than 24 hours after awareness.
What happens if we cannot meet the deadline?
Report anyway, and give reasons for the delay. The GDPR explicitly provides for this in Article 33, and the DORA rules on deadlines require you to inform the competent authority of the delay and its reasons within the original deadline. An incomplete notification is better than a late one: initial notifications and intermediate reports may explicitly be corrected and supplemented.
Do we have to report every incident?
No. Only significant or major incidents are reportable, and the GDPR notification is not required if the breach is unlikely to result in a risk to the rights and freedoms of natural persons. That is exactly why classification criteria need to be defined in advance. Nevertheless, under Article 33(5) GDPR, every breach must be documented, including those not reported, so that the supervisory authority can follow the decision.
How exactly does the takeover of alert handling work?
We clarify in advance which alert sources we see, which cases we may close ourselves, when to escalate and to whom. This includes access to your systems to the agreed extent and a short handover at the beginning and end of each time window. You retain control over your environment; we take over the work during the times you cannot cover.