From our other sites
The story
It was reported on September 30, 2026 that TOPPAN, during a data transfer job entrusted to it by Sompo Japan Insurance, made a drag-and-drop error and sent the personal information of roughly 170,000 policyholders to the wrong company instead of the intended recipient. On 5ch, discussion centered on whether “operational mistake” was really a fair description — many argued the true cause was a failure to double-check before sending — while others called for scrapping manual-work-reliant processes altogether, sparking debate over how to genuinely prevent a repeat.
Published
September 30, 2026, 8:44 AM
Author
Source: itmedia.co.jp / Original article here
What people said
It's the same problem even with manual work.
And with a CLI, there's the horror of your `history` (command log) coming back to bite you.
Fine if it's your personal mouse, but if you're using one for work and it's double-clicking on its own (chattering), replace it immediately.
drag-and-drop really is
prone to slipping off target.
Even then, mistakes still happen sometimes, though.
There's no way the customer database is actually connected to the open internet… right?
If the PC's specs are garbage, it can stutter and the drag can release without you noticing, moving the file somewhere you never meant it to go.
It shouldn't be framed as "due to a drag-and-drop mistake" —
it should be "a drag-and-drop mistake" AND "a failure to double-check."
Sending straight off a drag-and-drop without any verification doesn't add up, so
ultimately the main cause was failing to check before sending.
It's obvious they're trying to hide a bigger failure and make it look
like a minor operational slip, lol
Good point, exactly right.
This happens a lot —
the media pulling its punches out of deference.
All you can really do is encrypt it and store it so it's only ever handled on your own company's machines — basically keep it locked down "hell-safe" (a jokey, garbled riff on "fail-safe").
or just use separate PCs for each.
You're supposed to double-check BEFORE the "ta-daa," lol
They always say this kind of mistake will be "corrected," but is there an actual fix?
Cut out the manual work.
Cut out single-person processing.
It's bad enough that the vendor is treating 170,000 files like some ad-hoc, non-standardized task.
They say they're moving it to ServiceNow or AI, sure — but on a totally unrelated note, ServiceNow's McDermott was actually at Trump's gathering of tech-industry bigwigs yesterday, showing up flashy enough to look like a rock star. He's tight with that guy in the leather jacket (Jensen Huang) — they show up at each other's annual events, and it's basically a running bit that the two of them, Jensen and McDermott, always end up together in a Bloomberg interview.
Okay, that went completely off-topic.
Sending data outside the company is a pretty critical action,
so it should require sign-off from multiple people.
How much are they even getting paid for this contract?
Just build a proper system for it.
Though the manager's probably just as careless,
given they let the workflow get this sloppy in the first place.
who accessed it,
who copied it,
who updated it —
right?
There's zero recognition that the actual owner of that data is the person it's about.
And that goes for the insurance company that outsourced the work too.
Even with My Number (Japan's national ID) data,
Japan doesn't operate on the idea that the data belongs to the individual it describes.
Everyone who has accessed that data —
meaning everyone who's
looked at it, touched it —
should be made known,
every single one,
to the person the data is about.
That's what real privacy actually means.
Bet you don't get it, do you?
Contractually, anyway.
Why'd they just let it go through as-is?
I think banks used to do something like that back in the day.
Companies really should separate the internal LAN from the external LAN with a two-PC setup in the first place —
but since that's not happening, misdeliveries like this are bound to keep occurring.
Background and Key Points
TOPPAN has been shifting its business from printing toward information and data-processing services, and handles large volumes of personal data on behalf of client companies such as insurers. In this incident, the company was sending policyholder data via drag-and-drop as part of that work when the file was dropped onto the wrong destination, leaking data on roughly 170,000 people. Where opinions on the thread split was over how fair the “operational mistake” framing really was: comment #19 argued that the true cause was a failure to check before sending, and that calling it a mere “operational mistake” downplays where the responsibility actually lies. Many commenters also called for mandatory multi-person approval, automated system checks, and eliminating manual handling altogether — the shared view being that treating this as simple human error won’t actually stop it from happening again. Notably, this comes around the same time as a report that car-share giant Times leaked roughly 6 million records, putting renewed scrutiny on how outsourced work handling large volumes of personal data gets checked.
*This article is excerpted and summarized from the 5ch (Business News+) thread “TOPPAN Mistakenly Sends Data on 170,000 Sompo Japan Policyholders to Another Company Due to a Drag-and-Drop Error.”
Leave a Reply