Generative AI at Japanese Banks: What the Public Documents Say About Where Data Sits

Hello, this is Ryuta Hamamoto from TIMEWELL.

IT planners at Japanese banks have put the same question to me so many times that I recognise the shape of it before the sentence finishes. "FISC applies to us, so anything we feed into generative AI has to stay inside Japan, doesn't it?"

Lately I hear the mirror image of that question from the other side of the table. A fintech or SaaS company based outside Japan is three meetings into a deal with a Japanese financial institution, someone says the word FISC, and the deal quietly acquires a requirement that nobody in the room can trace to a source.

Answering either version accurately means running into a wall almost at once. The document at the centre of the conversation, the FISC Security Guidelines on Computer Systems for Financial Institutions (金融機関等コンピュータシステムの安全対策基準・解説書), is a paid publication. The 14th and current edition sells to non-members for 3,000 yen¹. You can buy it. You can read it. What you cannot do is copy what you read into a public article like this one. Which means that any piece explaining these rules by quoting the text has handed its readers something they have no way of checking.

Meanwhile the phrase "FISC-compliant" travels freely. It shows up in proposals, in RFP responses, in the security section of a vendor's website. I have sat in plenty of rooms where it was said and nobody flinched. Whether everyone in those rooms had the original open in front of them is a separate question, and I suspect the honest answer is usually no.

So here is the exercise. Lay out only the documents anyone can read for free, and see what they actually ask about where data sits when a financial institution runs generative AI in the cloud. One disclosure before I start: nothing below quotes a single line of the 14th edition. Where a question can only be settled by reading the paid text, I say so instead of filling the gap. If you want a quick read on where your own organisation stands before going further, we run a free AI readiness check.

What "FISC-compliant" cannot tell you from outside

The first edition of the Security Guidelines appeared in December 1985. Revisions since then have been deliberated by academics, financial institutions and computer manufacturers, joined by committee members bringing specialist knowledge from cloud providers and FinTech companies². The 14th edition was published on 25 March 2026, and FISC lists four areas of revision: AI security measures, cybersecurity, post-quantum cryptography, and the reflection of system failure cases and various guidelines². On post-quantum cryptography, the announcement states specifically that it reflects a study group report for deposit-taking financial institutions that the Financial Services Agency published in November 2024.

All of that is on FISC's website and free to read. What is not free is the content. The 14th edition PDF goes to members at no charge, while everyone else buys it as a publication for 3,000 yen¹.

That fact carries more weight in a compliance discussion than it first appears. If your only audience is your auditor or the regulator, having a copy on the shelf is enough. The moment you sit down with a counterparty or an external vendor and try to work out which clause a given requirement came from, the conversation stalls unless both sides have bought it. In practice one side usually has and the other has not, and the requirement survives on assertion rather than on text.

There is a second property worth getting right. In material FISC itself submitted to the Financial System Council's Study Group on Sophistication of Payment Services (決済業務等の高度化に関するスタディ・グループ) on 8 December 2014, it wrote this: "Because it is a 'voluntary standard', it has no binding force. Nor is there anything like a 'conformity assessment and certification scheme' run by a third party or by FISC."³ The same document adds that the scope of application, the systems covered and the specific measures are expected to be judged voluntarily by each financial institution in light of its own business, referring to the guidelines while implementing appropriate security measures.

The supervisory side points the same way. The FSA's Comprehensive Guidelines for Supervision of Major Banks, etc. (主要行等向けの総合的な監督指針), in its August 2026 version, goes no further than citing the Security Guidelines as an example of reference material on system risk⁴. In the passage on contingency planning it cites a FISC handbook as an example of something by which an objective level can be judged. FISC documents are referenced in eight places across the supervisory guidelines, and in every one of them the reference is illustrative rather than mandatory.

Which is why I do not treat the phrase "FISC-compliant" as evidence of anything. With no certification scheme in existence, the party deciding whether compliance can be claimed is the party making the claim. TIMEWELL holds ISO/IEC 27001 certification, and we have never described ourselves as FISC-compliant. Keeping straight what you can and cannot say about yourself strikes me as the bare minimum for anyone selling to banks.

For a vendor based outside Japan, this has a practical upside worth noticing. If a prospect's requirements document says "must be FISC-compliant" and nothing more, that is not a wall. It is an unfinished sentence. The useful reply is to ask which specific control the requirement is meant to achieve, because somebody on the customer's side has to answer that question eventually anyway.

The public documents ask you to know where the data is, not to keep it here

