In an era when system outages and cyberattacks can shake business continuity, incident response at financial institutions must deliver not just fast recovery but a level of quality that stands up to audit. What does it take to reach a more advanced level of incident response?
Our guest is Alex Sayle, who worked in platform and security at some of the world's largest financial institutions—Goldman Sachs, Morgan Stanley, and JPMorgan—and now serves as Head of Security & Platform at Fujitsu Launchpad. In conversation with SIGQ CEO Takaaki Kanetsuki, he explores the incident response mindset forged in global finance and the areas where Japanese financial institutions should focus their efforts.
What Incident Response Looks Like at Global Financial Institutions
Kanetsuki: If there is one thing that sets security and incident response practice at global financial institutions apart from other industries, what would it be?
Alex: What stuck with me most was being told, over and over, "Never hide a problem." Take fraud prevention: the person who discovers and reports fraud is not held responsible; it's treated as a problem for the whole organization. The point isn't to find a culprit but to look at the mechanisms and structures that allowed the fraud to happen, so you can uncover larger fraud and prevent recurrence. The same applies to incident response, and it's a mindset shared across risk management in finance generally. If you notice signs of an incident, report the situation promptly, raise your hand, and speak up. Then, even if you personally triggered the incident, it's framed as "the problem versus us" rather than a hunt for someone to blame.
Kanetsuki: Many Japanese companies default to holding individuals accountable, so that's a fundamental difference.
Alex: Yes. In global finance, the focus is on "what" and "when," not "who." If someone presses a dangerous button, the person who pressed it isn't the problem; the fact that the button could be pressed at all is. It's the same idea you see in SRE today—learn from the system rather than blame the individual—but it has been embedded in the financial industry for around 20 years.
Kanetsuki: Where does incident response at a large financial institution differ decisively from that at a non-financial company?
Alex: First, the organization operates on the assumption that incidents will always happen. There's a 24-hour command center, and the structure is built around handoffs between people. Second, there's a culture of not trying to drive risk to zero, but of assuming something is always broken and responding according to priority. Third, processes are designed on the premise that mistakes will be made. Financial regulators press hard on the cause of an incident and on measures to prevent recurrence. "We'll be more careful next time" doesn't cut it, so the response has to be built into the system.
Kanetsuki: I see. With reporting obligations to regulators on top of reporting to management, the incident response process gets complicated. And while all this external reporting is going on, the team on the ground still has to push ahead with the technical work: finding the cause and restoring service. How do you actually run a process this complex?
Alex: The most important thing in the initial response is to get an accurate picture of the current situation. You establish how far the impact extends—the party that caused the event, the parties affected, and the customers beyond them. Bringing together the people needed to do that is one of the command center's main roles.
Next, under the command center's direction, you clearly separate the people responsible for communicating with stakeholders from the people responsible for recovery. If the recovery team gets pulled into stakeholder communications, they can't focus on the actual recovery work. When the communications lead sets a clear timeline—"the next status update will be in one hour"—it holds off inquiries until then and lets the recovery team concentrate on the job.
The command center also has the authority to call in whoever is needed for the response. If specialist knowledge becomes necessary partway through, the command center finds the right person and assigns them. In a large-scale incident, this facilitating role of the command center is critical.
Kanetsuki: Incidents broadly fall into security incidents and system outages. Is the response process you just described the same for both, or does it differ by incident type?
Alex: The initial response is the same. At the moment an incident occurs, you often don't know whether it's security-related or a system failure. But if it turns out to be a security incident partway through, the first milestone changes. For a normal incident the goal is recovery; for a security incident the goal is containment. At that point, collecting logs, identifying the point of entry, and preserving forensic evidence become far more important. The entry point is the same, but the next steps change depending on the milestone.
Kanetsuki: People talk about "audit-ready incident response," and I think it matters especially in finance. In a financial context, what does "audit-ready" actually mean? For example, at what level of detail do you record the response timeline, the evidence, and the decision-making process?
Alex: Two things matter. First, someone who wasn't there at the time must be able to trace what happened afterward. Second, there must be evidence that some process was followed, even in an emergency.
Regulatory reports require an extremely detailed timeline. Specifically:
- What happened and when
- Scope of impact
- What recovery work was carried out
- When service was restored
- Who performed the work and what authority they had
That is the level of granularity you have to record. Naturally, that means keeping detailed work logs.
Another point that needs care: emergency response procedures must be documented in advance and followed. In a medical context, saving lives comes first, and there may be situations where deviating from procedure is acceptable. Not in finance. Because fraud can be disguised as an emergency, you are expected to follow procedure even in an emergency.
That's exactly why keeping the mechanisms you'd only use in an emergency in a state where they can be used day to day is the cornerstone of incident response in finance.
What to Leave to AI, What Humans Must Decide: Incident Response in the Age of AI
Kanetsuki: AI agents are starting to be used in incident response. As a security leader, where do you draw the line between what can be left to AI and what humans should do?
Alex: For business processes that involve working with AI, there are two models: "human on the loop," where AI works autonomously under human supervision, and "human in the loop," where a human must make the decision at a defined point. Security and incident response still assume the latter—a human is always involved. In other words, gathering information, organizing it, and presenting options can be left to AI. But decisions that carry risk have to be made by a human.
Kanetsuki: At the same time, AI agent technology is advancing rapidly. How do you see incident response changing going forward?
Alex: Whether "human on the loop" becomes possible in incident response ultimately comes down to whether AI can be held accountable. In reality, beyond the technical challenges and integration into business processes, laws and regulations will have a major influence.
In medicine, for example, even as AI adoption advances, the principle that the doctor makes the final decision still stands. Against that backdrop, it's hard to see the financial industry being the first to say, "It's fine to leave the decision to AI."
Kanetsuki: On a related note, one of the key use cases for AI agents in incident response is reporting. For example, can AI-generated reports and timelines be used for audits or regulatory reporting?
Alex: Under current protocols, the final report has to be submitted as a human judgment. In other words, you must leave approval and evidence showing that "a human reviewed this," and that is one of the bottlenecks to using AI.
To change that, regulators first need to accept AI-generated reporting within a defined scope. For example, they could accept AI-generated preliminary reports on the condition that the sources behind each conclusion are clearly cited. On the submitting side, you could then move to a phased approach: submit an AI-generated preliminary report first, and have humans review and correct the content for the final report.
Kanetsuki: What about use cases where AI agents assist humans? Major financial institutions have 24/7 incident response in place, but I hear that fintech companies and regional banks often struggle to build an equivalent setup. For those organizations, is AI a realistic way to raise the standard of incident response?
Alex: There's a great deal of potential. Incident response is highly dependent on individuals. The quality of the work depends on the environment someone has been in and the quality and quantity of experience they've accumulated. In a small organization, though, someone with no experience is often suddenly handed incident response. Those are exactly the people for whom delivering best practices through AI is most valuable. With AI organizing information, presenting options, and supporting human judgment, even a small team should be able to respond at a much higher level.
Kanetsuki: An "AI harness," essentially. And I think it's an important point that the standard of someone's incident response depends so heavily on the environment they've worked in and the managers they've learned under.
Alex: People who have been part of a good team, even once, are simply better at it. In Japan, though, the pool of people with that experience is small, and low workforce mobility makes it worse.
At financial institutions overseas, many people build their careers by moving between several banks, and the knowledge and experience gained at one organization spreads to the next with each move. In Japan, low mobility means that kind of circulation rarely happens.
That's exactly why we need to use AI to spread good practices and insight widely, and close the experience gap.
Raising the Baseline: What Japanese Financial Institutions Should Do
Kanetsuki: For major financial institutions that already have a certain level of incident response in place, which areas should they strengthen next, with global standards and the AI era in mind? In particular, even where major Japanese institutions have advanced response structures, much of it depends on vendors. Compared with overseas, where in-house is the norm, what challenges do you see?
Alex: In fact, whether in-house or vendor-built, the more advanced and complex a system is, the more unavoidable silos become. Making black-box areas visible and clarifying who is responsible for what is the challenge ahead for every organization. To do that, each vendor and team needs to build AI and documentation that can explain their own systems, creating touchpoints that AI can easily understand. When something goes wrong, instead of immediately calling the person in charge, you ask the AI first. The AI assesses the situation and escalates to a human only when it's genuinely necessary.
When vendors are involved in particular, communication crosses company boundaries, so some people hesitate to reach out—even a simple inquiry can eat up time and money. Companies can also end up passing responsibility back and forth. Going through AI could reduce that kind of inter-organizational friction.
Kanetsuki: That said, in a project involving multiple vendors, it's not realistic to expect the other vendors to adopt an incident management tool built by one of them.
Alex: No, it isn't. Conversely, that's precisely where a tool from an independent startup like Incident Lake has an advantage: with no vested interest in any particular vendor, it can serve as a neutral space that exists for the customer.
Kanetsuki: On the other hand, some financial institutions can't match the investment and headcount of the major players. With limited resources, where should they focus—defense, recovery, or elsewhere?
Alex: The more limited an organization's resources, the more it needs to consolidate its data in order to use AI. But if you hesitate over "which data, and how much of it, do we give the AI?" every time an incident occurs, you slow down the response. To make AI-driven incident response work, you need to get ahead of that: classify your data, define its scope of use, and set clear criteria for what AI is allowed to use.
Kanetsuki: You've said that "compliance is a weapon, not a shackle." At the same time, investment in incident response is hard to see paying off if nothing happens, so people will ask why spend money on something that may never occur. What does it take to get senior management to understand the need for this investment and bring them on board?
Alex: The front line and senior management speak different languages and care about different things. So you have to learn how to talk to executives.
Executives fundamentally want to keep costs down. Rather than relaying the technical or system details as they are, you need to explain them from a business perspective: "What risk do we face if we don't act?" and "What markets does acting open up for us?"
For example, what compliance and security mean changes with a company's stage of growth. When a startup moves into the enterprise market, customers start demanding security and compliance. If you've already done the work and can say "and here is the evidence," you close deals faster than your competitors. Compliance becomes a weapon that accelerates growth.
Once a company is large, on the other hand, incidents become a question of "when," not "if." The spread of advanced offensive AI is raising that risk further. Without adequate preparation, you expose yourself to major risks such as reputational damage and the financial losses that follow.
In short, for a small organization compliance is a weapon for growth; for a large one, it's armor against unavoidable risk.
To get people to understand the need to invest in security and incident response, you have to make the case in that kind of business language.
Kanetsuki: Finally, do you have a message for readers who work in incident response at Japanese financial institutions and the vendors that support them?
Alex: Start small, and keep at it without compromising. Begin by understanding where your data is, what it's used for, and how fresh it is. Start small, automate, and keep going: those three things are what matter most in preparing for incidents in the age of AI.
The priority is to identify the core operations that cannot be allowed to stop, and then make the structure explicit: who makes decisions when an outage occurs, the emergency contact chain, and the recovery procedures. Once that foundation is in place, the realistic approach is to bring AI into the heavy-lift phases—gathering information and coordinating communications.
What matters is not letting data end as isolated points. Collect it continuously and the points connect into lines. Keep collecting and the different lines combine into a surface. Once you can see the surface, the big picture comes into view—where the vulnerabilities and problems are, and where information leaked from.
Kanetsuki: I learned a great deal. Thank you very much for your time today!