Insight
Security Operations for Financial Institutions: FSA Guidelines, FISC Safety Standards, and SOC
Based on the October 2024 Financial Services Agency (FSA) Cybersecurity Guidelines for the Financial Sector, this session explains their relationship with FISC Security Standards and Financials ISAC. We will cover how SOCs meet the required 'detection and response' capabilities, the reality shown by regional financial institution self-assessments, and the suitability of AI SOC.

Security operations for financial institutions have transitioned over the past few years from "each company's voluntary initiatives" to "an area where supervisory authorities present frameworks and continuously verify their effectiveness." The "Guidelines on Cybersecurity in the Financial Sector," published by the Financial Services Agency (FSA) in October 2024, is a turning point document. This article outlines the key points of these guidelines, clarifies their relationship with the FISC Security Standards and Financial ISAC, explains how a SOC (Security Operations Center) can satisfy the required "detection and response," and explores realistic options for regional financial institutions facing talent and budget constraints.
Threat Environment and Regulatory Trends for Financial Institutions
First, let's look at the threat environment. According to the National Police Agency's (NPA) "Threat Situation in Cyberspace in 2025," the number of reported ransomware incidents tracked by the NPA in 2025 was 226, remaining at a high level. Small and medium-sized enterprises (SMEs) accounted for approximately 60% of the affected organizations, and VPN devices were the entry route in over 60% of cases. Only slightly more than 50% of organizations recovered in less than a month, and over 50% experienced total investigation and recovery costs of 10 million yen or more (NPA, 2026).
There are also figures directly related to financial institutions. The same report states that the number of fraudulent transfers related to online banking in 2025 was 4,747, with total damages of approximately 10.397 billion yen, and phishing accounted for approximately 90% of the methods used. It was also recorded that from late December 2024 to early January 2025, critical infrastructure operators, including transportation and financial institutions, suffered consecutive disruptions believed to be caused by DDoS attacks (NPA, 2026). In IPA's "10 Major Information Security Threats 2026," the top threat for organizations was "Damage from ransomware attacks," followed by "Attacks targeting supply chains and subcontractors" in second place, and "Cyber risks surrounding the use of AI" in third (IPA, 2026). Financial institutions must simultaneously prepare for direct attacks on their own organizations, phishing targeting customers, and breaches via third parties such as contractors, shared data centers, and cloud providers.
Against this backdrop, the FSA published the "Guidelines on Cybersecurity in the Financial Sector" on October 4, 2024. While supervisory guidelines for each business category previously contained provisions regarding cybersecurity management and system risk management, these guidelines were established as "more detailed" directives independent of those supervisory guidelines. Concurrent with the release, supervisory guidelines for various business categories—including major banks, regional/small-and-medium financial institutions, insurance companies, and financial instruments business operators—were amended simultaneously and applied immediately (FSA, 2024). In July 2025, formal partial amendments were made in conjunction with the reorganization of the NISC (FSA, 2025).
Key Points of the FSA Guidelines
Positioning, Scope, and Two-Tiered Response Items
The guidelines consist of three parts: "Section 1: Basic Concept," "Section 2: Cybersecurity Management Framework," and "Section 3: Strengthening Collaboration Between the FSA and Related Organizations." Section 2 is divided into six domains: "Framework Establishment," "Risk Identification," "Cyber Attack Defense," "Cyber Attack Detection," "Incident Response and Recovery," and "Third-Party Risk Management." The scope covers almost all business categories that have cybersecurity management provisions in their supervisory guidelines, including major banks, regional/small-and-medium financial institutions, insurance companies, financial instruments business operators, funds transfer service providers, crypto asset exchange service providers, and agricultural/fishery cooperative financial institutions (FSA, 2024).
In practice, the most critical aspect is that each item is written in two tiers: "Basic Response Items" and "Recommended Items." The guidelines define the former as "items commonly referred to as cyber hygiene and other basic measures that financial institutions generally need to implement." The latter are positioned as practices recommended for implementation by institutions whose incidents could significantly impact regional communities or economies, or as best practices that major financial institutions and key clearing/settlement organizations should reference. Crucially, the guidelines explicitly state that they "do not demand a one-size-fits-all response." Instead, institutions are required to adopt a "risk-based approach" to identify and evaluate risks in light of their business environment, management strategy, and risk tolerance, and to implement mitigation measures proportionate to those risks (FSA, 2024). FSA inspections and monitoring are also conducted on a risk-based basis aligned with scale and characteristics. Regional financial institutions do not need to mechanically satisfy all "recommended items," but they must be prepared to explain the rationale behind their chosen baseline.
Management Involvement and Responsibilities
The guidelines explicitly position cybersecurity as a management responsibility. A key talking point when explaining this to executive leadership is that if damages occur due to an inadequate cybersecurity management framework relative to the organization's scale, characteristics, and risks, directors and other officers "may be held liable for damages due to breach of duty of care or negligence of duty." Basic response items include the board of directors establishing a basic policy for cybersecurity management, maintaining the necessary management framework, conducting reviews at least once a year, formulating action plans including multi-year plans, and appointing a CISO (Chief Information Security Officer) under management responsibility while requiring risk status and progress reports at least once a year. Recommended items include KPI/KRI reporting at least twice a year, positioning the CISO in a role with direct, daily reporting lines to management, and setting risk appetite and risk tolerance (FSA, 2024).
Cyber Hygiene and Defense
The core of the "Basic Response Items" is cyber hygiene—the basic measures that represent daily hygiene management. This includes hardware and software inventory management, vulnerability management and patching, authentication and access management including multi-factor authentication (MFA), log collection and monitoring, anti-malware measures, data protection and encryption, and backups designed with ransomware in mind. Regarding patching, no specific number of days is mandated; instead, organizations are required to "set deadlines for responses such as patch application based on system criticality, risk, or vulnerability severity." For log management, the requirement is to "formulate and regularly review procedures for log acquisition, monitoring, and retention," meaning retention periods and methods must be defined as procedures, though no uniform retention period is specified (FSA, 2024).
Third-Party Risk Management
The guidelines dedicate an independent section to third-party risk management. Third parties here broadly include other organizations with business relationships or contracts, such as system subsidiaries, vendors, cloud and service providers, business partners, and API integration partners. Basic response items list the establishment of a centralized department to manage third parties, maintenance of registries, pre-transaction due diligence, explicit definition of roles, responsibilities, audit rights, and subcontracting procedures in contracts/SLAs, incident response and reporting procedures, execution/reporting of vulnerability assessments, continuous monitoring aligned with risk significance, and decommissioning processes including data destruction and access revocation upon transaction termination (FSA, 2024). As discussed below, outsourcing SOC services and deploying AI SOCs also fall under this section's oversight.
Detection, Incident Response, Recovery, and Exercises
Regarding detection and response, the core topic of this article, the guidelines specify the following. Under Detection (2.4), basic response items require organizations to "formulate and review as necessary procedures for monitoring, analysis, and reporting" to detect cyber attack indicators such as anomalies and IoCs (Indicators of Compromise), include cloud services in the monitoring scope, analyze whether detected indicators constitute incidents (including impact scope and severity), and promptly report to the appropriate responsible personnel. Monitored activities include connection of unauthorized devices, suspicious behaviors, unauthorized network intrusion, abnormal data transfers, unusual access patterns, and maintenance work by external service providers. On top of this, "continuous monitoring (24/7/365)" and using tools like SIEM to aggregate multiple monitoring feeds for real-time correlation analysis are positioned as "Recommended Items" (FSA, 2024).
Under Incident Response and Recovery (2.5), the baseline is to establish incident response plans and contingency plans (covering recovery plans) for each attack type, defining response priorities, target recovery times, and target recovery levels. The response process is structured into initial response (detection, triage, determining response necessity, reporting to the CISO and management), analysis (preserving evidence such as logs beforehand and analyzing the preserved logs; keeping records from detection to recovery), customer response and public relations (prompt reporting to regulatory authorities, public disclosure as necessary, and sharing attack threat intelligence with Financial ISAC, JPCERT/CC, etc.), containment (explicitly defining authorized personnel beforehand to decide whether to prioritize containment or evidence preservation), eradication, and recovery (explicitly defining personnel authorized to approve business resumption, and paying attention to potential backup tampering/infection). Under Exercises and Drills (2.2.5), conducting regular exercises, participating in cross-industry drills, ensuring active involvement of management, CISOs, and business unit leaders, including realistic scenarios with severe customer impact, and regularly validating and revising response plans are set as basic response items (FSA, 2024).
Positioning of FISC Security Standards, Financial ISAC, and Cross-Industry Exercises
Relationship with FISC Security Standards
In the practical operations of financial institutions, the "FISC Security Guidelines on Computer Systems for Financial Institutions" (FISC Security Standards), compiled by the Center for Financial Industry Information Systems (FISC), are widely referenced alongside the FSA guidelines. The FSA guidelines explicitly list four related guidelines to reference: the "Action Plan on Cybersecurity for Critical Infrastructure" and "Guidelines for Formulating Safety Standards" decided by the Cybersecurity Strategic Headquarters, the FISC Security Standards, the NIST Cybersecurity Framework, and the Cyber Risk Institute Profile. For contingency planning, they point to FISC's "Manual for Formulating Contingency Plans in Financial Institutions" (FSA, 2024).
Broadly speaking, the division of labor is that the FSA guidelines define "the management framework that supervisory authorities expect financial institutions to maintain," while the FISC Security Standards show "specific control items in system design, operation, and auditing." Many financial institutions use the FISC Security Standards to verify compliance in system department internal controls, IT audits, and contractor/cloud evaluations. Thus, the supervisory guidelines define "what to achieve" while the FISC Security Standards complement them with "how to achieve it." Since the FISC Security Standards are updated continuously, referencing the latest official FISC publications for specific control items is recommended.
Financial ISAC and Delta Wall: "Mutual Assistance"
The guidelines emphasize not only internal organizational capabilities but also sector-wide information sharing. According to the guidelines, the Financial ISAC Japan is an organization established in August 2014 to share and analyze cybersecurity information among Japanese financial institutions to improve the safety of the financial system. The guidelines state that it is desirable to actively utilize insights such as technical problem solving, best practices sharing, and analysis of the latest attack trends and vulnerabilities supported by the Financial ISAC. Upon incident occurrence, organizations are expected to share threat intelligence, such as attacker TTPs (Tactics, Techniques, and Procedures), with information-sharing bodies like the Financial ISAC and JPCERT/CC after removing confidential information (FSA, 2024). The Financial ISAC publicly shares that it conducts threat sharing/analysis, crisis response exercises, joint drills for members, and working group activities (Financial ISAC).
Regarding exercises, "Delta Wall," a cross-industry financial sector cybersecurity exercise hosted by the FSA, is conducted annually to further improve incident response capabilities across the industry. Delta Wall 2025, conducted in October 2025, planned for the participation of 177 financial institutions. Its name is derived from the three perspectives of self-assistance, mutual assistance, and public assistance, combined with a defensive wall (FSA, 2025). Given that the guidelines list participation in cross-industry exercises as a basic response item, the practical key is to run a cycle where findings from these exercises are reflected back into the organization's incident response plans and SOC operational procedures.
Meeting "Detection and Response" Requirements with a SOC
The entity that implements these requirements into daily operations is the SOC. As explained in What is a SOC? Roles, Tier Structure, and the Basics & Limits of 24/7/365 Operations, a SOC is an organizational function that monitors logs and alerts, detects and analyzes threats, and initiates incident response. It can be built in-house, shared, or outsourced (for definitions, see also Glossary: SOC). Mapping the guidelines' requirements to SOC functions yields the following alignment:
Formulating Monitoring, Analysis, and Reporting Procedures (2.4): A SOC playbook defining monitored systems, detection rules, escalation criteria, and contacts. Maintenance access by cloud providers and contractors must also be monitored.
24/7 Monitoring and Real-Time Correlation Analysis via SIEM (2.4, Recommended): A 24/7/365 alert monitoring structure and a SIEM platform aggregating logs from EDR, network, identity, and cloud sources.
Log Collection, Monitoring, and Retention Procedures (2.3) and Evidence Preservation (2.5): Identifying logs to collect, establishing retention and tamper-prevention rules, and defining procedures to preserve logs prior to analysis during incidents.
Initial Response, Triage, and Reporting to Management (2.5): Primary alert triage, prioritization based on business impact, and escalation criteria for reporting to the CISO.
Containment, Eradication, and Recovery (2.5): Mitigation playbooks with pre-authorized roles for host isolation or account suspension, and coordination with IT and business units.
Exercises and Drills (2.2): Tabletop and live exercises tracing the path from SOC detection to management decisions, and refining procedures based on results.
Among these, the initial challenges for many organizations are "continuous monitoring" and "audit-ready response." If it is unclear who monitors alerts during nights and weekends and who authorizes isolation, the organization cannot achieve the guidelines' goals of "promptly reporting to the appropriate responsible personnel" or "defining authorized personnel beforehand." This challenge is analyzed in depth in Why Security Frameworks Struggle During Nights and Weekends. Furthermore, maintaining records from detection to recovery is a prerequisite for regulatory reporting, internal audits, and post-incident analysis. A SOC's ability to record the investigation process serves directly as evidence of compliance. Specific procedures from detection to containment are detailed in First Response and SOC Alignment: A Practical Playbook from Detection to Containment.
The Reality of Regional Financial Institutions: Self-Assessment Milestones and Challenges
How large is the gap between the guidelines' standards and actual operations? The FSA and the Bank of Japan have required financial institutions to conduct a "Cybersecurity Self-Assessment (CSSA)" and have shared the aggregated results with the industry annually since FY2022. The FY2023 aggregate results, published in April 2024, surveyed 99 regional banks, 254 shinkin banks, and 145 credit cooperatives (498 institutions in total), providing valuable primary data on regional financial institutions (FSA, 2024).
Regarding detection and monitoring, institutions with a 24/7 SOC increased to 68.1% (up from 62.7%), while 16.1% had a SOC but lacked 24/7 monitoring, and 9.4% had no plans to establish one. For incident response, 94.6% maintained rules to immediately isolate devices upon malware infection, yet only 50.0% had established night and weekend response procedures. For log management, 74.5% identified logs to collect, 68.3% had retention rules, and 57.9% had anti-tampering rules—meaning 30% to 40% of institutions still lacked these basic response items. While 95.0% formulated contingency plans by attack type and 83.7% conducted drills, only 42.7% simulated attacks on third-party contractors, and only 33.6% had set target recovery times (FSA, 2024).
The most significant constraint is talent. In the survey, 62.7% to 82.9% of institutions reported they "cannot secure sufficient talent" across security functions. Only 18.3% had talent development plans, and only 21.5% had multi-year training plans. In third-party risk management, only 58.6% centrally managed critical third parties within a designated department, and 12.1% had no risk management processes in place. The FSA concluded that while many regional financial institutions are making steady progress, "securing and developing cybersecurity talent and managing third-party risks remain persistent challenges" (FSA, 2024).
Faced with this reality, building a sophisticated, 24/7 in-house SOC independently is often unrealistic for regional institutions due to talent and cost constraints. The guidelines themselves suggest mutual assistance for cooperative financial institutions through shared centers or consolidating support via central bodies. They also advise considering internal talent development alongside external hiring (FSA, 2024). Practical options include utilizing shared data centers or group SOC functions, leveraging external monitoring services like MSS (Managed Security Service) or MDR (Managed Detection and Response), or combining AI agents for autonomous investigation to operate with a lean team. Cost, talent, quality, and speed comparisons between in-house and outsourced operations are structured in A Comprehensive Comparison of In-house SOC vs. Outsourcing (MSS/MDR). Regardless of the model, outsourcing monitoring does not transfer management responsibility; vendors remain third parties under Section 2.6, subject to due diligence, contractual reporting obligations, and continuous monitoring.
Does an AI SOC Fit Financial Requirements? Audit Trails, Explainability, and Manual Labor
Let's examine how an AI SOC—where AI agents autonomously investigate and respond to alerts—aligns with the compliance requirements of financial institutions. The mechanics of an AI SOC are explained in What is an AI SOC? Mechanism, Differences from Traditional SOC, and Deployment Benefits Explained, so here we focus strictly on the guidelines' perspective.
First, consider audit trails and explainability. The guidelines require that investigations be conducted on preserved logs and that records of response actions and collected logs be maintained from detection through recovery. Investigations by AI agents inherently document which logs were accessed, the rationale for classifying alerts as true or false positives, and what actions were executed in a highly consistent format. However, this requires a design where humans can easily trace and verify the investigation path and decision logic. When evaluating an AI SOC, financial institutions must verify whether they can present the "rationale and referenced data behind decisions" to internal auditors and regulators, and whether these records are stored in a tamper-resistant format.
Second, consider continuous monitoring and manual labor. The Yagura AI SOC uses AI agents designed with expert analyst workflows to autonomously investigate and respond to EDR and SIEM alerts 24/7/365. The AI-driven primary investigation helps reduce staff workloads, and its effectiveness is validated using the customer's own alerts by measuring investigation rates, manual analysis times, and labor savings. It integrates with over 100 security products, including EDR, SIEM, and identity tools. As a proprietary service, it integrates with existing deployments like Microsoft Sentinel and leverages a context memory that learns the customer's environment to improve investigation accuracy over time. Compared to self-assessment data showing that 16.1% of SOCs lack 24/7 monitoring and only half have night/weekend playbooks, an AI SOC is highly compatible as a means to build a round-the-clock investigation framework with limited personnel. Yagura serves financial institutions, including regional banks, as key customers, delivering services designed around these regulatory operational requirements.
Third, remember that the AI SOC itself is a third party under Section 2.6. Upon deployment, organizations must clarify data residency, storage, access permissions, incident reporting, audit rights, and data decommissioning upon termination within contracts and SLAs. Financial institutions must also define policies for autonomous AI mitigation actions (such as host isolation or account suspension) as part of "explicitly defining authorized personnel beforehand."
Compliance Checklist and Summary
This checklist helps verify guidelines compliance from a SOC operations perspective. Use it as a starting point for a risk-based approach tailored to your organization's scale and characteristics.
Does the board of directors establish a basic policy and multi-year plan for cybersecurity, reviewing and reporting on them at least once a year? Is the CISO appointed under management responsibility?
Are basic cyber hygiene items—such as asset inventory, vulnerability/patch management, MFA, log collection/monitoring, and backups—run as documented procedures?
Are procedures for monitoring, analysis, and reporting formulated, and do they cover cloud and vendor maintenance access? Is it clear who monitors and acts on alerts during nights and weekends?
Are logs to collect identified, with established rules for retention, storage, and tamper prevention? Is there a procedure to preserve logs prior to analysis during incidents?
Are there incident response plans and contingency plans for each attack type, with clear priorities, target recovery times, and authorized personnel for containment and resumption?
Are procedures and roles defined for reporting to regulatory authorities, communicating with customers, and sharing information with Financial ISAC, JPCERT/CC, etc.?
Do management, the CISO, and business units participate in regular exercises and cross-industry drills, with findings reflected back into plans and procedures?
For third parties—including outsourced SOCs and AI SOCs—are centralized departments, registries, due diligence, clear boundaries of responsibility, reporting duties, audit rights, and continuous monitoring established?
Is security staffing assessed, and is there a talent development plan combining external resources with internal training?
Both "Basic Response Items" and "Recommended Items" in the FSA guidelines demand a risk-based approach aligned with the scale and characteristics of the organization. In detection and response, the baseline requires monitoring, analysis, and reporting procedures, audit-ready log management, and attack-specific response plans with clear authorizations. Continuous 24/7/365 monitoring and real-time SIEM analysis are positioned as the recommended standard. As self-assessment results show, while regional financial institutions are advancing toward this standard, talent and third-party management remain common constraints. Combining shared services, outsourcing, and AI agents to build operations that can "prioritize alerts, investigate them, maintain audit trails, and explain decisions" with a lean team is a realistic path to meeting both FSA guidelines and FISC Security Standards.
Related Service: Discover "Yagura AI SOC," where AI agents autonomously investigate and respond to EDR and SIEM alerts 24/7/365 while maintaining complete investigation audit trails. We also welcome inquiries regarding security operations for financial institutions.
References
FSA, "Publication of the Guidelines on Cybersecurity in the Financial Sector" (2024): https://www.fsa.go.jp/news/r6/sonota/20241004/20241004.html
FSA, "Guidelines on Cybersecurity in the Financial Sector" Full Text (Established 2024, Partially Amended 2025): https://www.fsa.go.jp/common/law/cybersecurity_guideline.pdf
FSA, "Cybersecurity" Policy Page (2025): https://www.fsa.go.jp/policy/cybersecurity/index.html
FSA, "Results of Cybersecurity Self-Assessment for Financial Institutions (FY2023)" (2024): https://www.fsa.go.jp/news/r5/cyber/20240423.html
FSA, "Results of Cybersecurity Self-Assessment for Financial Institutions (FY2023)" Full Text (2024): https://www.fsa.go.jp/news/r5/cyber/honbun.pdf
FSA, "Execution of the Cross-Industry Financial Sector Cybersecurity Exercise (Delta Wall 2025)" (2025): https://www.fsa.go.jp/news/r7/sonota/20251014/deltawall2025.html
Financial ISAC Japan Official Site: https://www.f-isac.jp/
NPA, "Threat Situation in Cyberspace in 2025" (2026): https://www.npa.go.jp/publications/statistics/cybersecurity/data/R7/R07_cyber_jousei.pdf
IPA, "10 Major Information Security Threats 2026" (2026): https://www.ipa.go.jp/security/10threats/10threats2026.html
Yagura, Inc. "Yagura AI SOC": https://yagurasec.com/ai-soc



