Incident response and service recovery
When a platform is compromised or down: contain, restore service, understand, and write down what will stop it happening again.
Contain, then restore service
The first decision separates what must be preserved from what must come back up. We isolate the affected system, take a usable copy of the traces, then bring the service back on a clean base without waiting for the analysis to finish.
That sequence avoids the most common mistake, which is to clean the compromised server and then discover that the only evidence of what happened has been destroyed.
- Isolation of the affected system, without destroying traces
- Usable copy of logs and of the system state
- Service restored on a clean base, in parallel with the analysis
- Immediate rotation of access and keys
Understanding what happened
The analysis looks for the entry point, the extent of what was reached, and how long the situation lasted. Those three answers govern everything else, including your notification obligations if personal data is involved.
- Entry point and timeline established
- Perimeter of the data actually reached
- Exposure duration established from traces, not assumed
- Material needed for any regulatory notification
Preventing a repeat
An incident that produces no lasting change happens again. We hand over a written report saying what happened, what was fixed, and what remains to be done in priority order. That document is what serves afterwards with a board, an insurer or an authority.
- Written report, usable outside the technical circle
- Fixes applied and fixes remaining kept distinct
- The monitoring that was missing put in place
- A restore test, to verify the backup actually holds
Incident response and service recovery
Do you work on platforms you did not build?
Yes. We first assess the situation and technical scope. This form handles general enquiries with a stated response time of two working days; it is not an emergency channel. On-call arrangements require a specific agreement.
Should a ransom be paid?
That is not a technical decision and we do not take it for you. We supply what informs it: what is actually encrypted, what the backups allow you to rebuild, and the real time a restore based recovery would take.
When must an authority be notified?
It depends on the nature of the data and the applicable law, and the deadline is short. We provide the factual material your legal counsel needs to decide, with the timeline and perimeter established from the traces.
Cybersecurity
Audits, hardening, access management and incident support.
In the division Cybersecurity
Let’s discuss your project.
Tell us about your objective, context and timeline. We will help define the next step.
Tell us about your project