Business website vulnerability: what to do in the first 24 hours

An email arrives from your host, a warning from CERT Polska (Poland’s national computer security incident response team) or a message from your contractor: there is a vulnerability in your website’s software and it needs patching. A vulnerability is a flaw in the code that lets an outsider take over the website, add their own code to it or get to customer data. Once the information is public, criminals know it too, and they search for vulnerable websites with automated tools. Putting it off until next week is therefore risky.

Below you have a plan for the first day, in an order that protects you against typical mistakes: checking, backup, fix, passwords and traces, and finally assessing a data leak and filing reports. You can do most of the steps without a developer, and for the rest I suggest what to ask your host or contractor to do. I’m writing as of 7 November 2026. The parts about GDPR and the KSC Act (Poland’s National Cybersecurity System Act) are general information, not legal advice.

The hours in the headings are approximate. If you suspect from the start that someone got to customer data, read the part about UODO (Urząd Ochrony Danych Osobowych, Poland’s data protection authority) right away, because the 72-hour deadline runs from the moment you become aware of the breach.

Hours 0–2: check whether the vulnerability affects your website

Before you change anything, establish three things: what software the vulnerability affects, in which versions, and from which version there is a fix. Take them from the vendor’s announcement (e.g., php.net, nodejs.org, the plugin’s page in the WordPress.org directory) or from the database of a recognized company, for plugins for example Wordfence or Patchstack. Media articles often simplify version numbers.

Then compare this with your website:

• WordPress: in the dashboard go to Tools → Site Health → Info. There you will find the version of WordPress, PHP, the theme and plugins. Plugin versions are also visible on the list in the Plugins menu.
• Shared hosting: the PHP version is shown in the hosting panel, usually in the domain or PHP settings.
• A custom-built website, for example in Next.js or Node.js: ask your contractor. You will find a ready message below.

I describe how to find out what your website runs on, when nobody at the company knows, in the guide on checking your PHP, CMS and plugin versions.

Also check whether the vulnerability is being attacked in practice. The US agency CISA maintains the KEV catalog (Known Exploited Vulnerabilities), a list of vulnerabilities that have been exploited in real attacks. If the CVE number from the announcement is there, speed up all the following steps. In addition, on moje.cert.pl, run by CERT Polska, you can order a free scan of your domain. It won’t replace checking versions, but it can be a good second pair of eyes.

Hour 2: a backup before making changes

An update done in a hurry can take down a store or a form. That is why, before every change, you should make a backup of the files and the database and download it off the server. A backup kept only in the hosting panel can disappear along with the website.

Label the backup with the date and time, for example BEFORE-PATCH-2026-11-07-10-00. If you suspect someone has already gotten into the website, this backup is also evidence: don’t restore it later as a “clean” version. I explain why one backup is not enough and how to test restoring in the guide on website backups and the 3-2-1 rule.

Hours 2–6: update or workaround

The most reliable route is updating to the patched version given by the vendor. In WordPress, start with the plugin or theme affected by the vulnerability, and then do the remaining updates. After each change, check the home page, the contact form and, in a store, the whole ordering process.

When there is no fix yet or you can’t install it right away, apply a workaround, that is, temporary protection described in the vendor’s announcement. It can mean deactivating a plugin, turning off one feature in the configuration or a web application firewall (WAF) rule at your host. A workaround buys time but doesn’t close the matter, so put a date for the full update in your calendar right away.

Patched versions sometimes change: the vendor releases another patch when the first one turned out to be incomplete. Before updating, check the announcement on the vendor’s website once more, not just in a note from two days ago.

If the website runs on an old version of PHP or Node.js that no longer receives security fixes, there may be no patch for it at all. Then updating means moving to a newer version. That is a bigger change, which is worth handing to a technical person, but don’t put it off.

Hours 6–12: accounts, passwords, logs and new files

An update closes the door, but it doesn’t tell you whether someone got in before you closed it. That is why you should check for traces.

Administrator accounts. In WordPress, open Users and select the Administrator role. Every account that nobody at the company recognizes is a red flag: write down the login, email and creation date, and only then delete it. Also review the users of the hosting panel and Google Search Console.

Passwords. Change the passwords for the website panel, hosting, FTP/SFTP and the database, as well as API keys (e.g., for payments or email sending) if they were stored on the server. Do it from a computer you have no doubts about, and turn on two-factor authentication wherever possible.

Logs. Ask your host for access and error logs from the day the vulnerability was disclosed, before they are overwritten. Look for repeated requests to the addresses the vulnerability concerns and for logins to the panel from unknown IP addresses.

New and modified files. In the file manager, sort files by modification date. Changes that nobody made are suspicious, as are PHP files in image directories (in WordPress, wp-content/uploads).

If you find signs of a break-in, switch to the plan from the guide Hacked WordPress: what to do in the first hour. Most of the steps also fit websites running on other software.