So is there anything public on the question of location? There is. FISC published the Expert Study Group Report on Cloud Use by Financial Institutions (金融機関におけるクラウド利用に関する有識者検討会報告書) in November 2014, it is free, and it takes the question head on⁵.

Start with the framing. The report concluded that use of public cloud is best treated as a form of external outsourcing, on the reasoning that this matches how financial supervisory authorities in other countries handle it. On that footing it states that because financial institutions bear ultimate responsibility towards their customers and towards the settlement system, that responsibility cannot be escaped. The report is explicit that its subject is resource-sharing public cloud, so you cannot simply extend its conclusions to private or community cloud in general.

Pages 14 and 15 contain a section of their own headed "② Data location". It reads: "Depending on the cloud provider, there are cases where operations and data are managed across multiple data centres located around the world. ... Sufficient care must be taken over which country's law applies in the event of a dispute, and over whether business continuity would be affected if data were seized for investigative purposes by local public authorities." It then adds: "In particular, where important operations are entrusted, understanding the location of data becomes more important."

Knowing, not confining

The requirement itself is worded like this: "It is necessary to understand the location region, meaning the country, state and so on, to the extent that the laws applicable to that cloud service can be identified." Where data is stored in distributed form, the report continues, it is necessary to understand which countries or regions it may be stored in.

Read that carefully. What is being asked for is that you know where the data is, not that you keep it in Japan. Blur the distinction and write "domestic only" into your internal rules, and you have taken on a constraint that the rulebook never imposed on you. Then you spend the following year explaining to your own business units why a tool everyone else uses is off limits, and the reason turns out to be a rule you wrote yourself.

There is a stricter tier. For mission-critical systems such as core banking, where extremely high availability and reliability are required, the report says it is necessary to understand the detailed location in order to assess matters such as the siting of the data centre. That passage sits in footnote 14 on page 15 rather than in the body. When you quote it, saying that it is a footnote is the honest thing to do.

There is also a passage running the other way: "From the perspective of the risk profile, where operations that are not positioned as important are entrusted, information on data location is considered to be not particularly important." Rather than one location rule applied uniformly, the report grades both the need to know and the level of detail according to how important the work is. When you sit down to inventory your generative AI use cases, that single sentence does a lot of work.

Storing data overseas is not prohibited either. The report raises two things to watch. On-site audits of data centres take time and cost a great deal in staff effort, so delegating to a local audit firm is likely to become the common response. And on communication during incidents: "Where the language ability of the financial institution's incident response staff on the ground is not sufficient, it is necessary to make clear in the contract that Japanese-language support and an incident response point of contact at the cloud provider's Japanese subsidiary or similar entity will be provided." The treatment is not prohibition. It is a gap to be closed with contract terms and operating arrangements.

One more piece of history from the same report. Cloud standard 【Un-108】 in the supplement to the 8th edition listed, as risks to assess where the governing law and courts for a dispute with the provider lie in another country, the need to understand and analyse local law and the local judicial system, to secure lawyers qualified to practise there, to bear the burden of remote meetings and court appearances, and to handle all of that in a foreign language⁵. That said, the item number 【Un-108】 was folded into other items in the 9th edition and no longer exists. It should be read as something that was once in the text, not as a current requirement.

For an overseas vendor, this is the section worth printing out. Almost every objection a Japanese financial institution will raise about your architecture is anticipated here, and almost all of it is answerable with documentation and contract language rather than with a data centre in Tokyo.

What the revision history gives away

The body of the guidelines is paid, but the summaries of each revision are free. More can be read out of them than I expected.

The major turning point was the 9th edition. The revision outline submitted to the FSA's Public-Private Council for Promotion of Payment Sophistication (決済高度化官民推進会議) on 20 December 2017 states that the structure of the guidelines was changed to Control Standards, Practice Standards, Facility Standards and Audit Standards, and sets out the introduction of a risk-based approach in these terms: "Under IT governance, conduct risk assessment on financial information systems and apply security standards in line with their risk characteristics."⁶ The same document records that the outsourcing standards (Un-87 to 90), the cloud standards (Un-108 to 111) and the audit-related standards were consolidated and reorganised, and that a cloud-specific standard 【To-24】 was newly created, covering matters such as understanding cloud locations and stating audit rights explicitly. The four-part structure can also be confirmed from the table of contents shown on the publication page for the 9th edition⁷.

