Japan's Financial Services Agency (FSA) now supervises cyber security against a single written guideline, and examiners expect financial institutions to show how each section is met in practice, not on paper. The Guidelines on Cybersecurity for the Financial Sector were issued on 4 October 2024 and, according to the FSA's provisional English translation, revised on 4 July 2025. This guide explains who is in scope, how the two tiers of measures work, what the guideline expects on governance, access control, testing, logging, third parties and recovery, and how the FSA's 2026 request on frontier AI threats adds to it. It is written for CISOs, risk and compliance teams, internal auditors and IT leaders at Japanese banks, insurers, securities firms, payment and crypto-asset businesses, and at overseas groups with Japanese licensed entities. Personal data duties sit under a different law: see the Japan APPI Guide.
The FSA states that the English text is a provisional translation for reference only and that the Japanese original prevails. Section numbers below follow the English translation fetched in November 2026.
Key takeaways
- One guideline, wide scope. Section 1.4 applies it to every type of institution covered by the FSA's comprehensive supervision guidelines, from major and regional banks to insurers, securities firms, crypto-asset exchanges, funds transfer providers and financial market infrastructures.
- Two tiers of measures. "Fundamental response measures" are the cyber hygiene baseline most institutions are expected to meet; "recommended measures" are advanced practices aimed at institutions with significant impact on the economy, such as major banks and FMIs.
- Risk based, not uniform. Section 1.1 says the guideline does not mandate uniform responses and expects priorities set by importance and urgency, while section 1.2.1 warns against focusing only on formal compliance.
- Privileged accounts are named directly. Section 2.3.1 expects strict control of privileged accounts, with examples such as multi-factor authentication, dual control and time limits, plus automatic expiry of unused IDs.
- Annual cycles anchor the programme. The framework, policies and risk assessment are each reviewed at least once a year, and senior management reports on cyber security at least annually.
Scope and status
The guideline is supervisory guidance rather than a statute. It sits alongside the FSA's comprehensive supervision guidelines for each business type, and section 1.4 lists the institutions covered. Section 1.2.1 adds that group entities, including overseas locations, should operate a consistent framework, which matters for foreign groups running Japanese subsidiaries from a regional hub.
| Sector | Institutions named in section 1.4 (summary) |
|---|---|
| Deposit taking | Major banks, regional and small and medium sized financial institutions, agricultural and fishery cooperative financial institutions, bank agents |
| Insurance | Insurance companies, small amount and short term insurance businesses, insurance agents |
| Securities and markets | Financial instruments business operators, financial instruments exchanges, financial service intermediaries, credit rating agencies |
| Payments and lending | Prepaid payment instrument issuers, funds transfer service providers, electronic payment service providers, electronic money claim recording institutions, money lenders, designated credit bureaus |
| Crypto and infrastructure | Crypto-asset exchange service providers and financial market infrastructures (FMIs) |
The FSA's English policy page lists the guideline with a publication date of 20 October 2025 for the English text. The original Japanese guideline dates from October 2024. Check the FSA site for later revisions before an audit, because the translation states it may change.
How the two tiers of measures work
Each section of the guideline is split into fundamental response measures, numbered (1), (2) and so on, and recommended measures, lettered (a), (b) and so on. The FSA describes the first tier as foundational actions that institutions generally need to implement and the second as examples that major institutions and FMIs should consider, drawn partly from foreign authorities' practice.
| Question | Fundamental response measures | Recommended measures |
|---|---|---|
| Who is expected to meet them | Institutions in scope generally, scaled by risk | Institutions with significant potential impact on communities or the economy |
| Typical content | Policies, asset ledgers, patch deadlines, MFA for remote access, log procedures, backups, incident plans | CISO with direct access to top management, TLPT, internal red team, SBOMs, 24/7 monitoring, SIEM correlation, decoy accounts |
| How to evidence | Documented control plus proof it operates | Documented decision to adopt, adapt or defer, approved by management |
Our recommendation (NHI Mgmt Group): treat every recommended measure as a decision to record. A mid-sized institution that declines TLPT should still have a minuted rationale and a compensating test plan, because the proportionality language in section 1.1 cuts both ways.
Key obligations by section
Governance and oversight (2.1)
- Board policy: the board treats cyber risk as part of organisation-wide risk management and sets a basic policy (2.1.1).
- Review cadence: the management framework is formally reviewed at least once a year, policies and regulations at least annually, and senior management reports on cyber security at least annually (2.1.1, 2.1.2). The recommended tier adds KPI and KRI reporting at least twice a year.
- Three lines: the risk management function provides independent oversight and reports to the CRO and the board (2.1.4); internal audit covers cyber security, including third-party risk, with external experts where needed (2.1.5).
Identifying risk (2.2)
- Asset ledgers: keep current ledgers of information systems, external services, hardware and software, including support end dates and versions, plus data flow and network diagrams (2.2.1). Recommended measures extend this to multifunction printers, shadow IT and SBOMs for in-house software.
- Risk assessment: at least once a year and when significant threats emerge or new products launch; exceptions need senior management approval (2.2.2).
- Patching: set patch deadlines by system criticality and severity, patch high-risk configurations promptly, and record management-approved exceptions with a risk assessment; group and overseas systems are in scope for high-severity issues (2.2.3).
- Testing: regular vulnerability assessment and penetration testing by risk, with both platform and application testing for public websites (2.2.4). Recommended measures include VPN and internal environments, regular threat-led penetration testing (TLPT) in production without prior notice to the blue team, and an internal red team. See the Threat-Led Penetration Testing Guide.
- Exercises: regular exercises, including industry-wide ones, with senior management, the CISO and business heads directly involved and realistic scenarios with serious customer impact (2.2.5). The FSA runs a financial industry-wide exercise series called Delta Wall.
Defence, detection and recovery (2.3 to 2.5)
- Access: minimum necessary access with separation of duties; strict control of privileged accounts; MFA for remote access to critical systems; default password changes and automatic expiry of unused IDs; management of third-party access rights (2.3.1).
- Logs: written procedures for log content, scope, access control, tamper prevention, retention and storage, with regular checks that logs are fit for purpose (2.3.4.2). Monitoring covers hardware, networks, personnel access and external service provider access, with periodic review of alert thresholds (2.4.1).
- Backups: isolated, tamper-resistant backups with integrity checks and recovery tests, and a check during restoration that backup data has not been tampered with or infected (2.3.3, 2.5.2.6).
- Incidents: response and contingency plans per attack type with priorities, RTO and recovery level objectives (2.5.1); triage and escalation to the CISO and senior management by predefined criteria; prompt reporting to authorities under applicable laws; sharing of TTPs with Financials ISAC Japan or JPCERT/CC (2.5.2.3). The guideline itself sets no hour-based reporting clock: follow the reporting rules in the supervision guidelines for your business type.
Third parties (2.6)
Section 2.6 expects the whole supply chain to be considered: a ledger of third parties, risk-based assessment by role, importance, data sensitivity and connectivity, due diligence before engagement, contract terms covering audit rights, subcontracting, incident reporting and data location, continuous monitoring and exit planning. The recommended tier adds concentration risk, fourth parties and exit strategies for critical providers. The FSA published commissioned research on third-party cyber risk management at large US, EU and UK institutions on 3 April 2026. See the Third-Party Risk Management Guide.
The 2026 frontier AI request
On 22 May 2026 the FSA issued a request to financial institutions titled "Short-Term Measures for Financial Institutions in Response to Changes in Threat Posed by Frontier AI", prepared by a working group in which the Bank of Japan took part. A provisional English translation is on the FSA site. It assumes attackers using advanced AI will find and exploit vulnerabilities faster, and asks institutions to act within roughly one month as a general guideline.
| Measure in the request | What it asks for | Guideline section it reinforces |
|---|---|---|
| Management priority | Executives, CIOs and CISOs directly involved | 2.1.1 |
| Priority services and systems | Focus on externally accessible systems behind critical services such as internet banking | 2.2.1, 2.2.2 |
| Technical debt | Close unneeded ports, remove redundant privileged accounts, upgrade end-of-support systems | 2.2.3, 2.3.1 |
| Patching capacity and vendor contracts | More staff for triage, contracts that allow night and holiday patching with SLA reporting | 2.2.3, 2.6 |
| Risk-based patching | Prioritise by exposure and likelihood of exploitation, not CVSS alone | 2.2.3 |
| Beyond patching | Virtual patching, bot mitigation, segmentation, MFA for privileged accounts, EDR | 2.3.1, 2.3.4 |
| Disruption readiness | Plan for proactive suspension of priority services and test BCPs and communications | 2.5.1 |
What it means for non-human identities and AI agents
The guideline does not use the term non-human identity, but its access, logging and third-party sections apply to service accounts, API keys, batch IDs and integration credentials as much as to staff accounts. Three clauses do most of the work:
- Privileged account control (2.3.1): many of the most privileged IDs in a core banking or payments estate are system accounts used by middleware and schedulers. Put them under the same MFA or equivalent strong control, dual control and time restriction regime, using vaulting and short-lived credentials where an interactive factor cannot apply. See the Service Account Security Guide.
- Unused ID expiry (2.3.1): automatic expiry is easy for people and hard for machine accounts with no owner. An NHI inventory with named owners and last-used dates is the practical prerequisite. See the NHI Dormancy Detection guide.
- External service provider access (2.4.1, 2.6): vendor maintenance connections and SaaS integrations are third-party access. Record each credential a supplier holds, and monitor its use.
The frontier AI request's call to remove redundant privileged accounts is, in our reading, an NHI clean-up instruction for most institutions, because orphaned system and vendor accounts usually outnumber redundant human admins.
Compliance steps
- Confirm the text: download the current Japanese guideline and the English translation, and record the revision you are mapping to.
- Gap assess by section: build a register with one row per numbered and lettered measure, its owner, current state and evidence. Mark recommended measures as adopt, adapt or defer with a rationale.
- Fix the ledgers first: asset, external service and third-party ledgers (2.2.1, 2.6) feed patching, testing and access reviews, so complete them before anything else.
- Close access gaps: MFA for remote access to critical systems, privileged account controls, unused ID expiry and default password removal (2.3.1), covering human and machine accounts.
- Set patch deadlines: write criticality-based deadlines and an exception route with senior management approval (2.2.3), then apply the frontier AI request's exposure-based prioritisation.
- Test and exercise: schedule vulnerability assessment and penetration tests, take part in industry exercises, and for larger institutions plan TLPT (2.2.4, 2.2.5).
- Prove recovery: run restore tests from isolated backups and verify RTO and RPO in an exercise (2.3.3, 2.2.5).
- Report and review: brief senior management at least annually (twice a year with KPIs and KRIs if adopting the recommended tier) and review the framework every year.
Framework mapping
The FSA does not publish a crosswalk. The mapping below is NHI Mgmt Group's own, to help institutions reuse NIST CSF 2.0 based programmes.
| FSA guideline section | NIST CSF 2.0 category |
|---|---|
| 2.1.1 to 2.1.3 Policies, regulations, resources | GV.RM Risk Management Strategy, GV.RR Roles, Responsibilities, and Authorities |
| 2.1.4 and 2.1.5 Oversight and internal audit | GV.OV Oversight |
| 2.2.1 Asset management | ID.AM Asset Management |
| 2.2.2 to 2.2.4 Risk, vulnerability management, testing | ID.RA Risk Assessment, ID.IM Improvement |
| 2.3.1 Authentication and access | PR.AA Identity Management, Authentication, and Access Control |
| 2.3.3 and 2.3.4 Data protection and system security | PR.DS Data Security, PR.PS Platform Security, PR.IR Technology Infrastructure Resilience |
| 2.4.1 Monitoring | DE.CM Continuous Monitoring |
| 2.5 Response and recovery | RS.MA Incident Management, RC.RP Incident Recovery Plan Execution |
| 2.6 Third-party risk | GV.SC Cybersecurity Supply Chain Risk Management |
Measuring progress
- Coverage: percentage of fundamental measures with evidence of operation, and percentage of recommended measures with a recorded decision.
- Patch timeliness: share of critical vulnerabilities on priority systems fixed within your own written deadline.
- Privileged hygiene: privileged accounts, human and machine, with an owner, strong authentication and a last-used date inside your expiry window.
- Third-party ledger: share of suppliers with a current risk tier, contract clauses for incident reporting and audit, and a listed set of credentials.
- Recovery proof: restore tests completed against target RTO and RPO in the last twelve months.
Common failure patterns
- Treating the recommended tier as optional for everyone: larger institutions that ignore lettered measures without a recorded decision struggle to explain themselves in supervisory dialogue.
- Ledgers that stop at servers: external services, SaaS and machine accounts missing from the asset ledger leave patching and access reviews blind.
- Exceptions with no expiry: patch and access exceptions approved once and never revisited, contrary to the management approval route in 2.2.3.
- Vendor contracts that block patching: maintenance agreements with no night or holiday cover, which the 2026 request asks institutions to check.
- Head office frameworks that skip overseas sites: section 1.2.1 and 2.2.3 expect group and overseas systems to be covered.
Practitioner checklist
- Record which revision of the guideline, Japanese and English, your mapping uses.
- Hold a register of every numbered and lettered measure with an owner and evidence.
- Complete asset, external service and third-party ledgers, including end-of-support dates.
- Enforce MFA for remote access to critical systems and strict controls on privileged accounts, including system accounts.
- Expire unused IDs automatically and remove redundant privileged accounts.
- Write criticality-based patch deadlines and a time-limited exception route.
- Run penetration tests and exercises with senior management involved; scope TLPT if you are a major institution or FMI.
- Keep isolated, tamper-resistant backups and prove restoration against RTO and RPO.
- Check vendor maintenance contracts for patching cover and incident reporting clauses.
- Report to senior management at least annually and review the framework every year.
Standards and references
- Financial Services Agency: Guidelines on Cybersecurity for the Financial Sector (provisional English translation)
- Financial Services Agency: Policy Approaches to Strengthen Cyber Security in the Financial Sector
- Financial Services Agency: Short-Term Measures for Financial Institutions in Response to Changes in Threat Posed by Frontier AI
- Financial Services Agency: Strengthening the Management of Third-Party Cybersecurity Risks by Financial Institutions
- Financial Services Agency: The Dialogue between the FSA and FISC
- NIST: Cybersecurity Framework 2.0
Related NHI Mgmt Group resources: Japan APPI Guide · Japan Active Cyber Defence Act Guide · Financial Services Cyber Regulation Map · Privileged Access Management Guide. This guide summarises the FSA Guidelines on Cybersecurity for the Financial Sector as at 9 November 2026 and is not legal advice.