Key takeaways

  • ApplyNow, which runs recruitment platforms used by Japanese employers for video interviews and electronic employment contracts, has published its final report on a breach of data on about 397,000 job applicants, workers and client staff. For about 30,000 who signed employment contracts, the data included My Numbers, bank accounts, basic pension numbers and residence card numbers.
  • Among four causes, it lists one that is easy to overlook: it had no retention period, and had not deleted the data of companies that had stopped using its services.
  • The same gap runs through this year's breaches. MUJI kept card numbers from a perk scheme it changed in 2021. Yumil Link's address books held login details for a client's service that closed in February. Monex Securities lost email addresses of people who never finished opening an account.
  • In each case, something ended: a contract, a scheme, a service, an application. In our view, deletion fails because those endings rarely have an owner. Japan's privacy law asks businesses to make an effort to delete data they no longer need; for My Numbers, the regulator's guideline says they must be deleted once the legal retention period has passed.

What happened at ApplyNow#

ApplyNow, a subsidiary of Kichiri Holdings, runs three services: Interview Cloud for sharing interviews, ApplyNow for recorded video interviews, and ApplyNow Sign for electronic employment contracts. According to its final report of November 4, based on an outside forensic investigation:

Date Event
Aug 9 An attacker exploits a vulnerability that the provider of a data analysis tool used inside ApplyNow had already published, gets in and takes administrator rights
Aug 23, 26 Part of the service databases connected to the tool is viewed
Sep 7 The data is taken in bulk. ApplyNow notices when the tool stops, disables the attacker's accounts and blocks the route the same day
Sep 9 First notice: data "may have" leaked; count unknown
Oct 9 Leak confirmed: about 390,000 people
Nov 4 Final report and final report to the privacy regulator

What leaked depended on the service. Applicants' names, phone numbers, email addresses and, for some, birth dates, addresses, schools and interview dates. Client companies' staff accounts, with hashed passwords. And for people who signed employment contracts through ApplyNow Sign, some or all of: My Number (the number only, not card images), bank name and account, basic pension number, residence card number, employment insurance number and information for dependant tax deductions. Interview videos and uploaded files were kept elsewhere and did not leak. ApplyNow says it has found no misuse.

ApplyNow names four causes:

  1. It did not know about the vulnerability the tool's provider had published, and patched late.
  2. It did not restrict where connections to the tool could come from.
  3. It had a way to detect and report unauthorized operations, but noticing took time.
  4. The analysis tool could read data that included personal information. And there was no retention period: data of companies and organizations that had ended their use of its services had not been deleted.

It has not said how many of the 397,000 records belonged to clients that had already left.

The pattern: data left behind when something ends#

ApplyNow's fourth cause is not unusual. In this year's breaches, data kept after the reason for it ended keeps turning up:

What ended Case What was still there
A client stopped using the service ApplyNow Applicants' and workers' data of former client companies
A perks scheme changed, in July 2021 MUJI Full card numbers of about 1.09 million MUJI Card holders, about 745,000 of them for cards that no longer work
A client's own service closed, in February 2026 Yumil Link 420,419 sets of login details for that service, in the client's mailing address books
An application was never completed Monex Securities (breach list) Email addresses from account applications since 2019, including people who never opened an account
A member left, or never finished signing up Times Car Identity document images kept for seven years after members left, and data on people who never completed registration
A system was migrated, in 2018 skyticket Payment logs with card numbers, left on a server after card storage stopped

We looked at the wider case for collecting and keeping less in an earlier article. What these cases add is when deletion should have happened. Each had a clear moment: the day a contract ended, a scheme changed, a service closed, an application was abandoned, a system was replaced. Nothing happened at that moment.