That is a 2017 snapshot. The table of contents for the 14th edition is not published, so whether the number 【To-24】 or its content survives today cannot be established from outside. Write "the FISC standards require you to understand cloud locations" without attaching an edition and a date, and you have produced a present-tense claim with nothing behind it.

Cloud had another document too. On 28 May 2021 FISC published the Explanatory Handbook on Cloud Introduction and Operation at Financial Institutions, trial edition (金融機関等におけるクラウド導入・運用に関する解説書（試行版）). Its status was stated plainly: "This handbook supplements the explanation of the standard items in light of the characteristics specific to cloud, without changing the Security Guidelines, and is positioned as a trial edition."⁸ It was offered at 900 yen for non-members, and its content was absorbed into the 11th edition published on 17 May 2023⁹.

The introductory material for that handbook contains something usable in practice. Working from the shared responsibility model, it says institutions need to distinguish two kinds of security measure and handle them separately: measures they implement using functions and information they prepare themselves, and measures that use functions and information provided by the cloud provider¹⁰. Because the dividing line moves with the responsibility demarcation point, the material adds, checking what functions and information the provider supplies becomes an important perspective. Generative AI has the same shape, with a model provider, a platform provider and the controls you implement yourself. Skip the line-drawing and you get gaps and duplicated effort at the same time.

Then AI. Standard sub-items addressing AI were newly created in the 13th edition, published on 21 March 2025¹¹. The same edition also reflected the specified social infrastructure services regime under the Economic Security Promotion Act, the FSA's cybersecurity guidelines, and operational resilience. That AI security measures were revised again in the following year's 14th edition is what I noted at the top. The fact that AI is now inside the standard can be confirmed for free. What was written about it stays behind the paywall, and that is still where things stand.

Two documents on generative AI you can read for nothing

The first is FISC's Considerations from a Security Measures Perspective on the Use of AI in Financial Institutions' Operations (金融機関によるAIの業務への利活用に関する安全対策の観点からの考察), published on 24 September 2024¹². The PDF downloads without membership registration.

The passage bearing on location is in a table setting out the challenges of using generative AI: "In the case of generative AI services provided by vendors, a sufficient understanding is required of the various specifications, such as the 30-day monitoring retention mechanism and the region in which the cloud environment is established, whether overseas or domestic." That is not an instruction to use a domestic region. It is a question about whether you understand the specifications of the service you are running, and the region is one of the specifications to be understood.

The same document goes further on handling information. Where it is difficult to meet security requirements, for reasons such as settings not being individually configurable, it says that handling highly confidential information in generative AI is not appropriate, from the standpoint of preventing unintended information leakage. The conditional clause comes first, which matters. This is not an unconditional ban on confidential information. Alongside it, the document states that so-called shadow IT, meaning staff using generative AI services for work without the organisation's permission, is not appropriate, because control and oversight of who is using what and how may break down. At the end, the document gives notice that a revision adding AI-related standard items to the Security Guidelines would be carried out within that fiscal year. That is what the 13th edition delivered.

The second is the FSA's AI Discussion Paper, version 1.1 (AIディスカッションペーパー（第1.1版）), published on 3 March 2026, with version 1.0 having appeared in March 2025¹³. Its subtitle is "An Initial Organisation of Issues Toward Promoting the Sound Use of AI in the Financial Sector". The paper publicly confirms the sequence I described above, that FISC published its considerations in September 2024 and that a revision adding AI standard items followed in March 2025. As a source, that makes it valuable in its own right, because it lets you evidence the addition of AI items without buying the standard.

On location, the clearest statement available anywhere at the moment is this one from the same paper: "The so-called cross-border transfer regulation (Article 28(1) of the Act on the Protection of Personal Information) applies where the recipient is a 'third party in a foreign country', and is therefore to be considered on the basis of the location of the AI provider rather than the location of the server. However, in the so-called standard-conforming system (Article 16 and others of the Enforcement Rules of the Act) and in understanding the external environment as a security control measure, the location of the server does need to be taken into account."¹³

So "the server is in Japan, therefore no cross-border transfer" and "the server is abroad, therefore cross-border transfer" are both too coarse. Reading it against the Personal Information Protection Commission's Q&A sharpens the outline. Where personal data is stored in a cloud provided by a third party in a foreign country, you have to make clear the name of the foreign country in which the provider is located and the name of the foreign country in which the storing server is located, understand the systems of that country, and place the content of the measures you have taken in a state where the individual concerned can know them¹⁴. Where the country cannot be identified, you have to state that it cannot be identified, give the reason, and provide information that serves as a reference for the individual. Running the other way, storing personal data on a server that you install abroad yourself and manage and operate yourself does not fall under Article 28(1), and neither does the case where the foreign provider is not to handle the stored personal data. The second of those is limited to situations where contractual provisions stipulate that it will not be handled and appropriate access control is in place¹⁵.

