Japan’s main privacy law is the Act on the Protection of Personal Information (APPI, Act No. 57 of 2003), enforced by the Personal Information Protection Commission. How Japanese privacy law affects apps is straightforward in outline: tell people what you collect and why, ask permission in the situations that require it, keep it secure, and hand it back when they ask.
The reason this reaches so many app teams is scope. APPI applies to any business handling personal information about people in Japan, whoever owns the app and wherever the servers sit. Since the 2020 amendment took effect on 1 April 2022, there is no small-record threshold, so an app with a handful of Japanese users is already covered.
One more law sits alongside it. The amended Telecommunications Business Act added an external data transmission rule in June 2023, and that one catches analytics and ad SDKs firing inside a mobile app. This article is general information, not legal advice.
Table of Contents
- What Japanese Privacy Law Means for Apps
- Which Apps and Data Are Covered?
- What Rights Do App Users Have?
- How Must Apps Disclose Their Data Practices?
- When Does an App Need User Consent?
- How Does Japanese Privacy Law Affect Apps Using Third-Party SDKs?
- What Rules Apply to Special-Care and Children’s Data?
- How Are Data Transfers Outside Japan Regulated?
- What Must an App Do After a Personal Data Breach?
- What Compliance Risks and Penalties Can Apps Face?
- How Can App Teams Build a Practical APPI Checklist?
- Frequently Asked Questions
- Does Japanese privacy law apply to an app that is only available outside Japan?
- Does using Google Analytics or an advertising SDK create extra privacy obligations?
- Can a user request deletion of all personal information from an app?
- What information should a Japanese app include in its privacy policy?
- Does an app need parental consent before collecting data from children?
- What should an app do immediately after discovering a personal data breach?
- What App Teams Should Do First
What Japanese Privacy Law Means for Apps
The APPI sets five ideas that app teams actually work with: specify the purpose before you collect, say the purpose out loud to the person, stay inside that purpose, keep the data safe, and never use it in a way the person would not expect. The rest of the law is detail built on those.
APPI distinguishes what the law requires from what regulators recommend. Publishing a Japanese-language notice of your utilisation purpose, documenting your handling decisions and answering access requests within a set window are the practices the Personal Information Protection Commission has pushed. Treat them as the floor, not the ambition.
Worth separating here: the Smartphone Software Competition Promotion Act is about app store terms, default app placement and payment routing. It is an antitrust law run by the Fair Trade Commission, and developers on forums constantly blend it with APPI. Different law, different problem.
Which Apps and Data Are Covered?

Coverage turns on two questions: are you a business handling personal information, and are any of the people involved in Japan. A US developer with a Tokyo office, an EU company selling into Japan, or a solo maker whose app ranks in the Japanese App Store can each be a personal information handler under the law.
Inside an app, far more data is personal information than teams first assume. An email address or phone number on its own is not enough, but an account ID linked to a name, a device identifier combined with usage logs, an IP address recorded alongside a subscription, or a profile you can infer from purchase history can all qualify.
That last one is the category teams forget. Personally referable information, introduced by the 2020 amendment, covers data that can be traced back to an individual even when it looks like a bare identifier. A cookie-style advertising ID sitting in an app SDK is the classic example.
The data categories that change how strict you must be
- Personal information: identifiable data. Notify the purpose before collecting, keep it inside that purpose, and support access and correction requests.
- Personal data: what you actually hold, including the indirect identifiers an SDK creates for you.
- Special care-required personal information: health, biometrics, religion, political views and similar. Opt-in consent, strict limits on onward sharing, tighter security.
- Personally referable information: identifiers linkable to a person. Needs purpose notification and tight handling even when the payload is thin.
Storing data in Japan is not a requirement. Plenty of apps run on overseas infrastructure, which shifts the question from location to safeguards and disclosure.
What Rights Do App Users Have?

