Your Website Was Hacked: First Steps and the 72-Hour Clock

A customer calls because your site redirects them to a gambling page. Or Google shows a red warning instead of your shop. Or your host suspends the account for sending spam.

The first impulse is almost always the same: delete something and hope it is gone. That is the wrong place to start — and it is not where the most urgent deadline is running either.

What follows is the sequence that works: preserve, assess, report, clean, close. I am a developer, not a lawyer and not a forensic specialist. If you hold sensitive data — health records, payment details, a substantial customer base — bring in someone who does this professionally from step two onward.

This article covers the obligations that apply under the GDPR, which is what you are dealing with if you process data in the EU or offer goods and services to people in it, regardless of where your company sits.

The first hour: preserve, don't delete

Before repairing anything, capture the state.

Take a full copy of the site exactly as it is — files and database. Do not overwrite, do not clean, just put a copy somewhere separate. This is your evidence. If you later have to establish whether customer data was taken, that copy is the only thing you can reconstruct it from.

Save the logs. Server logs, access logs, whatever your host provides. Many providers retain them for only a few days. Ask on day three and there is often nothing left.

Write down the time you noticed. It sounds trivial, but it is the starting point of a statutory deadline — more on that below.

What you should do straight away: take the site offline or switch to a maintenance page. That protects your visitors and stops ongoing harm without destroying evidence.

What you should not do: restore a backup and carry on. That overwrites everything and leaves open the question of how the attacker got in. If the way in stays open, the site is compromised again in a fortnight — only now without any traces.

Did something actually happen?

Not every oddity is a breach. Before starting the full process, work out what you are actually seeing.

Fairly unambiguous signs: redirects to unfamiliar sites, content nobody on your side published, a Google warning, suspension by the host, sudden spam complaints.

Ambiguous signs: the site is slow, a form stopped working, an extension throws errors. That can be an attack, but more often it is an update conflict or a full mailbox.

One thing people frequently misread: failed login attempts in the logs are not a breach. Every publicly reachable login form collects them around the clock, automatically. What matters is whether an attempt succeeded.

The 72-hour clock

This is the part almost everyone underestimates, and the reason "let's fix it calmly first" can get expensive.

Article 33 GDPR requires you to notify the competent supervisory authority of a personal data breach without undue delay and, where feasible, within 72 hours of having become aware of it.

Three details decide everything here:

The clock starts on awareness, not on the breach. If the intrusion happened three weeks ago and you notice this morning, the clock started this morning.

The 72 hours run continuously. Weekends and public holidays are included. Become aware at 4pm on a Friday and the deadline falls at 4pm on Monday.

You do not need to have finished analysing. Article 33(4) expressly allows phased reporting: give what you know now and supplement later. A preliminary report is permitted — a late one has to be justified.

When no report is required: where the breach is unlikely to result in a risk to the rights and freedoms of natural persons. The textbook case is data that was encrypted to current standards with the key not compromised.

And what applies regardless: Article 33(5) requires you to document every breach internally — what happened, which data was affected, how you assessed the risk, what you did about it. Even where you conclude no notification is needed, that assessment itself has to be traceable.

Who to notify: in Germany, for companies, associations and independent professionals, it is the data protection authority of your federal state. Most provide an online form. In other member states it is the national or regional supervisory authority.

Where risk is high: Article 34

A second obligation kicks in where the breach is likely to result in a high risk to the individuals concerned. Then Article 34 requires you to inform those individuals too, without undue delay.

It is uncomfortable, and it is also the situation where transparency is cheapest. Customers forgive an incident far more readily than the feeling that something was kept from them for months.

Practice distinguishes three kinds of breach, and the third is routinely overlooked:

• Confidentiality — unauthorised parties accessed data.
• Integrity — data was altered without authorisation.
• Availability — data was lost or destroyed, through ransomware or deleted backups.

The third is reportable even though nothing went "out". Permanent loss can itself amount to a high risk for the people concerned.

Cleaning up: the order that works