I would add one caution that sits underneath all of this. Specifying a domestic region does not necessarily mean the processing itself completes in Japan. I went through the providers' own documentation on that in running LLMs in a Japanese region. Answering the requirement to understand where data is takes more than a line in a contract. It takes a look at the actual processing path.

Zero search hits does not mean the text is silent

Now a word about method, because I nearly got this one wrong myself.

Run a full-text search across the FSA's Guidelines for Cybersecurity in the Financial Sector (金融分野におけるサイバーセキュリティに関するガイドライン) for 所在地 (address or location), 越境 (cross-border), 国外 (outside the country) and 準拠法 (governing law), and every one of them returns zero hits¹⁶. Looking at that result, I was one step away from concluding that the guidelines say nothing about where data sits.

Wrong. Read section 2.6 on third-party risk management from start to finish and there are two provisions on exactly that. Among the items to be recorded in the third-party register is "the type, confidentiality and location of the organisation's own data held or processed by the third party". Among the items to be stated explicitly in contracts and SLAs is "arrangements concerning the location, storage, retention, transfer and disposal of data". The vocabulary the original uses is 場所 (place) and データの所在 (where data resides), and not the 所在地 I had searched for. That was the whole of my error.

Regulatory text is not written in the words a reader happens to think of. A keyword search returning nothing proves nothing about whether the point is covered. That sounds obvious written down, and it is precisely the principle that gets skipped now that summarising a document with AI takes fifteen seconds. For what it is worth, third parties come up more than sixty times across the same guidelines, so managing outsourced providers is unmistakably a focus area. The conclusion I take from it is that there is no provision mandating domestic storage, and there is a clear expectation that you know where the data is and write it into the contract.

There is one more passage where quoting needs care. The supervisory guidelines contain a list of evaluation items: understanding of the locations where important data is processed and stored, reflection of audit rights and monitoring rights in the contract, confirmation and evaluation of assurance reports and third-party certifications, understanding of cloud-specific risks, and security risk assessment including authentication functions⁴. It gets quoted often. It sits inside Chapter IX on Electronic Payment Handling Business, under the main points of attention on system risk, in the part dealing with the use of external services such as cloud. It appears exactly once in the entire document, and the chapter on system risk for banks themselves carries no equivalent text. So you cannot read it as an obligation on banks in general to understand locations.

The items themselves, though, are a genuinely useful lens for evaluating an external service, whatever the business type. Get precise about what the regulator requires and where, and then adopt the good items voluntarily because they are good. Those are two different acts, and mixing them up is how internal rules get written that nobody can defend.

What to settle before you design the deployment

Here is what I check first on a financial institution project, in the order I check it.

Start with an inventory of use cases. How far you need to go in understanding location varies with how important the work is, which is how the public documents set it up. Searching and summarising internal documents is one thing. Drafting customer correspondence is another. Anything touching judgements near the core banking system is a third. Skip that sorting and write one rule for the whole organisation, and it usually lands in one of two states: too strict, so nobody uses it, or too loose, so nobody can defend it.

Next, look at whether you are procuring in a way that lets you explain location. Can the provider tell you which countries or regions it processes in? If storage is distributed, can it tell you which countries the data may end up in? This is not a rule that you must never use a service that cannot answer. It is a rule that if the answer is unavailable, you need to be able to explain, as an institution, that it is unavailable and why. Where personal data is involved, carry the design all the way through to what you will publish in the state where the individual concerned can know it.

The contract items are, in effect, already listed across the public documents. Arrangements on the location, storage, retention, transfer and disposal of data. Audit rights and monitoring rights. Japanese-language support and an incident response point of contact at a Japanese subsidiary or similar entity. With those in the contract, a configuration that places data outside Japan can still be explained coherently to a regulator or an auditor. The configuration that worries me is the opposite one, where all of that is left blank and the only thing on offer is "it is a domestic region, so it is safe".

Then split the measures along the shared responsibility model, separating what you implement with your own functions from what you implement by using the provider's. With generative AI, the items people most often assign to the wrong side are the retention period for input data, the scope of logging, and whether inputs are used to train models. Putting that into a table and getting the stakeholders to agree on it cuts a surprising amount of rework out of the audit later.

