A fintech we worked with had good engineers and a sensible product, but if you asked what would happen in the first hour of a serious incident, the answers diverged. Who decides whether to take a system offline? Who talks to customers, and who to a regulator? Where is the list of who to call after midnight? They had an incident-response document, but it had been written once, filed, and never tested against a realistic scenario. In a payments business, the first confused hour is exactly where a containable problem becomes a public one.
They were not asking us to predict every possible attack. They wanted the confidence that, on a bad day, the team would respond as a team rather than as a set of individuals each improvising. That is a readiness problem, and readiness can be practised.
The challenges we had to solve
- The plan looked complete on paper but had never met a real scenario, so nobody knew where it would break under pressure.
- Roles and decision rights were unclear. In an incident, ambiguity about who calls the shots costs the time you can least afford.
- Communication paths to customers, partners and regulators were vague, which matters most in the regulated corner the business operates in.
- The team had never practised together, so the muscle memory that keeps a bad hour calm simply was not there yet.
How we approached it
We started by making the plan usable: clear roles, clear decision rights, and a short, practical runbook rather than a long document nobody reads in a crisis. We made sure detection and escalation actually connected, so an alert reaches a person who can act, and we mapped out who communicates with whom, and when, including the regulatory obligations a payments business carries. The point was to remove the questions people would otherwise be asking for the first time at the worst possible moment.
Then we ran a tabletop exercise: a realistic scenario, walked through with the people who would actually be in the room, with no production system harmed. Talking it through surfaced the honest gaps, an out-of-date contact, an unclear handoff, a backup assumption nobody had checked, while it was still cheap to fix them. We sized the whole thing to the business; a tabletop or two a year is a sustainable habit, where an elaborate programme would have been abandoned. The readiness is theirs; our part was helping them rehearse it before it was tested for real.
Where it stands
The fintech now has a plan its people have actually used, even if only in rehearsal, and they know what each person does in the first hour. The gaps the exercise found are closed, and the team has agreed to run another scenario periodically rather than wait for a real one to teach them. A serious incident would still be hard, but it would be handled, not improvised.