TL;DR
- 01What happened
On 28 September 2026, the Tokyo Metropolitan Housing Supply Corporation mailed 1,997 copies of a notice about a change in how to apply for drain-pipe cleaning to the residents’ association heads of Tokyo public housing complexes. In 846, the address was wrong, and 770 reached residents other than the intended recipients. What arrived was the names of 770 public-housing residents’ association heads. The Corporation and the Tokyo Housing Policy Headquarters announced it on 16 October.
- 02Why no one noticed
It was not a cyberattack. When building address labels from an Excel list, staff took the building and unit numbers from the wrong part of the list and attached the labels without noticing. Each label still looked like a proper address; only matching it against the source list would show the error. It was a resident, not the Corporation, who noticed, 15 days after mailing.
- 03The missing layer
What did not work was a layer that checks, apart from the operator and directly before dispatch, that destination and list match.
What happened
- Work
- mailing a notice to residents’ association heads of Tokyo public housing. The Corporation, a policy partner organisation of the Tokyo Metropolitan Government, maintains the public housing under contract.
- Content
- the notice “Change to the drain-pipe cleaning application method”. Labels were wrong, so notices reached residents of other buildings and units.
- Count
- 846 of 1,997 notices were misaddressed; 76 were returned and 770 reached someone other than the intended recipient.
- Information involved
- the names of 770 residents’ association heads. The release does not say addresses leaked.
- The error
- when building address labels from an Excel list, the building and unit numbers were quoted from the wrong part of the list. Which column was mistaken is not disclosed.
- Not addressed
- the release does not mention secondary leakage or misuse.
Glossary
Address label — A label printed with the recipient's address and name, stuck on the envelope. Here it was built from an Excel list.
Policy partner organisation — A body that carries out Tokyo Metropolitan Government policy in partnership with it. The Corporation is one, and maintains Tokyo's public housing under contract.
The irreversible step was ④, dispatch. The announcement does not say whether any step between ③ and ④ checked the labels against the source list.
The list holds complex, address and name.
Which column was mistaken is not disclosed.
Each label looks like a proper address.
846 misaddressed; 770 reach other residents.
Dispatch rested on labels built from the wrong part of the list. The problem is that those labels went through to dispatch at step 4 without being matched to the source list.
Timeline — disclosure and response
- notices mailed.
- a resident who received a misdirected notice contacted the Corporation; the error came to light.
- the Housing Policy Headquarters and the Corporation announced it.
Facts here rest on the Tokyo Metropolitan Government press release. The error is described only as quoting the building and unit number “from the wrong part of the list”; which column was mistaken is not given. Figures for mailings, misdirected items and names are the published values and have not been independently verified.
After disclosure
- Individual contact: the Corporation is contacting association heads and affected recipients individually to apologise and explain.
- Prevention: stronger checks by multiple staff members.
From mailing to discovery was 15 days; from discovery to announcement, 3. The signal came from the recipient side, not the sender.
Why it wasn’t stopped
The failure is neither operator skill nor outside attack. Dispatch ran with no means of checking that the label content matched the source list.
The address labels went all the way to dispatch without ever being matched to the source list.
That is the gap between detection and proof. It was a resident, not the Corporation, who noticed, calling 15 days after mailing. What failed sits before that. As far as the announcement shows, nothing directly before dispatch checked, apart from the operator’s eyes and memory, whether these labels matched the list.
The Corporation’s prevention plan is stronger checking by multiple staff. More checkers help, but they do not leave a verifiable record that a check happened or what was compared with what. A human check remains the checker’s memory and the fact of having checked.
The same structure appears in earlier Briefs. In TOPPAN and Sompo Japan, the contents of a manually assembled ZIP were not rechecked before sending. In the review-screen check at the payment fund, the act of checking did not serve as evidence of execution. In the Hokkaido hospital HDDs, media left the building with the premise unverified. In each, no independent check sat directly before execution.
“Checked” and “checkable” are different facts. The first lives in memory; the second is recorded before the action.
How to counter this
Operator mistakes cannot be eliminated, but a wrong label can be stopped before dispatch. Keep a record of which row of the source list each label was built from, and just before dispatch match the labels against the list by a means other than the operator’s eyes. Do not send what does not match. When label-making or dispatch is handed to a system or an AI agent, put the same match in front of dispatch.
Industries and operations to watch
- IndustryGovernment & public sector
- Municipalities and affiliated bodies that mail notices to residents or associations in bulk from a roster or list. Notices carry names, roles and other details meant only for the addressee.
- OperationSending & delivery
- Building addresses from a list, then enclosing, labelling and mailing. An address error does not show until the item has arrived.
The same hole exists wherever mail is produced from a roster: mail-merge addresses, labels built from a spreadsheet, dispatch data prepared by a contractor. In each, shifting one reference in the list shifts every row, and the result still looks plausible to the person who made it.
Do today’s controls close it?
| Control | Here | Why |
|---|---|---|
| Visual checks by multiple staff (the Corporation’s prevention plan) | Partial | More chances to notice. But what was compared with what is not recorded, and plausible-looking addresses can still be missed. |
| Spot checks | Partial | Easy to catch when every row shifted the same way. When only some rows shifted, they pass unless they fall into the sample. |
| Personal-data handling training | Partial | Raises care. Reference mix-ups happen even when people are careful. |
| Email misdelivery-prevention tools | Not relevant | They check email recipients and have nothing to do with paper mail. |
- Build addresses tied to rows of the source list. Record, for each label, which row of the list it came from. Reduce manual choice of which column to reference, and make every label traceable back to its row.
- Before dispatch, match every item by a means other than the operator. Mechanically match each label’s destination to its row in the source list, and confirm no destination falls outside the mailing’s scope (which notice goes to which recipients). Do not dispatch until the match is done.
- Record the match separately from the operator’s actions. Keep when, against which list, and which labels were matched and let through, in a form you can later show a third party. Hold what does not match, and record why.
Three things to confirm for work that produces mail from a roster or list
- Can each row of the address labels or dispatch data be traced back to the row of the source list it was built from?
- Before dispatch, does someone or something other than the person who made the labels match every address against the source list? If they do not match, can dispatch be stopped?
- Is the fact of the match, and what was compared with what, kept as a record rather than in the checker’s memory?
Note: this still fails if the source list itself is wrong, or if items are mixed up at the enclosing or labelling stage after the match. Holding dispatch until every item is matched also delays mailings.
Sources
- primary, municipal releaseTokyo Metropolitan Government, Housing Policy Headquarters “On the leak of personal information” (Japanese)
Only the parties’ own release serves as primary here; no independent third-party verification or English-language outside reporting has been found, and this is a single source. Japanese media and blogs are not used as sources.
References: why after-the-fact detection is not proof is covered in the last layer left in AI-era cyber defense. The pillar view is Pillar 01 — provenance proof.