Website security
& malware cleanup
in Vienna

Once a compromised site in Austria is stabilised, two separate obligations sit alongside the technical cleanup. The first is reporting the incident to CERT.at, the national computer emergency response team. It collects reports from operators across the country. It can offer guidance if the same attack pattern is hitting other sites. This step is not mandatory in every case. Even so, it is the standard channel, and it helps build the wider picture of what is currently circulating.

The second obligation is narrower and carries a hard deadline. Under the GDPR, if personal data was affected, exposed or likely exposed, the operator must notify the Austrian Datenschutzbehoerde. The window is seventy-two hours. It runs from the moment the operator becomes aware of the breach. That clock starts early, often before the full scope of the intrusion is understood. An initial report can and should be provisional, updated once the investigation is complete.

Deciding whether personal data was affected is not always obvious from the first scan. A defaced homepage with no database access is a different case. So is a contact form with stored submissions, or an account system with stored passwords, even hashed ones. Reviewing what tables, uploads and logs the access could plausibly have reached, before deciding a notification is unnecessary, avoids a mistake that is hard to correct later.

Evidence has to be preserved before remediation removes it. Copying logs, database snapshots and a full backup of the infected files, timestamped and stored separately from the live system, gives an investigation something to work from once the malicious code itself is gone. Wiping and restoring a site from a clean backup the moment it is discovered feels like the responsible move. It usually is, for the site itself. Doing it before anything is preserved destroys the trail a report may later need. A copy of the affected database taken before cleanup starts is worth more than any note written afterward from memory.

A short internal record of the timeline helps, whether or not the incident ever reaches a regulator. When was the anomaly first noticed. When was access cut off. What was changed, and by whom. This kind of record is cheap to keep at the time. Memory fades fast. It is close to impossible to reconstruct a timeline a month later, once the pressure of the outage has passed and the details have blurred.

None of this replaces the technical cleanup, and none of it should delay containment. Isolating the site comes first. Stopping the bleeding comes first. But the reporting and evidence steps run in parallel with that work, not after it. Treating them as an afterthought is the most common reason an otherwise well-handled incident ends up harder to close out than it needed to be.

Regulators reviewing a late or thin report tend to focus on process, not on the intrusion itself. Did the operator act promptly once aware. Was the scope assessed honestly. Was the data at risk described plainly, without minimising it. A site owner who can answer these questions with a dated record, rather than a reconstructed guess, is in a far stronger position than one relying on recollection alone. That position matters long after the malicious code itself has been deleted and forgotten.

A malware scan built to find infected files can miss the kind of compromise that matters most on an ecommerce site. A skimmer is a short piece of script inserted to copy payment details as a shopper types them. It stays invisible by design. It sends its own copy of the card data to an external server. The real transaction still completes normally, so nothing about the checkout looks broken to the person paying.

This kind of injection often does not touch the files of the site at all. It arrives through a third-party script: an analytics tag, a chat widget, an ad pixel, or any external library loaded into the checkout page. Compromise the vendor. Compromise the account controlling that script instead. Either way, every site loading it inherits the skimmer. Nothing on the site itself needs to be altered. A file-level scan finds nothing, because there is nothing local to find.

Spotting it takes a different method than a standard scan. Reviewing every script loaded on the payment page, and asking what each one is for and who controls it, turns up scripts nobody remembers adding. Sometimes a familiar script is now loading from an unfamiliar address. That is the tell. Comparing the current script list against a known-good inventory, taken when the checkout was last reviewed, is far faster than reading obfuscated code line by line.

A content security policy limits which external domains a page may load scripts from at all. That alone stops most surprises. An injected or hijacked script pointed at a new address simply fails to load. Subresource integrity goes a step further for scripts that are expected. The browser checks a hash before running the file, and a tampered copy is rejected outright rather than executed. Neither control is difficult to add to an existing checkout, and both catch a class of attack that file scanning cannot see.

Testing has to cover the payment form itself, and also the pages around it. Watching outbound network requests while a test transaction runs, and confirming that card data leaves only for the expected payment processor and nowhere else, is the most direct way to confirm a checkout is clean. Run it once. Run it again on a schedule. Doing this after a general cleanup, and repeating it regularly afterward, catches a reinfection long before it shows up as a wave of customer complaints or fraudulent charges.

The scripts allowed on a checkout page deserve the same change control as the code powering the rest of the site. Keep a record. What was added, when, and by whom. A review before anything new is approved for a page that touches payment data. Treating third-party scripts as fully trusted by default is how most skimming incidents start, and revisiting that assumption is cheaper than explaining a card data breach after the fact.