A Company PC Was Hacked: Three Questions

1. Three questions that decide how big this is

Why those three. How long they were in decides how far back you have to trace the impact. Which data they touched decides whether you have to report it and who has to be told. Whether they are still there decides whether you can keep operating normally today. A boss or a client wants those three sentences. The rest of the detail is not what they are asking for.

The awkward part is that none of the three is answered by scanning. A scan tells you what is on the machine. It cannot tell you what day it arrived or what it did. The traces that answer those questions are scattered across execution history, scheduled tasks, account creation times and outbound connections, and every one of those can be damaged by a reinstall, by a cleanup tool, or simply by shutting the machine down.

2. Do not let the person involved handle it

This sounds unkind, but in practice it is the most common source of lost evidence. Whoever notices their machine behaving oddly will usually try to help first: run a scan, delete the suspicious file, clear temporary files, or just restart. Every one of those actions removes traces.

One more practical point: do not discuss the details in a group chat. If the other side is still inside the network, your company messaging may well be visible to them too. Use the phone, or talk in person.

3. What to preserve

The principle is to collect before you fix, and to change as little as possible about the machine while collecting. That is why installing a pile of tools on it is a poor idea. In practice what you need is the running processes, the startup items, scheduled tasks, local accounts, outbound connections, and the system and security event logs.

4. If personal data is involved, the clock is tighter than you think

If that machine holds personal data belonging to customers or staff, this stops being purely an IT matter. In Taiwan, the amended Personal Data Protection Act, the PDPA, brings incident reporting into the law: an incident that meets the threshold has to be reported to the regulator within a fixed window, and above a certain scale the affected individuals have to be told as well. The draft implementing rules set that window at 72 hours from the point you become aware, not from the point you finish investigating, and there are often several days between those two moments.

If you operate outside Taiwan, the shape of that duty is similar but the specifics are not. The EU GDPR also runs a 72-hour clock, while other jurisdictions count from a different starting point, set different thresholds, or report to a different authority again. Treat 72 hours as an illustration of how little room these regimes leave, then check what your own regulator actually requires. The deadline that binds you is the one where you operate.

Either way the practical consequence is the same: you cannot wait until everything is understood before the clock starts. The workable approach is to run two tracks from the moment the problem surfaces. One establishes what happened technically. The other establishes whether you have a duty to report and by when. Do not let the investigation eat the reporting window.

5. How the check itself works

The process is straightforward. A collection tool runs on the machine, it produces an output file, that file gets interpreted, and you get a report setting out what was found, what needs dealing with, and what can be left alone. Running the tool takes a few minutes to a quarter of an hour. The time goes on the interpretation.

There are two ways to run it, and the choice is yours. Either I go in with administrator rights and collect, or you run the tool yourself and send the output file back. The second is often easier to agree to in a company, because nothing has to be opened up for remote access and the machine stays with you. Same tool, same output. The only difference is whose hand presses go.

It covers desktops and servers, priced per machine, and currently supports Windows. So the office PC that got hit and the server in the comms room go through the same service rather than being scoped as two separate jobs.

6. What matters more than the investigation itself

Once the report is in hand, three things actually need doing: close the way in, deal with the other affected machines together, and keep this incident's timeline as a record. The third gets skipped most often, and it is the one that comes back. Client security questionnaires, audits and tender documents all ask you to show that incidents get handled, and that is not something you can produce on the spot.

One more thing worth doing while you are here. If the way in was a phishing email, the same email probably reached other people in the company. Rather than sending everyone a warning to be careful, run an actual test and see how many click. That is a separate exercise with its own written authorisation to sort out first, but it tells you something a warning email never will.