From Security to Resilience: Can You Recover?

Cyber Resilience
Written By AKATI Sekurity Insights

Prevention is table stakes. The sharper question for the board is how quickly the business gets back on its feet after a disruption, and what proving that capability demands of the people who run it.

Somewhere inside Netflix, a piece of software spends its working day doing something that sounds like sabotage. It reaches into the company's live systems, the ones serving customers in real time, and switches them off. Not in a test environment. In production, during business hours, deliberately. Netflix built it in 2010, named it Chaos Monkey, and the idea behind it has since travelled into banks, hospitals and airlines.

The logic is counterintuitive and, once you sit with it, difficult to argue against. You cannot trust a recovery you have never performed. A backup that has never been restored is a guess. A failover that has never been triggered is a hope. So rather than wait for an outage to reveal which assumptions were wrong, you cause small failures yourself, often, on your own schedule, until recovering from them stops being an emergency and becomes a routine.

That is the shift the word resilience is pointing at, and it asks a different question from the one security usually answers. Security asks whether you can keep bad things out. The work is necessary, and it has a ceiling. Most of what actually halts a business is not a master hacker. It is a software update that ships a defect, a certificate nobody renewed, a cloud region that goes dark, a supplier whose outage quietly becomes yours. Failure has too many doors to lock them all. So the mature question moves past whether you will be disrupted to how quickly you can operate again, and whether you have ever proven it.

What resilience actually demands

Answering that is engineering work rather than aspiration, and it has a specific shape.

It begins with deciding what must not stop. Most organisations treat every system as equally urgent in a crisis, which means none of them gets the right attention first. Resilient ones name their handful of important business services, the things the company exists to do: take the order, clear the payment, settle the claim, keep the production line moving. Everything else can wait an hour while those come back.

For each of those services, you set honest recovery targets. The recovery time objective is how long the service can be down before the harm becomes unacceptable. The recovery point objective is how much data you can afford to lose, counted backwards from the moment of failure. The discipline lives in the word honest. The right number is the one the business genuinely needs, agreed with the executives who own the revenue, not the comfortable figure buried in a continuity plan nobody has opened since the audit.

Then you map what each service depends on, including the third parties, because a supplier is where modern failure most often enters. And finally, the step almost everyone skips, you prove the whole arrangement works by breaking it on purpose. Restore the service from backup under timed conditions. Trigger the failover. Run the rehearsal end to end. The gap between the recovery time you achieve in that exercise and the recovery time the business needs is the only honest measure of where you stand.

The regulators arrived first

What started as a Silicon Valley engineering habit has, across much of the world, hardened into law.

The European Union's Digital Operational Resilience Act has applied since January 2025, with no transition period. It requires financial firms to manage and report technology incidents, to govern the risk concentrated in their technology suppliers, and, pointedly, to run a programme of operational resilience testing. The regulation's own language frames the goal as the ability to withstand, respond to and recover from disruption, and it reaches beyond Europe's borders to bind the critical technology providers that serve EU firms wherever those providers happen to sit.

Malaysia's regulators reached the same conclusion on their own terms. Bank Negara's Risk Management in Technology policy requires financial institutions to test their backup and restoration procedures periodically to confirm they can in fact recover, and to test a recovery strategy before a system goes live, with the board held accountable for the outcome. The Securities Commission's Guidelines on Technology Risk Management, which now sit above its older cyber rules, define the recovery time objective in plain terms and, in the 2024 revision, added requirements to test critical systems before deployment and to report near-miss events.

For a board, this changes the standard of evidence. "We have backups" is no longer an answer. The answer that regulators, and increasingly insurers and large customers, now expect is a date and a number: when you last made a critical service fail, and how many hours it took to bring it back.

Five moves to begin

None of these requires a new budget line to start.

  1. Name your important business services. Sit with the executives who own the revenue and agree the three or four things that cannot stop. This is a business decision before it is a technical one.

  2. Write down the recovery time each of those services truly needs, then find the gap. You will likely discover the technology cannot yet meet the number. That gap, in priority order, is your roadmap.

  3. Run one real recovery this quarter. Restore a critical service from backup, or trigger a failover, under timed conditions. Book the next exercise before you finish the first.

  4. Rehearse the decisions, not only the systems. Settle now who declares an incident, who authorises a failover, and who speaks to customers and the regulator, so nobody is inventing the chain of command in the middle of the night.

  5. Put recovery time on the board agenda as a standing number, reported with the same regularity as safety incidents.

The question that has changed

Return to that piece of software at Netflix, patiently switching off the systems it is paid to protect. It looks like vandalism and works like insurance. The company that makes itself fall over on a quiet Tuesday, by choice, is the one least surprised when something knocks it over on a Sunday by accident. The board's question is no longer how high the walls stand. It is whether anyone has ever made the business fail on purpose, watched the clock, and been satisfied with the answer.

Sources

Disclaimer

This article is provided for general information and discussion. It reflects publicly available sources at the time of writing and may not account for subsequent developments. It is not legal, financial, regulatory, or security advice, and should not be relied upon as a substitute for guidance from a qualified professional familiar with your specific circumstances. Regulatory obligations vary by jurisdiction and entity type, and readers are encouraged to consult the original sources and their own advisers directly.

AKATI Sekurity
Resilience & Strategy
Frequently Asked
Questions
From Security to Resilience
Resilience, recovery & the rules 06
Cybersecurity is the discipline of keeping incidents from happening, through controls such as patching, access management and monitoring. Cyber resilience is the rehearsed ability to keep operating during a disruption and to recover quickly afterwards. Security is measured by what it prevents; resilience is measured in recovery time, and crucially, in whether that recovery has been tested.
Chaos engineering is the practice of deliberately injecting failures into live systems to confirm they can recover. Netflix pioneered it in 2010 with a tool called Chaos Monkey, which randomly switches off production systems during business hours. The principle is that you cannot trust a recovery you have never performed, so you cause controlled failures regularly until recovery becomes routine.
Important business services are the small number of functions an organisation cannot allow to stop, such as taking orders, clearing payments or settling claims. Resilience planning prioritises restoring these first in a crisis, rather than treating every system as equally urgent. The concept sits at the centre of modern operational resilience regulation.
The recovery time objective (RTO) defines how long a critical service can be unavailable before the business impact becomes unacceptable. The recovery point objective (RPO) defines how much data an organisation can afford to lose, measured backwards from the point of failure. Both appear in regulatory frameworks including the EU's DORA and Malaysia's Bank Negara RMiT and Securities Commission technology risk guidelines.
DORA applies directly to financial entities operating in the EU, and it also reaches the critical third-party technology providers that serve those firms, wherever those providers are based. It has applied in full since 17 January 2025, with no transition period, and requires firms to run an operational resilience testing programme rather than simply maintain a written plan.
Bank Negara Malaysia's Risk Management in Technology policy requires financial institutions to test backup and restoration procedures periodically and to test a recovery strategy before a system goes live, with board accountability for the outcome. The Securities Commission's Guidelines on Technology Risk Management define the recovery time objective and, in its 2024 revision, added requirements to test critical systems before deployment and to report near-miss events.
AKATI Sekurity Insights
Next

What the Dark Web Already Knows