Website security
& malware cleanup
in Toronto

Cleaning an infected website in Canada raises a legal question that the technical work cannot answer on its own. Was personal information exposed? Under PIPEDA, the private-sector privacy law that covers most commercial organizations in the country, the answer changes what a business owes to the regulator and to the people whose data it holds. The cleanup team does not make that call. It does supply most of the evidence the call depends on.

The law speaks of a breach of security safeguards. That covers loss of personal information, unauthorized access to it and unauthorized disclosure of it. A skimming script on a checkout page fits easily. So does a backdoor that gave an attacker a route to the customer table, even when nobody can yet prove the table was copied. A defaced homepage with no path to stored data may not qualify at all. The difference has to be established, never assumed.

When a breach creates a real risk of significant harm to an individual, the organization must report it to the Office of the Privacy Commissioner of Canada and notify the affected people. Both steps are due as soon as feasible once the organization has determined that a breach took place. Significant harm is read broadly. It includes humiliation, damage to reputation or relationships, financial loss, identity theft and negative effects on a credit record. Two factors drive the assessment. How sensitive is the information? How likely is it to be misused?

Other organizations may need to hear about it as well. If a bank, a payment processor or a government institution could reduce the risk of harm, the law expects them to be told. Card skimming is the obvious example. A card issuer can watch the affected accounts for fraud far better than the merchant ever could.

Then comes the record. Every breach of security safeguards has to be recorded, including the ones that never reach the harm threshold. Each record must be kept for two years. The Commissioner can ask to see them. A line saying the site was hacked and has been fixed will not carry much weight in that conversation. A useful record shows what happened, when it was found, which data was involved and why the organization chose to report or not to report.

This is where the cleanup method starts to matter. A rushed fix that deletes infected files, restores a backup and wipes the server removes the malware and the evidence together. Afterwards nobody can say whether the attacker reached the database. That doubt tends to push the risk assessment toward notifying everyone, which is costly and alarming for customers.

Before anything is deleted, a careful team preserves a copy. That means web server access logs, error logs, hosting panel activity, database query logs where they exist, and a snapshot of the infected files with their modification times intact. The copies go somewhere the attacker could not reach. Every step of the work gets a timestamp as it happens. So does the first sign of trouble, and the moment access was cut off.

From that material the team can answer what the privacy lead will ask. Which tables could the malicious code read? Did any request pull customer data out in bulk? Were stored passwords hashed, and with what? Did payment details ever sit on the server, or did they pass straight to a processor? How many days was the hole open? Each answer either narrows the group of affected people or shows that no personal information was touched.

The cleanup report should be written for that reader. Plain language helps. So do a dated timeline, a list of the data categories at risk and a frank statement of what the evidence cannot show. Gaps are normal. A log retention period that turned out too short is a finding in its own right, and extending it belongs in the hardening plan. The privacy adviser then has something solid to work from.

Once malware is confirmed, there are two broad ways to get rid of it. The first is to clean in place: find every injected line, every rogue file and every altered setting on the live server, then remove them one by one. The second is to rebuild. The team sets up a fresh environment, installs the platform and extensions from official sources, brings across only content that has been checked, and points the domain at the new copy. Both work. They fail in different ways.

Cleaning in place is faster when the infection is shallow. A single injected script in a theme file, found early, with clear logs showing how it arrived, can be removed in an afternoon. The site stays online and nothing about hosting changes. The weakness is completeness. Attackers rarely leave one door. A second backdoor hidden in an image folder or a forgotten plugin will reopen the site a week later.

Rebuilding trades speed for certainty. Nothing from the old server is trusted by default. Core files come from the vendor. Plugins and libraries come from their official repositories, at current versions. Custom theme code is compared line by line against version control, if it exists. Uploads are scanned and stripped of anything that is executable. What survives that filter is known to be clean.

The choice usually turns on a few plain questions. Is there a clean copy of the custom code somewhere outside the server? How long was the attacker inside? Was the infection found by the owner, or by a search engine warning after weeks? Has the site been reinfected before? The longer the dwell time and the weaker the records, the stronger the case for a rebuild.

Custom code without version control is the hard case. If the only copy of the theme lives on the infected server, a rebuild still has to start from it. The team then reads each file by hand, which is slow but finite. It is often the moment to put that code into a repository for good.

Content needs its own filter. Posts and pages are stored in the database, and malicious markup can hide there as easily as in files. Exporting content through the platform, reviewing it for scripts and iframes, and importing it into the fresh install is safer than copying the database whole. User accounts deserve the same scrutiny. Any administrator nobody recognises should not make the trip.

A rebuild also brings a chance to move hosting, change file permissions and switch off features nobody uses. Those changes are cheap during a rebuild and awkward afterwards.

Whichever route is chosen, the old environment should be kept offline for a while. It is the evidence. If something reappears, comparing it with the rebuilt copy shows quickly whether the new site was compromised again or something was carried across by mistake.