Last, shadow IT. FISC's considerations went out of their way to name it, and the reason is that once you lose track of who is using what and how, the assumptions underneath every other control go with it.

On building a platform that lets generative AI work with internal documents and institutional knowledge, ZEROCK is designed on the premise of domestic operation. How much of the location awareness, the access control and the record-keeping you hold on your own side is a question worth settling before you get to product selection, not after.

Back to the wall I started with. Should you buy the paid standard? If you carry responsibility for a financial institution's systems, yes. Three thousand yen for the full shape of the voluntary standard is not a close call on cost.

But a second job survives the purchase. When you explain a requirement to a counterparty or a vendor, when you share the basis for an internal rule with colleagues, when you set out your reasoning to the regulator, your language holds up better if you have built it out of the public documents. Otherwise the discussion collapses into competing recollections of a text nobody in the room can open.

Every document I have cited here is free. The 2014 study group report, the 2017 revision outline, the 2024 considerations on AI, the 2026 discussion paper, and the privacy regulator's Q&A. Read those five, then inventory your own use cases, and what you end up with will be considerably more accurate and considerably more usable than the sentence "FISC means it has to stay in Japan".

If you get stuck partway through working out which document bites on your particular use case, or how to explain the setup you already have, get in touch.

Footnotes

1. The Center for Financial Industry Information Systems (FISC), publication page for "Security Guidelines on Computer Systems for Financial Institutions, 14th edition" (金融機関等コンピュータシステムの安全対策基準・解説書（第14版）). Publication date March 2026; the listed price for non-members is 3,000 yen including tax; provided free to members; separate pricing for educational institutions. All from that page. https://www.fisc.or.jp/publication/book/007219.php ↩ ↩²

2. FISC topics, "Publication of the Security Guidelines on Computer Systems for Financial Institutions (14th edition)", 25 March 2026. The first edition dating from December 1985, deliberation by specialist committee members including academics, financial institutions, computer manufacturers, cloud providers and FinTech companies, and the four areas of revision in the 14th edition (AI security measures, cybersecurity, post-quantum cryptography, system failure cases and various guidelines) are all from that page. Quotations here are the author's translation from the Japanese original. https://www.fisc.or.jp/topics/007222.php ↩ ↩²

3. FISC, "About the Security Guidelines on Computer Systems for Financial Institutions", Financial System Council, Study Group on Sophistication of Payment Services (決済業務等の高度化に関するスタディ・グループ), 7th meeting, document 3, 8 December 2014. The statements that it is a voluntary standard with no binding force, that no conformity assessment and certification scheme exists whether run by a third party or by FISC, and that scope, systems covered and specific measures are for each financial institution to judge voluntarily, are from that document. Author's translation. https://www.fsa.go.jp/singi/singi_kinyu/kessai_sg/siryou/20141208/03.pdf ↩

4. Financial Services Agency, "Comprehensive Guidelines for Supervision of Major Banks, etc. (main volume)", August 2026. The citation of the FISC Security Guidelines as an example of reference material on system risk, the citation of the FISC handbook on contingency planning as an example of something by which an objective level can be judged, and the placement of the evaluation items including "understanding of the locations where important data is processed and stored" in Chapter IX on Electronic Payment Handling Business at IX-3-1(2)② (pages 469 to 470 of the main volume) are all from that document. Author's translation. https://www.fsa.go.jp/common/law/city.pdf ↩ ↩²

5. FISC, "Expert Study Group Report on Cloud Use by Financial Institutions", November 2014. The treatment of public cloud as a form of external outsourcing, the section "② Data location" (pages 14 to 15), the requirement to understand the location region (country, state and so on), footnote 14 on page 15 concerning mission-critical systems such as core banking, the simplified risk management according to risk profile, the points to watch when storing data overseas (Figure 9), and the full text of 【Un-108】 from the supplement to the 8th edition reproduced in the appendix, are all from that report. Author's translation. https://www.fisc.or.jp/document/fintech/file/190_0.pdf ↩ ↩²

6. FISC, "Outline of the Revision of the Security Guidelines (9th edition)", 20 December 2017, Financial Services Agency, Public-Private Council for Promotion of Payment Sophistication, document 4. The change of structure into four categories, the introduction of a risk-based approach, the consolidation and reorganisation of the outsourcing, cloud and audit standards, and the creation of the cloud-specific standard 【To-24】 are from that document. Author's translation. https://www.fsa.go.jp/singi/kessai_kanmin/siryou/20171220/04.pdf ↩