What Japanese law expects#

  • Personal data in general. The Act on the Protection of Personal Information (APPI) asks businesses to make efforts to delete personal data without delay once it is no longer needed for its purpose (Article 22). It is an effort duty, not a hard rule, and it is rarely enforced on its own.
  • My Numbers. The rule is stricter. The My Number Act allows businesses to keep someone's number only while it is needed for the specific tasks the law permits, such as payroll tax and social insurance. The Personal Information Protection Commission's guideline for businesses says that once a number is no longer needed for those tasks and the legal retention period has passed, it must, in principle, be deleted as soon as possible, and recommends building systems on the assumption that it will be. ApplyNow does not say whether former clients' data included My Numbers.
  • Contractors. When a business hands personal data to a contractor, it must supervise the contractor (Article 25). In our view, that supervision should include what happens to the data when the contract ends.

Our view#

Deletion needs a trigger and an owner. Collecting data is designed into every product: a form, a field, a database. Deleting it is left for someone to remember. The moments that should trigger deletion, a client leaving, a scheme changing, a service closing, a user giving up halfway, belong to sales, marketing or product teams, not to whoever runs the database. Unless each of those endings is written down as a deletion event with a named owner, the data stays, and this year shows where it ends up.

Some data should never have been the key. MUJI did not only fail to delete card numbers when its perks scheme changed. In our view, the deeper mistake came first: it used credit card numbers to identify members for the scheme at all. A card number is a payment credential, not an identifier. Had the scheme linked members by an internal ID or a token from the card issuer, ending it would have left nothing dangerous behind. Choosing identifiers that are safe to keep is the cheapest form of deletion there is.

An unfinished application needs an expiry date. Keeping data on people who abandoned a sign-up looks indefensible at first. There can be a reason: letting someone pick up an application where they left off. But that need lasts days or weeks, not years. Monex's leaked addresses go back to 2019. In our view, incomplete applications should be kept only for a stated resume period, holding only what is needed to resume, and then deleted automatically, with the applicant told how long their half-finished data will be kept.

For a vendor, a customer leaving should end in deletion, by default. ApplyNow's former clients may not have known their applicants' and employees' data was still on its servers. The same is true of any platform that holds data on behalf of its customers. Offboarding should delete the customer's data on a fixed schedule and give the customer a record that it was done. Customers, for their part, should ask for that record at the end of every contract.

Keep analysis tools away from live personal data. ApplyNow's attacker came in through an analysis tool that could read the production databases. Such tools are often set up by data teams outside the usual security reviews, and given broad access because that is easiest. ApplyNow's own fix is the right one: point them at a copy with the personal data removed.

What this means for practitioners#

  • List the endings. For each system, write down the events after which its data is no longer needed: contract end, cancellation, account closure, abandoned sign-up, scheme or service closure, system migration. Give each an owner and a deletion action.
  • Do not use sensitive values as identifiers. Card numbers, My Numbers and similar values should never be the key that links records; use internal IDs or tokens.
  • Give incomplete sign-ups a resume window. Keep only what is needed to continue, say how long it is kept, and delete it when the window closes.
  • Set retention periods and automate them. A period nobody enforces is a policy, not a control. Deletion should run on a schedule and be checked.
  • Delete at offboarding, and prove it. If you hold data for customers, delete it when they leave and tell them. If you use such a vendor, put deletion at contract end, and confirmation of it, in the contract.
  • Treat My Numbers separately. Track the statutory retention period for each document type and delete numbers when it ends. The guideline expects systems designed for that.
  • Check what your analysis tools can see. Business intelligence and analytics tools connected to production databases are attack surface. Patch them, restrict where they can be reached from, and feed them de-identified data.
  • Do not forget copies. Logs, exports, backups and test databases hold the same data. A deletion that misses them has not happened.

Japanese terms at a glance#

Japanese Reading Meaning
保管期間 hokan kikan Retention period
利用終了 riyō shūryō End of use (of a service)
削除 sakujo Deletion
努力義務 doryoku gimu Duty to make efforts (not a strict obligation)
特定個人情報 tokutei kojin jōhō Personal information containing a My Number
委託先の監督 itakusaki no kantoku Supervision of contractors
データ分析ツール dēta bunseki tsūru Data analysis tool
最終報 saishūhō Final report