Data leak: UODO, customers and CERT Polska

This part concerns situations where someone may have had access to customer data: orders, accounts or form messages. A vulnerability alone that nobody exploited is not yet a personal data breach.

UODO within 72 hours (Art. 33 GDPR)

Under Art. 33 GDPR, the data controller reports a breach to the President of UODO without undue delay and, where feasible, not later than 72 hours after becoming aware of it. A report is not needed when the breach is unlikely to result in a risk to the rights and freedoms of individuals. A report sent after 72 hours must be accompanied by the reasons for the delay.

You can file the report online through the form on biznes.gov.pl, signed with a Trusted Profile (profil zaufany) or a qualified electronic signature. When the deadline is running out and you don’t yet know all the details, send an initial report and complete it later. A template of the form is on the UODO website, and for general questions the office’s hotline can help: 606 950 000, on business days from 10 a.m. to 2 p.m.

Art. 33(5) GDPR requires documenting every breach, including one you don’t report to UODO: what happened, what the effects are and what was done. Notes kept according to this plan are a good start. Discuss the risk assessment in a specific case with a lawyer or a data protection officer.

Notifying customers (Art. 34 GDPR)

When a breach is likely to result in a high risk to customers, for example if passwords to their accounts have leaked, Art. 34 GDPR requires notifying the individuals themselves, also without undue delay. Write in clear and plain language: what happened, what the possible consequences are, what has already been done and whom to contact with questions. Adapt the template below to the facts and include only what you know for certain:

Hello, on [date] we detected unauthorized access to our website. The first name, last name, email address and phone number provided with orders may have been disclosed. We have closed the vulnerability, changed passwords and reported the matter to the data protection authority (UODO). Please be careful with messages that refer to your order and ask for an additional payment or login details: we do not send such requests. Please send any questions to [email].

CERT Polska

You can report an incident to CERT Polska through the incydent.cert.pl form. The team operates within NASK (a Polish state research institute) and also handles reports from companies that are not covered by the KSC Act. This does not replace a report to UODO: they are two different institutions with two different purposes.

NIS2 and the KSC Act

If your company is an essential or important entity within the meaning of the Act on the National Cybersecurity System (ustawa o krajowym systemie cyberbezpieczeństwa, KSC), amended in 2026 (Journal of Laws 2026, item 252), it is subject to separate deadlines for reporting major incidents to the competent CSIRT, including an early warning no later than 24 hours after detection. Most small businesses are not covered by this act. I describe how to check this in the guide Who does NIS2 apply to?

What to ask your host and contractor to do

Your host and contractor often have what you don’t: server logs, technical access and backups from the last few days. Who is responsible for what depends on the type of hosting and the contract, which I write about in the guide on who is responsible for website updates. On the first day, ask for specific things, preferably by email, so there is a record:

Hello, in connection with the vulnerability [name and CVE number], please provide: 1) information on whether the website [address] uses a vulnerable version and when it will be updated; 2) a copy of the files and the database from before the update; 3) access and error logs since [vulnerability disclosure date]; 4) information on whether there are any signs that the vulnerability has been exploited. Please reply today by [time].

If your host or contractor processes your customers’ data on your behalf, Art. 33(2) GDPR obliges them to notify you of a breach without undue delay. The decision to report to UODO is yours as the controller, though, so don’t wait passively for their assessment.

A 24-hour checklist to print

Print it and keep it with your hosting login details. For each item, write down the time and the person who did it.

1. I have the vendor’s announcement: software name, vulnerable versions, patched version, CVE number.
2. I know which version my website uses and whether the vulnerability is in the KEV catalog.
3. A backup of the files and database has been downloaded off the server and labeled with the date.
4. The fix is installed or the workaround is on, and the date for the full update is in the calendar.
5. The website, form and orders work after the changes.
6. List of administrators checked, unknown accounts written down and deleted.
7. Passwords and API keys changed, two-factor authentication turned on.
8. Logs and new files reviewed or handed over to the host.
9. Assessment of whether personal data may have leaked. If so: a report to UODO within 72 hours and a decision on notifying customers.
10. A note on the course of events saved.
11. A decision on reporting to CERT Polska.

Summary

The order matters: first establish whether the vulnerability affects you, then the backup, the fix, passwords and traces, and finally the leak assessment and reports. Write everything down as you go, because these notes will be useful both to the authority and to your contractor.

If you would rather have someone keep an eye on this for you, choose technical maintenance. In the Watch plan (from PLN 149 net a month) I monitor your website every 5 minutes, make an off-server backup every week and install urgent security updates within 2 days. Standard (from PLN 349 net a month) means daily backups and a response within 1 business day, and Pro (from PLN 749 net a month) a response within 4 hours, including failures on weekends. After an incident, it’s worth ordering a security audit with a report and fixes, from PLN 990 net. If the vulnerability already affects your website, write to me: I reply within 24 hours.