Resilience is an operating model that connects critical services, architecture, recovery, decision rights, third parties, and executive accountability.
Begin With the Business Service
Cybersecurity programs often organize themselves around tools, control families, vulnerabilities, and technical domains. Those elements matter, but they are not the outcome. The outcome is the organization’s ability to protect trust, continue critical services, make sound decisions under pressure, and recover within an acceptable period of time.
The most useful starting point is a small set of critical business services: payments, customer access, lending, liquidity, communications, data, and the operational processes required to sustain them. For each service, leadership should understand the people, systems, third parties, facilities, data, and decisions that make recovery possible.
Architecture Is a Resilience Decision
Resilience is designed long before an incident. Redundancy, segmentation, identity architecture, immutable recovery points, data replication, dependency mapping, and operational runbooks determine whether an organization can isolate failure and restore service.
A recovery objective without architecture capable of meeting it is only an aspiration. Management should be able to explain which critical services have tested recovery paths, what dependencies could invalidate those paths, and where the organization is accepting concentration or single-point-of-failure risk.
Decision Rights Matter Under Pressure
Incidents expose ambiguity quickly. Who can disconnect a service? Who decides whether to invoke recovery? Who communicates with customers, regulators, law enforcement, vendors, and the board? What evidence is required before systems return to production?
Those decisions should not be invented in real time. A resilient operating model defines incident command, decision authority, escalation thresholds, communication responsibilities, legal and regulatory coordination, and the conditions for returning to normal operations.
Third Parties Are Part of the Operating Model
Financial institutions and fintechs depend on a dense network of core processors, cloud providers, payments platforms, telecommunications carriers, managed security firms, data providers, and specialized SaaS vendors. A vendor’s recovery plan does not automatically become the institution’s recovery plan.
Management should understand which third parties are required for each critical service, what alternatives exist, how incidents are reported, what evidence is available, how access can be controlled, and what the organization will do if a provider cannot meet its commitment.
Measure Recovery, Not Tool Count
Boards and executives need measures that describe operational confidence: time to detect, time to contain, time to make a decision, recovery time by critical service, recovery-point integrity, backup restoration success, exercise findings, dependency gaps, and closure of material actions.
The question is not whether every incident can be prevented. It is whether the organization can absorb disruption, protect essential functions, make informed choices, and recover without losing control of the narrative or the operating environment.
What leaders should carry forward
- 01
Anchor resilience in critical business services and their dependencies.
- 02
Design decision rights, architecture, recovery, and communication before an incident.
- 03
Report operational recovery confidence, not only security-tool activity.
Matthew March
Matthew March is a financial-services technology executive, board director, Fractional CISO, and adviser with more than 25 years of experience connecting technology strategy to growth, resilience, governance, and enterprise value.
Read Matthew’s Story