7. FISC, publication page for "Security Guidelines on Computer Systems for Financial Institutions, 9th edition, December 2021 version" (sales now ended). The table of contents structure of V. Control Standards, VI. Practice Standards, VII. Facility Standards and VIII. Audit Standards is from that page. The table of contents for the 14th edition is not published. https://www.fisc.or.jp/publication/book/005075.php ↩

8. FISC topics, "Publication of the Explanatory Handbook on Cloud Introduction and Operation at Financial Institutions (trial edition)", 28 May 2021. The positioning as a trial edition that supplements the explanation of standard items without changing the Security Guidelines is from that page. Author's translation. https://www.fisc.or.jp/topics/004844.php ↩

9. FISC, publication page for "Explanatory Handbook on Cloud Introduction and Operation at Financial Institutions (trial edition)". Publication date May 2021, non-member price 900 yen including tax, and the absorption of its content into the Security Guidelines 11th edition published on 17 May 2023, are from that page. https://www.fisc.or.jp/publication/book/004842.php ↩

10. FISC, "Introduction to the Explanatory Handbook on Cloud Introduction and Operation at Financial Institutions (trial edition)" (© 2021 FISC). The statement that, working from the shared responsibility model, financial institutions need to distinguish between security measures implemented using functions and information they prepare themselves and those using functions and information provided by the cloud provider, is from that material. Author's translation. https://www.fisc.or.jp/topics/file/cloudsyoukai.pdf ↩

11. FISC topics, "Publication of the Security Guidelines on Computer Systems for Financial Institutions (13th edition)", 21 March 2025. The creation of standard sub-items addressing AI, and the reflection of the specified social infrastructure services regime under the Economic Security Promotion Act, operational resilience, and the FSA cybersecurity guidelines, are from that page. https://www.fisc.or.jp/topics/006665.php ↩

12. FISC, "Considerations from a Security Measures Perspective on the Use of AI in Financial Institutions' Operations", 24 September 2024. The passage on understanding the specifications of vendor-provided generative AI services (the 30-day monitoring retention mechanism and the region in which the cloud environment is established), the treatment of highly confidential information where security requirements are difficult to meet, the passage on shadow IT, and the notice of a forthcoming revision adding AI-related standard items, are all from that document. Author's translation. https://www.fisc.or.jp/document/public/file/ai_opinion_20240924.pdf ↩

13. Financial Services Agency, "AI Discussion Paper (version 1.1): An Initial Organisation of Issues Toward Promoting the Sound Use of AI in the Financial Sector", March 2026. The statement that the cross-border transfer regulation is considered on the basis of the AI provider's location, that the server's location needs to be taken into account for the standard-conforming system and for understanding the external environment, and the description of FISC's September 2024 considerations and the March 2025 revision of the standards, are from that paper. The publication date of 3 March 2026 and the fact that version 1.0 dates from March 2025 are from the announcement page. Author's translation. https://www.fsa.go.jp/news/r7/sonota/20260303/aidp_version1.1.pdf and https://www.fsa.go.jp/news/r7/sonota/20260303/aidp.html ↩ ↩²

14. Personal Information Protection Commission, "Q&A on the Guidelines for the Act on the Protection of Personal Information", Q10-25. The requirement, where personal data is stored in a cloud provided by a third party in a foreign country, to make clear the name of the foreign country in which the provider is located and the name of the foreign country in which the storing server is located, to understand the systems of that country, and to place the measures taken in a state where the individual can know them, together with the treatment where the country cannot be identified, is from that Q&A. https://www.ppc.go.jp/all_faq_index/faq1-q10-25/ ↩

15. Personal Information Protection Commission, same Q&A, Q12-3. That storage on a server the business operator itself installs, manages and operates abroad does not fall under Article 28(1) of the Act, and that the case where the foreign provider is not to handle the stored personal data also does not fall under it (limited to cases where contractual provisions stipulate that it will not be handled and appropriate access control is in place), is from that Q&A. https://www.ppc.go.jp/all_faq_index/faq1-q12-3/ ↩

16. Financial Services Agency, "Guidelines for Cybersecurity in the Financial Sector" (4 October 2024, partially amended 4 July 2025). The third-party register item "the type, confidentiality and location of the organisation's own data held or processed by the third party" and the contract and SLA item "arrangements concerning the location, storage, retention, transfer and disposal of data", both in section 2.6 on third-party risk management, are from that guideline. Author's translation. https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf ↩