Users can ask to see their records, ask for corrections, ask for use to be suspended, ask for deletion where the law allows it, and withdraw consent they previously gave. An app that cannot answer those requests in-app, or that routes them to a support inbox nobody owns, is the gap most teams find.
Build one visible entry point, accept Japanese-language requests, verify identity before you hand anything over, and set an internal deadline so nothing sits. Roughly two weeks is a common internal target, though the statutory framework looks at whether you are responding without undue delay.
Withdrawal of consent is the right people use least and expect most. If a user turns off a processing permission, your app should stop that activity cleanly rather than quietly continuing under a different flag. Most complaints about Japanese apps come from that mismatch.
How Must Apps Disclose Their Data Practices?
A usable disclosure answers six things: the purpose of use, what data you collect, who you share it with, how long you keep it, what security measures you take, and how overseas transfers are handled. It also says how a person exercises their rights and who to contact.
Four surfaces usually carry that information, and they should agree with each other. The privacy policy holds the full statement. The app store listing carries the platform’s own structured disclosure, such as Apple’s privacy labels or Google Play’s Data Safety section, and you complete those as a matter of course.
Consent screens handle the choices, and just-in-time notices cover the moment it matters, such as the first time a location permission or an analytics prompt appears. Teams that write the policy last, after the SDKs are already firing, end up with a document that does not match the app.
If you target Japanese users, write the notice in Japanese. That expectation comes up repeatedly in developer communities and it is the version that actually reaches the people it protects.
When Does an App Need User Consent?
For ordinary processing, Japan leans on notice and purpose limitation more than on opt-in. Collect for a stated reason, tell people the reason, stay within it, and provide a way to opt out. Teams that import a GDPR-style banner for every event usually build a worse product and collect less meaningful consent.
Opt-in is different in a short list of cases, and those are the ones your app UI has to handle:
- Handling special care-required personal information, such as health records, biometric templates or religious affiliation.
- Providing personal data to a third party where the arrangement does not fit an exception.
- Using data for direct marketing beyond the cases the law allows without consent.
- Transferring data overseas where consent is the chosen route rather than another safeguard.
Consent has to be informed, specific and revocable. A single accept-everything button covering analytics, advertising and model training in one dark-pattern bundle is weak on all three counts.
The external data transmission rule is the one that surprises people
The Telecommunications Business Act rule effective in June 2023 requires providers of telecommunications services to tell users, before they send their data outside, who receives it and what it is used for. Most commentary frames it as a website cookie rule. For app teams it matters because mobile SDKs transmit externally by default, from install onward, before the person has seen anything.
How Does Japanese Privacy Law Affect Apps Using Third-Party SDKs?
The honest answer to how Japanese privacy law affects apps is that the SDK list does most of the damage. An app team controls what it writes; it does not control what an analytics package, an ad network or an attribution SDK does with the data it receives.
Audit the SDK list category by category. Analytics and session recording, advertising and ad tracking, attribution and campaign measurement, crash reporting, social login, payment processing, and location services each carry a different disclosure burden. Get a per-SDK answer to three questions: what data leaves the device, what is the stated purpose, and is the vendor inside or outside Japan.
Hiring a vendor does not transfer your obligations. The APPI still expects the business operator to supervise the processor through a written agreement, security commitments and monitoring. An unsigned SDK contract is a finding waiting to happen.
Watch for dark patterns while you are in there. SDKs that start on app launch, rather than after consent, are the most common finding in app privacy reviews.
What Rules Apply to Special-Care and Children’s Data?
Sensitive categories get a tighter rule set: prior opt-in consent, strict purpose limits, restricted onward provision, and stronger security. Health and wellness apps, period and fertility trackers, mental health check-ins and anything using face or fingerprint templates all sit here, and each has a deletion problem attached to it.
For children, design for the age you actually attract rather than the age in your store listing. Age-appropriate design means collecting less, explaining more plainly and offering a route for a parent or guardian to review and delete what a child submitted. Proposals to put firmer rules on data from under-16s have been part of the reform discussion for years.
Medical-adjacent apps deserve particular care. A step count is not health data in the same sense as a diagnosis record, and the difference matters when you define your handling rules.
How Are Data Transfers Outside Japan Regulated?
Sending Japanese user data to an overseas host, analytics vendor or parent-company backend is allowed, but it is conditioned. You need to know the recipient, be able to tell the user who receives the data and for what, and put in place safeguards or obtain consent.
The safeguards in practice look like contractual limits on further onward transfer, technical controls such as encryption and access restriction, and a published supplementary notice that a reasonable person can understand. The UK and EU both took the route of treating Japan as adequate. The EU-Japan adequacy decision relies on supplementary rules that require Japanese operators to apply Japanese standards when they handle EU data, and it exists because of the APPI’s protections rather than instead of them.
Vendor lists change quietly. A subprocessor swap is still a transfer, so your contract needs a change-notification clause.
What Must an App Do After a Personal Data Breach?
Escalate first, investigate second, communicate third. The instinct to fix quietly is the expensive one. Treat a suspected incident as reportable the moment you know personal data was involved, and bring in qualified legal and security support immediately.
- Contain and stop further loss, without destroying logs you will need.
- Preserve evidence and work out what data was affected, how many people, and which data categories.
- Investigate cause and fix the underlying gap, not just the symptom.
- Assess notification duties. The reporting duty to the Personal Information Protection Commission attaches to situations the law treats as requiring a preliminary report, and special care-required information triggers a stricter standard than ordinary records.
- Notify affected users when required, in plain Japanese, with what happened, what data, and what they should do.
- Report the final outcome and prevention measures, and publish details if the regulator asks.
Timeliness is the part that gets scrutinised. Delay in reporting is treated as its own problem, separate from whatever caused the incident.
What Compliance Risks and Penalties Can Apps Face?
The financial ceiling is not usually what hurts. The operational and contractual consequences arrive first.
| Risk type | What it looks like for an app team |
|---|---|
| Operational | Withdrawal of the PPC’s designation as an authorised body, remediation orders and mandatory improvement plans |
| Contractual | Enterprise customers and Japanese distribution partners demanding APPI evidence they do not currently have |
| Reputational | Public reporting, app store listing removal pressure, user churn in a market that notices quickly |
| Enforcement | Administrative guidance, recommendations, corrective orders and fines under the APPI, plus criminal exposure for serious violations |
Maximum fine levels under the APPI sit at up to 100 million yen for certain corporate violations, and proposed administrative monetary penalties would add a more graduated enforcement track. Reform of the penalty system has been under discussion since the Personal Information Protection Commission’s 2024 interim summary, so check the current figures before you quote them anywhere.
How Can App Teams Build a Practical APPI Checklist?
Run this in order. It takes a couple of sprints and produces an artefact the whole company can point at.
- Build the data inventory. List every category the app and each SDK collects, where it goes, how long it is kept and where it is deleted.
- Compare disclosure against reality. Line up the privacy policy, the store listing and the actual SDK behaviour. Mismatches are the finding, and they are usually dozens.
- Write the notice in Japanese and confirm the utilisation purpose matches what the product team intends.
- Fix consent design. Delay non-essential SDKs until after choice, split the choices, and make every one revocable in settings.
- Paper the vendors. Signed data processing agreements, breach notification clauses, subprocessor change control and a list of who receives data.
- Set retention and deletion defaults per data category rather than one global policy.
- Ship a rights workflow with a public Japanese entry point, identity verification, and a documented internal deadline.
- Document cross-border safeguards and publish the supplementary notice.
- Rehearse the breach plan. Run a tabletop exercise so someone knows who decides to report.
- Keep the evidence. Every decision about purpose, consent and retention in one place you can hand to an auditor or a regulator.
Test the checklist against a build, not a document. Ask an engineer to trigger an SDK event and find where the notice covers it. If they cannot, the notice is wrong.
Frequently Asked Questions
Does Japanese privacy law apply to an app that is only available outside Japan?
APPI applies to a business handling personal information about people in Japan, not to a particular app store region. If Japanese residents install your app, download from your site or register accounts, you are very likely a personal information handler. There is no small-record threshold, so low user numbers do not exempt you.
Does using Google Analytics or an advertising SDK create extra privacy obligations?
Usually yes, indirectly. The SDK makes you a handler of personally referable information and can make the vendor a third party receiving your users’ data. The amended Telecommunications Business Act external data transmission rule adds its own disclosure duty when data leaves your service. Disclose the SDK, state its purpose and delay firing it until after any required consent.
Can a user request deletion of all personal information from an app?
A user can request disclosure, correction, suspension of use and deletion in cases the law allows, plus withdrawal of consent. The deletion right is not absolute where retention is legally required, such as transaction records. An app still needs a working request channel, identity verification and an internal deadline for answering.
What information should a Japanese app include in its privacy policy?
Cover the purpose of use, the data categories collected, recipients, retention periods, security measures, overseas transfers, the rights process and a named contact. For users in Japan, write it in Japanese. Keep the app store listing consistent with it, since reviewers and users compare the two.
Does an app need parental consent before collecting data from children?
Consent for special care-required personal information is required regardless of age. For children generally, the expectation is age-appropriate design, minimised collection and a route for a parent or guardian to review and delete what was submitted. Firmer rules for under-16s have been proposed rather than enacted, so design to the age you actually serve.
What should an app do immediately after discovering a personal data breach?
Contain the incident, preserve logs and evidence, and escalate to qualified legal and security professionals straight away. Then work out what data was affected and how many people, assess whether the reporting duty to the Personal Information Protection Commission is triggered, notify users where required, and document the fix. Delay in reporting counts as a separate problem.
What App Teams Should Do First
Start by identifying the personal data your app actually processes, including everything an SDK collects on your behalf. Then map how each app and SDK uses it and where it goes.
Next, compare what you disclose against what the build really does. That comparison is usually where the work is.
After that, get Japanese legal review for any high-risk activity you cannot resolve internally: special care-required data, children, cross-border transfers or a breach. Bring a Japanese-qualified adviser in early, not after a regulator writes to you.
How Japanese privacy law affects apps is decided mostly by choices made long before anyone files a complaint: which SDKs you added, which notice you published, and whether a user could take control of their data when they asked.