The first 24 hours
Your site is serving pages you did not write, redirecting elsewhere, or your host has just suspended it. What follows is the order in which the steps are taken, the one that preserves what you will need later. Seven steps, and the only irreversible one is the first — precisely because it consists in destroying nothing.
The order of operations
There is a reason for this order: each step protects the next. Taking back access before copying means losing the trail; cleaning up before dating means losing the evidence.
Keep a copy before touching anything
It's the step that determines all the others, and the one most often skipped. Copy the files AND the database in their current state, onto separate storage. That state, however damaged it may be, is the only thing that will later allow you to date what happened, and to answer a hosting provider, an insurer or a client. Once cleaned up, it is gone forever.
Decide with full knowledge whether the site stays online
Taking the site down protects your visitors and stops the damage; it costs you your visibility and the day's sales. The simple rule: if pages that aren't yours are being served to your visitors, or if a form is collecting payments, take it down. Otherwise, an honest holding page is better than a site cut off cold. In every case, the copy from point 01 is taken BEFORE.
Regain access in the right order
Hosting first, because it controls everything else: control panel password, then FTP and SSH, then the database, then your content management system accounts. Changing the admin password first is the natural reflex, and it's the least useful: whoever controls your FTP will put it back within the minute. While you're at it, remove any accounts you no longer recognise.
Date the incident using the logs
Your host's access logs carry the date. Look for requests to files you don't recognise, and file uploads from an unusual address. The date matters for two reasons: it tells you which backup is still clean, and it sets the boundaries of what needs examining.
Draw up the exact list of what has changed
This is the point where the human eye reaches its limit. A live site contains tens of thousands of files, and the one that was added looks just like the others. The question that can actually be answered is the reverse: how many files can justify their presence, and which ones cannot? That's what our analysis does — it compares your site against the authentic code published by the vendors, names every discrepancy, and delivers the whole thing signed.
Notify those who need to know
Your hosting provider, if they've suspended the site or flagged something to you: a dated, signed report will considerably shorten the exchange. And if personal data may have been compromised, European regulation gives you 72 hours to notify your data protection authority — in France, the CNIL. That deadline starts running from the moment you become aware of it.
Restore, then certify the resulting state
Restoring the vendors' files to their authentic version handles the greater part of the work. What remains is what belongs to you alone — your themes, your settings, your additions — which has to be reviewed by hand. Once the state has been reached, have it certified: that certificate is what will tell you, next month, whether the site is still the one you restored.
Point 05, done for you, with the means to show it
The analysis answers the question in point 05 by turning it around: instead of looking for what is known to be bad, it asks each file to justify its presence. A file that matches the authentic code published by its vendor is accounted for. The others are named, one by one, with their date and their location.
You receive the exact count, the list of files, the probable date of entry, and three signed documents: the report, the certificate of the resulting state, and the document you can hand over to your host or your client. Each one can be verified with us, free of charge and forever, by anyone — that is what makes them enforceable.
One caveat, written here as it is on every document: a fully accounted-for site is a site in which every file has answered for itself, which is already a great deal — and that is not the same thing as a secure site. A password breach or an up-to-date but vulnerable extension remains beyond the reach of a file comparison.
The following month, and the ones after that
A site restored once is often compromised a second time, through the same door, because the door was left open. Two things really make the difference for what comes next: knowing the same day that an executable file has changed, and knowing that an extension installed on your site has been pulled from the official repository or that a vulnerability has been disclosed since. Monitoring covers both, including on days when your site itself hasn't changed at all.
It states things precisely: when the attestation breaks, it announces that this site differs from the one that was attested. Your own deployment breaks it in exactly the same way — which is why you re-attest after every deployment, and why a break with no deployment deserves a close look.
How many files on your site can justify their presence?
You'll have the exact number, each file named, the likely date, and three signed documents that someone else can verify.