TL;DR
Getting Privacy Mark (P-Mark) isn't primarily a documentation project—it's an operations project.
The biggest mistake companies make is assuming they can write policies, run training, and apply immediately. In reality, JIS Q 15001 evaluates a personal information protection management system (PMS) that has already been operating, meaning you need evidence of a complete PDCA cycle: plans, execution, audits, corrective actions, and management review.
Success depends on maintaining a handful of core operational records, especially your personal information inventory, risk assessments, legal register, and vendor management (not just a template pack).
The timeline is driven by how long it takes to generate credible operational evidence, not how quickly you can write documents. If you're also implementing ISO 27001, you should build one integrated management system rather than two separate compliance programs.
Anyway,
Most companies hear about the Privacy Mark the same way. A Japanese enterprise customer sends a vendor assessment, or a 委託契約 comes back with a clause about it, and someone forwards the email asking how long this is going to take.
The expected answer is: write some policies, run a training session, do an internal audit, apply.
That isn't wrong. It's just missing the part that actually determines your timeline.
The Privacy Mark assesses a system that has already been running
P-Mark is granted against JIS Q 15001, which describes a personal information protection management system — a PMS. The important word is system. Not a document set. A system is something that operates, and the review is built around the assumption that yours has been operating before you applied.
In practice that means you are expected to have completed a full PDCA cycle before you submit an application. Not planned one. Completed one, with records.
The review then has three parts that reinforce each other: a check that your application is complete, a document review against the standard, and an on-site review where examiners talk to your representative and your staff and look at what people actually do. Documents that describe a company you aren't will not survive the third part.
So the binding constraint on your timeline is elapsed operating time, not writing speed. This is the single most common thing companies get wrong when they promise a customer a date.
Plans are evidence, not preparation
This is the part that surprises nearly everyone, and it's the reason you can't compress the schedule at the end.
For employee education, expect to show:
- the education plan, written before the education happened
- the record that it was delivered, including who attended
- the material you used
- evidence that people actually understood it — a short test or questionnaire, with results
For internal audit:
- the internal audit plan
- the checklist the auditor worked from
- the record of the audit itself
- the report of findings to your representative
For findings, corrective action records showing each nonconformity was closed. For management review, what was put in front of leadership, a record that the review happened, and what leadership decided as a result.
Notice the pattern. For every required activity there is a document saying you intended to do it and a document saying you did it. The format is yours — an internal format is fine, nobody is requiring a specific template, but both halves have to exist, and the dates have to tell a coherent story. A training plan authored the same day as the training record, three weeks before you applied, tells a story too. Just not the one you want.
You cannot retroactively plan something you have already done. This is the mechanism that makes the Privacy Mark a real operating requirement rather than a documentation exercise, and it's why the honest answer to "how fast can we get this?" starts with a calendar, not a document list.
The registers everything else hangs off
Four things carry most of the weight. If these are wrong, nothing built on top of them works.
1. The personal information inventory (個人情報管理台帳)
Every category of personal information the company handles: what it is, why you hold it, where it lives, who can reach it, how long you keep it, and how it's destroyed. This is the most load-bearing document in the entire system. Your risk analysis is derived from it. Your access controls are justified by it. Your retention rules point at it. If the inventory is a guess, everything downstream is a guess.
It is also the item most likely to be out of date a year later, because it changes every time engineering ships a feature that touches user data. Whoever owns it needs a way of finding out about those changes that doesn't depend on someone remembering to send an email.
2. Risk analysis tied to that inventory
Per item, across the lifecycle — acquisition, use, storage, transfer, deletion — what could go wrong, what you do about it, and what residual risk you're accepting. Reviewed on a defined interval, not once.
3. A way of tracking applicable laws
You need to know which laws and guidelines apply to how you handle personal information, and you need a defined way of noticing when they change. The Act on the Protection of Personal Information and the PPC guidelines are not static; anyone who worked through the 2022 amendments remembers that. What this looks like in practice is unglamorous: a maintained list, a named owner, and a review cadence that someone actually keeps.
4. Vendor and 委託先 management.
Anyone you entrust personal information to — cloud infrastructure, payroll, recruiting, offshore development, support tooling needs; selection criteria, an evaluation before you engage them, a contract with the right protections, and a re-evaluation on a schedule. With records for each step.
For a SaaS company this list is longer than people expect. Every subprocessor is in scope, including the ones procurement never saw because someone put them on a credit card.
Alongside those, the operational ones: a complaints and inquiries process with a record of each case, an incident procedure with defined reporting lines and timing, and the ability to actually handle a disclosure request when one arrives.
One big document, or many small ones?
There are two failure modes here and most companies pick one of them.
The monolith is a single PMS manual containing everything. Nobody reads it, every small change becomes a version-control event affecting the whole document, and when an examiner asks where the retention rule lives, someone scrolls for two minutes.
The other failure is forty documents out of a purchased template pack, most of which describe a company with departments you don't have and processes you never adopted.
What tends to work for a company under a hundred people is a short top-level manual describing the system and who is responsible for what, a small number of 規程 covering the areas that genuinely have rules; handling, access, entrustment, incident, education, internal audit — and the 様式 kept as separate short files so a form can change without reissuing a policy.
Size the document set to the company, not to the standard. The test I'd apply: could a new employee find the rule governing what they're about to do in under a minute? If not, the documentation is decoration, and the on-site review will find that out.
The public-facing part
You effectively end up with two privacy policies: the internal one that governs how staff handle personal information, and the 個人情報保護方針 you publish. The published one has expected content, including a contact point for complaints and inquiries, and alongside it you need to make available the items the APPI requires; purpose of use, the procedure for disclosure requests, and so on.
If your company operates in English, this is worth saying plainly: the Japanese version needs to be the authoritative one and it needs to be written, not machine-translated at the end of the project. It's a public document that a Japanese customer's legal team may read before they read anything else you've produced.
What this means for your timeline
If a customer has asked you for a Privacy Mark, the useful answer isn't "we'll start next month." The sequence is: build and document the system, operate it long enough to generate a real cycle of records, run the internal audit, hold the management review, apply, then work through the document review, the on-site review, and any corrective actions that come out of them.
The writing is the small part. The operating period is the part you can't buy your way out of, and the plan-and-result structure above is what makes that true.
None of this is exotic. It's ordinary management system logic applied to personal information, and if you're also pursuing ISO 27001, the two can be designed as a single system instead of two parallel ones that duplicate each other's paperwork. That's worth its own post.
If you're at the "a customer just asked us about this" stage and want a straight answer on scope and timeline, or you need the independent internal audit the standard requires, get in touch.