What should you do if your business website is hacked?

An owner opens the business website and finds a changed homepage, an unfamiliar payment link, or a contact form that no longer sends inquiries to the team. Is the site hacked, and should someone immediately restore yesterday’s backup?

First, treat the change as a suspected incident. Record what you see, contact the people who control the site and its accounts, and protect visitors from an unsafe page or form. Have a qualified responder verify the cause and scope before replacing files or restoring a backup. A clean-looking homepage is not proof that the accounts, inquiry data, or underlying software are safe.

This is a response guide for the moment something looks wrong. Our website security ownership guide covers the earlier job of assigning updates, backups, access, and alerts before an incident.

Use the national figure as context, not a website breach rate

In Statistics Canada’s 2025 Canadian Survey of Cyber Security and Cybercrime, 15% of small businesses were impacted by a cyber security incident. In this survey, “small” means enterprises with 10 to 49 employees; the survey excludes smaller firms, public administration, and some sectors and lower-revenue enterprises. Respondents reported incidents that affected them during 2025, across their operations, rather than website compromises alone. The figure cannot estimate the chance that your site has been hacked. It does show why a response route belongs in a business plan even when the website seems ordinary.

Verify the signal and get the right people involved

Write down when and where the problem appeared. Save the affected URL, a screenshot, and the exact message or redirect, along with the device and account used to see it. Note who first noticed it and what changed recently. Do not ask staff to keep visiting a page that may deliver malicious content. Avoid entering passwords or customer data into the suspect site.

Contact the site’s host or platform, developer, and the person who manages the domain, using known contact details outside the affected website. If the problem may involve business email or a payment provider, contact those providers too. One person should coordinate decisions and keep a time-stamped record of what each provider finds and changes. The Canadian Centre for Cyber Security’s compromise guidance recommends gathering the time of suspicion, affected systems, access history, update history, and potentially exposed information so a technical team can verify the incident.

There are several plausible explanations. A legitimate but mistaken content edit can look like defacement. A changed DNS record can send visitors to another server while the original site files remain intact. A compromised administrator, plugin, application, or form service can change content or capture inquiries. A responder should distinguish these paths; a routine page rollback may hide the symptom while leaving the entry point open.

Protect visitors without destroying the trail

If a page is visibly unsafe, ask the host or qualified responder to remove it from public use or show a safe maintenance page. If a form or checkout could be sending information to an unknown destination, pause that function and give customers an alternative contact route that the team has verified. The Cyber Centre’s website defacement guidance calls for contacting the vendor, using a maintenance page, examining content and backups, and involving technical support. The exact containment method depends on how the site is hosted.

Preserve logs, suspicious files, account events, and the current state before cleanup. Ask the provider what evidence can be retained and for how long. If an employee device may also be compromised, follow a qualified incident responder’s instructions before rebooting or wiping it; the Cyber Centre notes that powering off a device can destroy volatile evidence. An owner does not need to perform forensics personally, but should avoid a rushed “delete and hope” fix.

The responder may isolate an affected service, revoke a compromised integration, or limit account access. Change credentials through a known-good device and the provider’s legitimate sign-in page, in the order the responder recommends. Review administrator accounts, recovery methods, deployment access, API keys, and connected services. Do not assume a password change alone removes malicious files or closes a software vulnerability.

Find out what the website could reach

Make a simple map of the affected service and its connections. Does the site only publish pages, or can it read form submissions, a booking calendar, a client portal, an order database, or payment settings? Where do inquiries go after submission? Which accounts can change those destinations? The answer determines both the technical investigation and the customer impact.

Keep a list of what is confirmed, suspected, and not yet known. For example: “The public page was altered” may be confirmed while “customer records were viewed” remains unknown. Do not tell customers that no data was affected just because no one has found evidence yet. Conversely, an altered page does not prove that a database was stolen. Ask the host and relevant specialists to review access logs, account changes, form destinations, and backups against the incident window.

If personal information may have been involved, bring in the business’s privacy lead or qualified counsel promptly. The Office of the Privacy Commissioner of Canada’s breach guidance explains that organizations subject to PIPEDA must report qualifying breaches that pose a real risk of significant harm, notify affected individuals, and keep breach records. Which privacy law and notice duties apply can depend on the business, data, and jurisdiction. A site developer cannot make that legal assessment from a screenshot.

Restore service only after the entry point is addressed

Ask the responder to identify the likely path in: an exposed account, vulnerable software, changed DNS, or a provider-side issue. Fix or isolate that path before restoring content. Inspect the backup itself and choose a copy from before the suspected change; a recent backup may already contain malicious content. Restore into a controlled environment when possible, then check page files, software versions, administrator access, integrations, and data connections before reopening to the public.

Test the whole customer journey after recovery. Open the site from a device and network outside the team, follow key navigation, submit a safe test inquiry, and confirm that it reaches the intended staff inbox. Check booking and payment paths if the site has them, without using real customer details for tests. Review mobile views and both languages the business actually serves. Continue monitoring account changes, redirects, form delivery, and provider alerts after the site returns; the first clean page load is only one check.

For a bookkeeping practice, this might mean the owner asks the host to pause a suspicious inquiry form, the technical responder checks its destination and administrator history, and the practice’s privacy adviser assesses whether any personal information was exposed. Staff use a verified phone or email route while the form is unavailable. This is an illustrative sequence, not a claim about a client incident or a guarantee that a particular response is sufficient.

Communicate what you know and who is responsible

Give staff one approved status message and an alternate customer contact method. If a public page was unsafe, explain which service is paused and how customers can reach the business. Make factual updates as the investigation develops; avoid a confident all-clear before the evidence supports it. A privacy specialist should review any required notice to affected people. The host, insurer, payment provider, and law enforcement may each have their own reporting or preservation needs, so keep a record of who was contacted and why.

Afterward, turn the incident notes into a short working plan: who can disable a page, who calls the host, where backups live, who assesses personal information, and who approves customer messages. Test those contacts before the next emergency. If the current site cannot be safely maintained or recovered, the business may need a separate security specialist and a scoped rebuild. A new design alone does not resolve compromised accounts or data.

Red Comet designs and develops business websites. If you are planning a new site after an incident, we can discuss its pages, contact path, and handoff responsibilities; security investigation and legal breach assessment need the appropriate specialists. Bring the incident record and the lessons from recovery so the next site’s scope is based on what actually failed.

Sources

• Statistics Canada, Impact of cybercrime on Canadian businesses, 2025, released October 21, 2026.
• Canadian Centre for Cyber Security, What to do when your organization has been compromised by a cyber attack, modified January 21, 2026.
• Canadian Centre for Cyber Security, Website defacement.
• Office of the Privacy Commissioner of Canada, Report a privacy breach at your business, modified June 23, 2025.