PHR operators sometimes ask whether ISMS certification also settles their obligations under Japan's Act on the Protection of Personal Information. It does not. The two have different objectives and different tests, and neither substitutes for the other.
They are not unrelated either. The security control measures the Act requires overlap substantially with ISMS controls. The clean way to hold it is: the law decides what must be protected; the ISMS builds the mechanism for protecting it.
PHR adds a third layer: a government-issued basic policy for private-sector PHR operators. This article starts from the nature of the data a PHR operator handles and works out how law, policy, and standard fit together. For PHR as a concept, see What Is a PHR?.
Disclaimer: General information only. Interpretation of the Act is governed by the Personal Information Protection Commission's guidelines and Q&A; seek legal advice for your specific business. Interpretation of the standard is governed by the standard itself and the accreditation and certification bodies.
The Nature of the Data
A PHR lets individuals manage their own health and medical information. From the operator's side the data separates as follows.
| Data type | Examples | Legal position |
|---|---|---|
| Checkup and test results | Specific health checkup results, blood values | May constitute special care-required personal information |
| Clinical and dispensing data | Diagnoses, prescriptions, claims-derived data | May constitute special care-required personal information |
| Vitals and activity | Steps, heart rate, sleep | Ordinary personal data alone; changes character when joined to clinical data |
| Self-entered medication records | Medication notebook apps | Can imply a condition, so needs careful handling |
| Attributes and contact details | Name, date of birth, email | Ordinary personal data |
| Usage logs | App and viewing history | Personal data once linked to an identifier |
The safe design assumption is that the core of a PHR business is special care-required personal information. Two consequences dominate:
- Collection generally requires the individual's consent. Ordinary personal data can be collected once the purpose is notified or published; this category cannot
- Opt-out third-party provision is not permitted. "You may stop it if you object" is not a valid basis; individual consent is needed
These two shape the product itself. The common data-business instinct — collect first, decide uses later — does not transfer.
Where a leak occurs, incidents involving this category fall within the reporting duty to the Commission and notification to the individuals concerned. Some categories apply regardless of the number of records, so build the decision flow before you need it.
Designing Consent
Consent is a legal question and equally a product and logging question. What audits ask is not "do you obtain consent" but "can you reconstruct who consented, when, to which version of the wording, and to what?"
| What to decide | The actual decision | What to record |
|---|---|---|
| Granularity | Blanket consent to the service, or per-partner consent | Identifier of the consented scope |
| Point of capture | Signup / start of data linkage / new feature | Timestamp, with timezone |
| Wording version | Re-consent on revision, or notice only | Version ID of the wording shown |
| Withdrawal route | In-app, or via support | Withdrawal timestamp and subsequent handling |
| Minors and representatives | How guardian consent is obtained | Verification method and record |
| Data after withdrawal | Delete, or cease use only | Execution record of deletion or suspension |
Post-withdrawal handling is where implementations stall. Data in backups, copies in the analytics estate, data already passed to partners — you must decide how far withdrawal reaches and make it technically executable, or you cannot honour a request when it arrives. Treat this in the risk assessment as a data-lifecycle concern.
Put consent records in the asset inventory, protected against tampering and retained long term. Being able to prove consent existed is the business's defensive line.
How the Basic Policy and the ISMS Divide Labour
Japan's Ministry of Internal Affairs and Communications, Ministry of Health, Labour and Welfare, and Ministry of Economy, Trade and Industry jointly issued a basic policy on the handling of checkup and related information by private-sector PHR operators. It sits alongside the Act, not inside it.
So three layers apply.
| Layer | What it settles | What you produce |
|---|---|---|
| Personal information law | Lawfulness of collection, use, provision, disclosure requests; duty of security measures | Privacy policy, consent flow, disclosure-request procedure |
| Basic policy for private PHR operators | Sector-specific expectations for handling checkup data | Handling procedures reflecting the policy, user-facing explanations |
| ISMS (ISO/IEC 27001) | The mechanism for operating and improving security continuously | Risk assessment, SoA, operating records, internal audit records |
These stack; they do not substitute. The law sets obligations, the policy gives sector-specific expectations, the ISMS keeps it running. A certificate is not proof of legal compliance, but it is evidence that security measures are implemented organisationally.
Building only the ISMS and skipping the legal layer leaves holes:
- Purposes of use specified too coarsely to extend later
- Consent granularity misaligned with the feature set, forcing re-consent on every release
- No clear separation of third-party provision, outsourcing, and joint use, so partner contracts cannot be explained
- No procedure for disclosure, correction, and cessation requests
The provision / outsourcing / joint-use distinction matters most in PHR. Hospitals, insurers, health insurance societies, research bodies, advertisers — settle the category for each partner before design, or you will be re-collecting consent later.
If you want to demonstrate privacy management as an ISMS extension, ISO 27701 exists: see ISO 27701 (PIMS) and ISMS vs Privacy Mark. For a consumer-heavy PHR business, the Privacy Mark is worth considering alongside.
Where It Lands in ISMS Documentation
Deciding in advance where each legal decision lives inside the ISMS avoids duplicate maintenance.
| Legal or policy decision | ISMS home |
|---|---|
| Purpose specification, privacy policy | A separate document, but under ISMS document control with revision history |
| Identifying special care-required data | Asset inventory classification — top confidentiality grade |
| Consent capture and withdrawal | "Acquisition" and "disposal" phases of the risk assessment; documented procedure |
| Security measures (organisational, human, physical, technical) | Maps closely to Annex A; link explicitly in the SoA |
| Supervision of suppliers | Supplier management procedure and evaluation records |
| Breach reporting and notification | Incident procedure — state the reporting threshold inside it |
| Disclosure requests | Documented procedure with response records |
The useful point is that the law's four categories of security measures map well onto Annex A's four themes — organisational A.5 (37), people A.6 (8), physical A.7 (14), technological A.8 (34). Add one column to the SoA mapping controls to legal requirements and one document explains both.
See Annex A 2022: 93 Controls Across Four Themes and Writing the Statement of Applicability.
Scope and Data Partners
For a PHR operator, how external linkage is treated is the distinctive scope question.
- Public data linkage such as the national portal: the API specification is not yours to change. Fix the demarcation and concentrate controls on what you do govern — protection of received data, access control, logging
- Data received from hospitals or insurers: the security of the receiving path and identifier management after receipt. Counterparties may ask you to evidence three-ministry alignment
- User-entered content: users can mistakenly enter a third party's information; address it in both terms of use and detection
- Research and secondary use: decide pseudonymisation and anonymisation on the legal side, and keep the processing execution records as ISMS operating records
On scope itself, see Designing ISMS Scope for a Healthcare Company. If you also serve hospitals, three-ministry work runs in parallel (Integrating ISMS Documents with the Three-Ministry Guidelines). For how hospitals evaluate cloud services, see Cloud Security for Medical Institutions.
Conclusion
- Design on the assumption that core PHR data is special care-required personal information: consent to collect, no opt-out provision
- Consent is a logging design problem as much as a legal one — reconstruct who, when, and which version
- Settle post-withdrawal handling across backups, analytics, and partners before a request arrives
- Law, the basic policy for private PHR operators, and the ISMS stack. Certification is not legal compliance but is evidence of organised security measures
- The law's four categories of security measures map well onto Annex A's four themes; a mapping column in the SoA avoids duplicate documents
- Classify each partner as third-party provision, outsourcing, or joint use up front, or face re-consent later
Pottech supports ISMS certification with a focus on healthcare. Where law, sector policy, and standard overlap as they do in PHR, deciding which document explains what is what determines the workload. We supply templates and lead project management and dealings with the certification body.
See ISMS Certification Support or contact us. The overall picture is in What Is an ISMS (ISO/IEC 27001)?.
References and Sources
- Personal Information Protection Commission
- Basic policy on handling of checkup information by private PHR operators | METI
- Information Management System Accreditation Center (ISMS-AC)
- Guidelines for the Safe Management of Medical Information Systems | MHLW
Note: the Act and its guidelines are revised periodically. Whether data is special care-required, whether reporting is triggered, and whether consent is needed all turn on specifics. Confirm against the Commission's publications and with legal counsel.