A Clean Rebuild Is Not a Data Inventory
Restoring a machine and accounting for the information on it are different incident-response decisions. One should not be used as evidence that the other is complete.
On 8 October 2026, Daiichi Kosho reported possible exposure after malware infected one Nippon Columbia Group employee PC. About 8.724 million records were potentially exposed, not necessarily that many people. Customer fields included registered name, sex, date of birth, email address and telephone number; employee records were also included.
Keep possibility and proof separate
The notice did not confirm leakage or misuse. It excluded passwords from the potentially exposed information and named no malware family or attacker. A 9 October update opened a telephone line and repeated that misuse remained unconfirmed. Those are dated company findings, not an independent assurance about what happened to every record.
A useful incident log separates observations from assumptions. Every unresolved conclusion needs an owner, the evidence needed to resolve it and a review time. Otherwise the language in a status report can become more certain merely because the recovery work has finished.
A plausible message is not an authenticated request
The company warned about suspicious email, texts and calls, unfamiliar links and attachments, and requests for passwords or card information. Knowing a customer’s details is not proof that an inbound contact represents the service.
For example, a message could describe a plausible reservation and then ask the recipient to confirm a payment. That is a hypothetical verification problem, not a reported fraud in this incident. The useful test is whether the same request can be found through a separately opened account or checked using a previously trusted contact route. A caller’s confidence does not answer that question.
If a suspicious interaction has already led to a sign-in, distinguish the exposed contact details from the credentials the reader subsequently supplied. Record which account was involved and when. Changing an unrelated password would not resolve a compromised session on that account. This is response guidance, not a finding that accounts were accessed here.
Give the data question its own closure test
BlackTree’s operational assessment is to separate service restoration from evidence-backed data scoping. Consider a hypothetical contractor export needed to answer customer queries. A recovery ticket might show that the workstation was rebuilt and the application works. A second record should identify the export, its authorised purpose, its expected lifetime and any remaining copies. Closing the first ticket should not automatically close the second.
That separation turns a broad instruction to review supplier risk into something an incident owner can verify. The service owner can accept restored functionality; the data owner can accept a documented account of what was present, what could reach it and which uncertainties remain. Neither should have to infer the other’s approval from a successful login.
Where evidence cannot establish whether information left the device, record that limitation instead of substituting a clean malware scan. Where a local copy is no longer needed, its removal should have a named owner and a checkable result. These are controls to assess, not findings that this contractor lacked them.
Related reading: why a familiar telephone number is not authentication.
Sources: Original incident notice, 8 October 2026; Telephone-line update, 9 October 2026.
