The call rarely comes at a convenient hour. There is text on the home page that nobody wrote, the browser warns about your own address, or a customer gets in touch because her virus scanner reacted when she clicked the contact form. What happens in the next few hours usually decides more about the damage than the question of how the attack worked technically. This article describes the order: what is done first, what is expressly not done, when a reporting deadline starts running, and how a business gets back into search results cleanly afterwards.
Key takeaways
- The first measure is taking the site down, not cleaning it up: a maintenance page stops the damage for visitors while files, logs and timestamps remain untouched as traces and can still be evaluated later.
- If personal data is affected, the controller reports the breach without undue delay and, where feasible, within 72 hours to the competent supervisory authority; if the report is later, reasons for the delay belong with it (Article 33(1) GDPR).
- Access is rotated from a device that had nothing to do with the incident: passwords, keys and sessions in hosting, in the content system, in the database and at the domain registrar.
- What gets restored is a state from before the incident, not the most recent backup: yesterday's copy may already contain the back door, and then the same sequence starts again two weeks later.
- In Lower Saxony the state data protection authority received 1,607 reported personal data breaches in 2025, around 5 percent more than the year before; the figure reflects submissions, not established legal violations (LfD Niedersachsen 2026).
The first hours decide more than the technology
A hacked site is rarely a targeted attack on one particular business. Far more often an address is hit because an automated program found a known weakness. In the reporting period from July 2024 to June 2025 an average of 119 new vulnerabilities per day became known worldwide, growth of around 24 percent over the previous period (BSI 2025). Anyone who understands their own website as a piece of software that wants looking after sees the situation more realistically than someone who treats it as a finished piece of furniture. What that looks like day to day is in the article on website maintenance and security.
Small businesses are not at the margin of this but at its centre. The BSI counts 3.1 million small and medium-sized enterprises in Germany; by number they make up 99.4 percent of German commercial enterprises (BSI 2025). Of the ransomware attacks reported to the Federal Criminal Police Office, 80 percent hit small and medium-sized enterprises (BSI 2025). The figures say nothing about any individual business, but they clear away a widespread assumption: that a tradesperson's site or a practice website is too insignificant to interest anyone. Attacks of this kind do not look for significance, they look for open doors.
The second widespread error concerns the reaction. The first reflex is usually: make it go away quickly. Delete the changed file, remove the odd user account, clear the cache and hope that was it. Precisely this order costs the most later, because it destroys the answer to two questions that will be asked over the coming days: how did someone get in, and what did they achieve? Without an answer to the first, the gap stays open. Without an answer to the second, neither can a report be written nor can anyone judge whether one is needed at all. Whoever has already clarified who owns the domain and the access saves the longest search in that hour.
The difference between a glitch and an incident
Immediate steps: the order that limits the damage
The following order is not sorted by effort but by effect. Each step preserves the state the next one needs. Anyone who reverses it and begins with the clean-up carries on without a basis and usually repeats half the work.
It makes sense to distribute the steps as soon as more than one person is available: one person talks to the host, one pulls copies, one prepares the assessment of what is affected. Where a maintenance contract exists, the first number is already on file; in maintenance a named contact is part of the scope of service and not something to look up in a search engine.
- Take the site off the network, do not delete it: serve a static maintenance page or answer with status code 503. Visitors are protected, the files stay unchanged.
- Record the moment: date and time of discovery, who reported it, what exactly was visible. This note is the start of the documentation and the reference point for the deadline.
- Pull copies before anyone cleans up: file system, database, access and error logs of the web server, logs of the content system. Store them on media that is not attached to the affected server.
- Inform the host. They see things that stay invisible from outside: outgoing connections, bulk sending through the mail server, load spikes, logins with stolen credentials.
- Stop outgoing damage: switch off mail delivery through the affected domain while junk is going out. The reputation of the domain is harder to repair than the site itself.
- Only then assess what is affected. That assessment decides whether a report to the supervisory authority is due and whether data subjects have to be notified.
'personal data breach' means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data transmitted, stored or otherwise processed;
The sentence is unwieldy but it is the test. Four events trigger it: destruction, loss, alteration and unauthorised disclosure or access. Reading address data out of the contact form meets it. An encryption attack that renders the database unreadable meets it as well, because the loss of availability counts too. An injected redirect to a foreign site without access to stored data usually does not.
Whether personal data is involved at all depends on how the site is built. A pure business-card page with no form and no login stores little; as soon as a contact form, a newsletter, a booking calendar or a customer area is added, the picture changes. Server logs with IP addresses count as well. Anyone who documented at set-up which system touches which data answers this question in minutes rather than days; the basis for that is the data processing agreements and the associated record.
Reporting duty: when the 72 hours start running
The deadline does not start with the attack and not with the completion of the investigation, but when the breach becomes known. From that point the controller reports without undue delay and, where feasible, within 72 hours to the competent supervisory authority, provided the breach is likely to result in a risk to the rights and freedoms of natural persons (Article 33(1) GDPR). If the deadline is exceeded, the report has to be accompanied by reasons for the delay. The clock keeps running, including over a weekend.
Reports are often postponed because not everything has been clarified. That is not necessary: where the information cannot be provided at the same time, it may be provided in phases without undue further delay (Article 33(4) GDPR). An initial report with what is known and a follow-up are the intended route, not a makeshift. The case where a service provider discovers the breach also matters: the processor then notifies the controller without undue delay (Article 33(2) GDPR), and the controller's deadline starts with that knowledge.
| Point | Report to the supervisory authority | Notification of data subjects |
|---|---|---|
| Legal basis | Article 33 GDPR | Article 34 GDPR |
| Trigger | Likely to result in a risk to the rights and freedoms of natural persons | Likely to result in a high risk to the rights and freedoms of natural persons |
| Deadline | Without undue delay, where feasible within 72 hours of becoming aware | Without undue delay, no fixed number of hours |
| Content | Nature of the breach, categories and approximate number of data subjects, contact point, likely consequences, measures (paragraph 3) | Clear and plain language, at least the information in Article 33(3)(b), (c) and (d) |
| Exception | A risk is unlikely to arise | Effective encryption, risk subsequently removed, or disproportionate effort with a public communication (paragraph 3) |
| Regardless of that | Documentation of the breach, its effects and the remedial action taken (paragraph 5) | Record the wording and the time of the notification |
In Lower Saxony the state commissioner for data protection is competent. Its figures show that reports have long been routine: for 2025 it records 1,607 personal data breaches, an increase of around 5 percent over 2024 (LfD Niedersachsen 2026). For 2018 it gives 370; the regulation has applied only since 25 May 2018, so that figure covers around seven months. The authority classifies its figures itself: they reflect submissions, not established legal violations. A report is therefore not an admission of guilt but a procedural step that is provided for.
What leaving it undone can cost
Preserve traces instead of deleting them
Documentation is not optional. The controller documents any personal data breaches, comprising the facts relating to the breach, its effects and the remedial action taken; that documentation has to enable the supervisory authority to verify compliance (Article 33(5) GDPR). It does not come together at the end from memory but alongside the work, and at the moment it is created it costs almost nothing.
Files and database
A complete copy of the web directory and an export of the database, taken before any clean-up and stored outside the affected server. Without that state it is hard to show later what was changed.
Logs
Access and error logs of the web server, logs of the content system, login attempts, transfer and remote maintenance sessions. How long the host keeps them varies by package; whoever waits may lose them without doing anything.
Timeline
A plain list with time, observation and the person acting. It later answers the question of when the breach became known, which the deadline hangs on, and assigns every measure to a point in time.
Visible damage
Screenshots of the changed pages, of the browser warning and of the search results. Those images disappear as soon as the site is cleaned and cannot be recreated afterwards.
External notices
Messages from customers, from the host, from a directory service or from a bank, with date and wording. They often establish the time of becoming aware more precisely than your own recollection.
Affected records
An estimate of which categories of personal data were accessible and roughly how many people are affected. Those are exactly the details the report under Article 33(3) GDPR asks for.
This collection is not a forensic report. It is the state a business can preserve without specialist tools, and it is enough to write the report, to work with the host and, in case of doubt, to brief an expert sensibly. In larger incidents, for example with encrypted data or access to payment details, the assessment belongs in expert hands; the secured copies are then the basis of that work.
The one file that counts
Recover access before anything is rebuilt
An attack does not end with the removal of a file as long as the credentials remain valid. In many cases the route does not run through a gap in the system at all but through a password that leaked somewhere else. That is why access is renewed completely, and from a device that had nothing to do with the incident. A password change typed on the machine that may have malware reading along is wasted time.
- Hosting control panel, remote maintenance and transfer access, database users: new passwords, old keys removed, unknown keys in the account checked.
- Content system: reset editors' passwords, end active sessions, go through newly created users and changed roles.
- Switch on a second factor for the administrative accounts wherever it is available and store the recovery codes somewhere that is not on the same server.
- Check domain administration and DNS: whoever redirects the name does not need the website at all; the article on moving domain and email clarifies who is responsible.
- Include connected accounts: mailboxes, payment connections, map services, directories and the verified business profile, so that nobody carries on there with old data.
- Replace interface keys and credentials in configuration files; they sit in plain text on a server a stranger has seen.
# Serve maintenance page, take content offline
RewriteEngine On
RewriteCond %{REQUEST_URI} !^/maintenance\.html$
RewriteCond %{REQUEST_URI} !\.(css|png|svg)$
RewriteRule ^ /maintenance.html [R=503,L]
ErrorDocument 503 /maintenance.html
Header always set Retry-After "7200"The status code is more than cosmetics. A 503 tells search engines that the address is temporarily unavailable and stops them adopting the maintenance page as new content. The Retry-After header names an order of magnitude in seconds alongside it. A redirect to another domain or a blanket 404 do more harm at this point than the downtime itself, because both are read as a permanent statement about the address.
If the site sits with a provider whose control panel does not allow such details, it is worth looking at the contract. Which points matter is in the article on choosing web hosting. Recovery time, log retention and a reachable contact are the points that make the difference in an emergency and that few people read when signing; in our web hosting they are therefore fixed in writing.
Rebuild: a clean state instead of an infected backup
The most common mistake in a rebuild is reaching for the most recent backup. If the access went unnoticed for two weeks, yesterday's copy contains the back door. The site then runs cleanly for three days and falls over again, this time with the loss of confidence that comes with a relapse. What is needed is a state from before the first sign, and to determine that you need the logs secured in the second step.
The controller shall document any personal data breaches, comprising the facts relating to the personal data breach, its effects and the remedial action taken.
The rebuild itself follows a sober order: restore the clean state, update every component, connect access with the new credentials, and only then go public again. Extensions that have not been maintained for months are dropped on this occasion rather than carried along. And a comparison between the restored state and the secured copy shows which content was created in the meantime and has to be added back by hand.
What becomes apparent in this phase: a rebuild rarely takes long because of the technology, but because of missing prerequisites. Access to the domain administration is missing, the backup sits on the same server that failed, or nobody knows which extensions belong to the operation and which were installed once for a test. Ongoing support closes exactly those gaps in advance; in the website subscription backups, updates and a maintained inventory list are part of the fixed scope.
Back into search: warnings, index, confidence
A cleaned site is not yet a restored site. As long as search engines display a warning or injected pages sit in the index, the commercial damage remains. If a Google assessment finds that a website has been hacked or behaves in a way that could harm a visitor or their computer, the findings appear in the security issues report in Search Console (Google Search Console Help). Hacked content there means any content placed on a site without permission, mostly due to security gaps.
After the clean-up comes the request for a review. In our experience it is accepted when it contains three things: an exact description of the problem, the steps taken to fix it, and evidence that they worked. Nobody should plan on a result the same day, because most reviews take several days or weeks (Google Search Console Help). That waiting time belongs in the communication with customers, not in daily frustration.
These commands replace no analysis, but they answer the questions that get asked first, and they do it without changing anything. Anyone who looks regularly at the figures in Search Console often notices injected pages there first: in search queries that do not fit the business, and in addresses nobody created.
What runs differently after the incident
After the rebuild is the moment when changes are cheapest. The attention is there, the people involved know the weak points from their own experience, and the budget question is answered differently than it would be four weeks later. Six points are worth it in almost every business, in our experience.
- Backups in a place that does not hang off the same access, with retention over several weeks instead of a few days.
- Test a restore instead of assuming it: a backup without a successful test run is an assumption, not an asset.
- Updates with a fixed date and named responsibility; the gaps that get exploited have usually been known for weeks.
- Cut access back to what is needed: editors rarely need administrative rights, departed service providers need none at all.
- A second factor for all administrative access and a password store instead of a spreadsheet in the mailbox.
- An emergency sheet with numbers, responsibilities and the order of steps, printed out and not only on the server that fails.
Worked through in order, these points produce a state in which a further attempt stays without consequence or at least shows up early. They replace no technical hardening, but they shorten the time between incident and discovery, and that time is the most expensive part of the whole affair.
The point that is missing most often
The emergency sheet for the next serious case
An incident plan that nobody can find in an emergency is not one. What helps fits on one page, hangs in the office and is additionally stored outside the affected system. Three blocks are enough for that.
Who gets called
Host with customer number and emergency number, technical support, the person holding the data protection officer role, and the management. With names and numbers, not with job titles.
What sits where
Where the backups are, who has access to the domain administration, where recovery codes are kept and which systems touch personal data. One page, reviewed once a year.
What happens first
The first five steps in a fixed order, the sentence about the deadline at the top: record when it became known, put the site into maintenance, pull copies, call the host, assess what is affected.
The sheet has a side effect that reaches beyond the emergency: writing it down shows what is missing. Anyone who cannot answer the question about access to the domain administration has found that out on a quiet Tuesday rather than at two in the morning. The same applies to clubs and practices, where responsibility changes hands more often than in a business: how that plays out for a club website with events, members and donations and for a medical practice website under professional advertising rules is set out in the two articles on those subjects.
When the personal data breach is likely to result in a high risk to the rights and freedoms of natural persons, the controller shall communicate the personal data breach to the data subject without undue delay.
This notification is the part most businesses are afraid of and at the same time the part that does the least damage when it is properly prepared. Anyone who writes early, factually and in plain language what happened, what is affected and what has been done ends up better off than someone who waits until somebody else tells the story. Which systems and which cookie banner settings collect data at all should be documented by that point. For building and continuously securing a site that survives such a day, our contact form is the shortest route.
Related Articles
Website Maintenance 2026: Secure Against Attacks
The BSI reports around 119 new vulnerabilities per day (up 24 percent). Why local businesses must regularly maintain their website and what upkeep covers.
Data processing agreements: what a website really needs
Which services behind a website count as processing on your behalf, what the Article 28 GDPR contract must contain and how the record of activities follows.
Moving domain and email without losing mail
Auth code, TTL, MX switch: how a domain migration actually runs, so the website stays reachable and no message ends up in a mailbox nobody opens any more.