A serious incident is not the moment to improvise. It’s the moment to execute: contain the problem as quickly as possible, understand the real scope and restore the service with the least possible impact. What happens in the first hours makes the difference between a managed incident and a disaster that keeps spreading.
I come in as technical systems support when something has already happened: a security breach, an unexpected outage, a compromised server, corrupted data or a migration that went wrong. The immediate goal is to recover the service; the second is to understand what happened and leave the environment more robust than it was.
I work with agencies that need systems backup when a client project goes into crisis, and with companies whose internal teams don’t have the response capacity for certain types of incident.
Most common incident types
- Compromised server. Unauthorised access, uploaded webshell, installed cryptominer, anomalous outbound traffic. Contain, isolate and clean without losing evidence if needed for a subsequent report.
- Service outage with no obvious cause. The site isn’t responding, the logs aren’t clear, and there’s no time for a calm diagnosis. First priority: recover the service. Second: understand why it happened.
- Data loss or corruption. Accidental deletion, truncated table, overwritten files. Evaluating what can be recovered and from where, before time works against you.
- Ransomware or file encryption. Containing the scope, assessing what is and isn’t affected, and a recovery plan from whatever backups are available.
- Migration gone wrong. A server or hosting change that left something broken: inconsistent database, incorrect configurations, degraded service without knowing exactly why.
- Unexpected load spike. The server gives in under an unplanned traffic peak (campaign, viral event, DDoS attack) and needs stabilising while a more solid solution is worked on.
How I approach the response
The first step is always containment: limit the impact while understanding the scope. Isolate if necessary, stabilise the service, and stop the problem from growing while investigating.
The second step is diagnosis: read the logs, understand the timeline, identify the entry vector or root cause. Without this, any solution is provisional.
The third step is recovery: restore the service cleanly, with verification that the environment is in good shape before going back to production.
And the close is the report: what happened, how it was resolved, what needs to change so it doesn’t happen again. Documented and delivered.