Emergency takeover: what we do in the first 48 hours
When a business arrives with a site down, a developer gone or a compromise underway: the sequence for the first two days, in order, and what we do not touch.
The short answer
Businesses arrive in an emergency in three shapes: the site is down and nobody can fix it, the developer has vanished with the keys, or a compromise is underway. The first 48 hours have one goal in all three: stop the damage and establish control. Improvement comes later. Hour one is understanding: what is happening, what you can reach, who holds what. Day one is securing the domain and accounts, taking a backup of whatever exists before anything changes, containing any compromise, and restoring service by the smallest safe action once the cause is known. Day two is stabilising: monitoring, credentials rotated, the state documented, and the plan for the proper takeover. What we do not do: change things we cannot undo, reinstall over evidence, or promise a fix before we know the cause.
The 48 hours
| When | What | Why |
|---|---|---|
| Hour one | A call: what is happening, what you can log in to, who else has access, what changed recently | Nothing safe can be done without knowing what exists |
| Hours one to four | Secure the domain: registrar access, lock, auto-renew; confirm DNS control | Everything depends on it; it is the first thing a compromise or a departed developer endangers |
| Hours one to four | Backup of whatever exists: files, database, content export, repository clone | Nothing is changed before a copy exists |
| Day one | Find the layer: domain, DNS, certificate, hosting, deploy, application; restore service by the smallest safe action | An outage is one specific thing at one layer |
| Day one, if compromised | Contain: offline or holding page; preserve logs and a copy; do not clean in place | Visitors protected; evidence kept; the door not left open |
| Day one to two | Rotate every credential you regain; remove unknown users; add two-factor | The previous holder’s access is assumed to persist |
| Day two | Monitoring and alerts to a named person; the setup documented as found; a written summary of the state | Stability and a record |
| Day two | The assessment and plan for the proper takeover: what to keep, fix, replace, and the price | The emergency ends; the project begins |
What we do not do
- Change anything before a backup exists.
- Clean a compromised site in place; we restore from clean and close the entry point.
- Reinstall or restore over evidence before it is preserved.
- Touch the live site’s code until the deploy path is understood.
- Promise a full fix or a price before the cause is known.
- Bill open-ended hours; the emergency engagement has a cap and a report.
After the 48 hours
The site is up or safely offline, the domain and accounts are out of the hands of whoever you are leaving and the holder of each is written down, a backup exists, credentials are rotated, monitoring is watching and the state is recorded. The assessment says what the site is, what it holds, what is sound and what is dangerous, and proposes the takeover in stages with a price. Almost every emergency traces back to two things: ownership that was never in the business’s name and maintenance that was never contracted. The takeover fixes the emergency in two days and the causes over the following quarter.
What this means for you
In an emergency, expect a partner to spend the first 48 hours establishing control and stopping the damage, in a fixed sequence, without touching what cannot be undone or promising what is not yet known. Expect a capped emergency engagement, a written state at the end of it, and a plan for the proper takeover. And expect the causes to be ownership and maintenance, because they almost always are, and to be fixed so that this was the last emergency of its kind.
Frequently asked questions
Our developer has vanished and the site is down. What happens first?
First, a call to understand what you can reach: registrar, hosting, the site's admin, the repository, email. Then the domain, because everything depends on it. Then a backup of whatever exists, before anything is changed. Then the cause of the outage, found from the layer it is in: domain, DNS, certificate, hosting, deploy, application. Service is restored by the smallest safe action, and only then does the stabilising begin.
What if the site has been hacked?
Containment first: offline or behind a holding page, so visitors and your reputation are protected and the site stops sending spam. Evidence preserved: logs, a copy of the compromised state. Then a restore from a known-clean version, every credential rotated, the entry point found and closed, monitoring in place. We do not clean by deleting the visible malware; that leaves the door open.
What will it cost?
The first 48 hours are priced as an emergency engagement with a cap, because nobody can quote an unknown. After stabilisation, the assessment produces a plan and a price for the proper takeover. What we will not do is quote a full fix before we know the cause, or bill open-ended hours without a cap and a report.