Only now, with a preserved copy and the reporting question settled, do you start clearing up.

Change every credential. Hosting, database, CMS accounts, FTP, email. Including the ones you believe were untouched. Access to one area often means access to more.

Check for accounts you did not create. A common pattern: the attacker adds an extra administrator account so they can return after a password change. Go through the user list.

Restore a backup — the right one. Yesterday's copy usually already contains the intrusion. You need one from before it, and for that you first need to know when it happened. Which is why this step does not come first.

Update everything. CMS, extensions, themes, server software. The most common way in is a known vulnerability in an outdated component that has had a patch available for months.

Close the way in. If you do not know how the attacker got in, the incident is not over. Cleaning without establishing the cause means starting again in a few weeks.

Getting out of Google's warning

If Google has flagged the site as harmful, the warning does not clear itself once you have cleaned up.

Search Console has a Security Issues section. It shows what Google found, and once you have cleaned up you request a review from there. It normally takes a few days.

One caution: only request the review when you are confident the site is clean. A rejected review lengthens the process.

If you have no access to Search Console because a previous provider set it up, that is a separate problem — covered here.

Once cleared, the site returns to the results, though not the same minute. If it stays unfindable for a good while after that, what you are looking at is no longer a remnant of the incident but an indexing question — covered here.

Prevention is considerably cheaper

The aftermath is the right moment to change the structure that allowed it.

Automate updates or contract them out. The overwhelming majority of website compromises run through known vulnerabilities in outdated software. Not through sophisticated attacks, but through automated scanners sweeping the internet for installations that have not been updated in months.

Reduce the attack surface. Every extension you do not need is one more potential hole. Remove rather than deactivate.

Backups held separately. A backup on the same server is worthless against ransomware. Separate location, and once a year check that restoring actually works.

Two-factor authentication on every administrative login. If you run the stack yourself, the Next.js security hardening article covers the headers and defaults that belong in the application.

Fewer moving parts. A structural point: a site with dozens of extensions that all need keeping current has more attack surface than one served as static files with no executable environment exposed at all. Which approach suits which case is covered in the architecture comparison.

And a legal point that often gets missed: responsibility for the security of the data sits with you as the operator, not with your developer — the same principle that governs your legal notice and privacy policy, discussed in the article on Impressum and GDPR.

Frequently asked questions

Do I always have to report a hack to the data protection authority? No, but the exception is narrower than people assume. Notification is required once the breach is likely to result in a risk to the rights and freedoms of natural persons. It is not required where such a risk is unlikely — for instance where data was encrypted to current standards and the key was not compromised. Internal documentation is required either way.

When do the 72 hours start? From the moment you became aware of the breach, not from the breach itself. The period runs continuously, weekends and holidays included.

What if I still do not know everything after 72 hours? Report preliminarily. Article 33(4) expressly permits supplying information in phases. An incomplete report inside the deadline is markedly better than a complete one after it — a late report requires you to justify the delay.

Is restoring a backup enough? No, and it can do harm. A backup overwrites the traces you would use to establish whether data was taken. A recent backup also usually contains the intrusion already. Preserve the current state first, establish when the intrusion happened, then restore from before that point.

Do I have to tell my customers? Only where the breach is likely to result in a high risk to them — in which case, without undue delay, under Article 34. Below that threshold, notifying the authority is sufficient.

I deleted the file with the malicious code. Is that it? Probably not. If the way in remains open, the same code comes back. And if an extra administrator account was created, changing passwords alone does not help. An incident is closed when the cause is identified and shut.

My company is outside the EU. Does any of this apply? Possibly. The GDPR applies where you have an establishment in the EU, and also where you offer goods or services to people in the EU or monitor their behaviour. If your site sells to European customers, assume it applies and check rather than assuming it does not.

In short

Preserve before you repair. The clock starts when you notice. A preliminary report is allowed and beats a late one.

And the incident ends not with a clean site, but with a closed door.

If you are reading this in the middle of it: the most important step is the first one. Take the copy before you touch anything.