Yannick H.,
Too Long; Didn't Read
Resilience Engineering shifts the focus from "How do we restore System X?" to "How do we maintain business operations no matter what happens?" The framework consists of five dimensions: Business Impact, Process Resilience, Technical Architecture, Organizational Capability, and Compliance & Governance. The order is crucial—always start with the business, never with IT. We will show you how to approach these dimensions systematically.
What distinguishes companies that are operational again within 48 hours after a cyberattack from those that struggle for weeks?
It is not the budget. Nor is it the number of security tools.
It is the way they think about resilience.
In recent years, we have seen both kinds of companies. Some have perfect disaster recovery documentation and still fail. Others may have less paperwork, but they have something more important: a systematic ability to function under pressure.
Today we’ll show you the framework that makes the difference.
Why Most Resilience Approaches Fail
Most IT departments start with technology. That is their comfort zone.
"We need backups. Failover servers. Multi-cloud. More redundancy."
The problem? Without business context, this leads to perfectly secured systems that nobody needs — and unprotected systems that are business-critical.
An example: A manufacturing company invested six figures in highly redundant IT infrastructure. Perfect availability. But when their main supplier went down because of a cyberattack, production still came to a standstill. IT worked flawlessly — but without components from the supplier, no one could work.
The flawed assumption: Resilience does not mean "IT systems always run." Resilience means "business processes always run — or at least well enough."
The Framework: 5 Dimensions of Operational Resilience
Operational resilience requires a systematic approach across five dimensions. Each one builds on the previous one. And the order is non-negotiable.
The 5 dimensions build on one another — always start with business impact, never with technology.
Dimension 1: Business Impact & Critical Services
The key question: Where is your revenue? Which processes must keep running?
Before you even look at a single line of IT architecture, you need to understand which business processes are truly critical. Not "somehow important" — critical in the sense that: if this does not run, we lose money or customers or both.
What you need to identify:
Revenue-critical processes – the processes that directly generate revenue
Regulatory-critical processes – the processes whose failure has regulatory consequences
Dependencies – what does each process need to run? (IT, suppliers, staff)
Maximum tolerable outage time – how long can we go without this process?
Practical tip: Work with your business units, not the IT department. They know what actually generates money.
If you already have a Business Impact Analysis – check whether it is up to date and whether it answers these questions.
Dimension 2: Process Resilience
The key question: How do you keep working when critical systems or suppliers fail?
Now it gets concrete: For each critical process from Dimension 1, you need answers to:
Fallback options: What is Plan B? Can the process run manually? Are there alternative suppliers?
Minimum Viable Operations (MVO): With what reduced capacity can we continue while we solve the problem?
Activation time: How quickly can we switch to Plan B?
The 70% rule: Perfect redundancy is unaffordable. But 70% capacity within 30 minutes protects more revenue than 100% capacity after 48 hours.
Practical example:
An e-commerce company defined:
Normal: 500 orders/day through the online shop
MVO (70%): 350 orders/day through phone + manual entry
If AWS goes down, an emergency hotline is active within 30 minutes. Not perfect, but revenue keeps flowing.
Dimension 3: Technical Architecture
The key question: Which IT systems support your critical processes? Where are the single points of failure?
Only now — in Dimension 3 — do we look at IT. But not in isolation, always in relation to business processes.
What you need to analyze:
IT system-to-business mapping: Which systems support which critical processes?
Current vs. required availability: Is the current SLA sufficient?
Single points of failure: What has no redundancy? No failover?
SPOF mitigation: How do you eliminate or reduce these weaknesses?
A common mistake: Companies often have highly redundant systems for non-critical processes — and single points of failure in critical ones. Because no one has systematically analyzed the connection between IT and business.
Dimension 4: Organizational Capability
The key question: Can your teams make clear decisions under stress? Who is responsible?
Technology alone is not enough. The best fallback infrastructure is useless if no one knows who is allowed to activate it.
What you need:
Clear decision structures: Who is allowed to decide what? Within what time limit?
RACI matrix for crises: Responsible, Accountable, Consulted, Informed – for every critical decision
Substitution rules: What happens if the decision-maker is unavailable?
Trained teams: Hands-on exercises, not PowerPoint presentations
An important insight: In a crisis, an 80% correct decision in 15 minutes is more valuable than a 100% correct decision in 4 hours.
Define clear escalation paths with time limits. If the decision-maker cannot be reached after 15 minutes, the decision automatically goes to the deputy.
Dimension 5: Compliance & Governance
The key question: How do you use regulatory requirements as a structure for your resilience?
NIS2, FINMA, GDPR – many people see these as bureaucracy. But smart companies use these requirements as a checklist.
What regulation gives you:
Structure for your documentation
Prioritization through regulatory significance
External validation of your measures
Legal certainty in a crisis
Practical approach: Map regulatory requirements to your resilience dimensions. You will find that what NIS2 and FINMA demand is usually what you need anyway. Regulation simply gives you the structure.
Why the Order Is Crucial
The framework is not a buffet where you can choose where to start.
If you start with technology, you are solving the wrong problem.
Wrong approach (common):
IT buys more backup capacity
IT implements multi-cloud
At some point, someone asks, "Do we actually need this?"
No one knows for sure
Right approach (rare):
Business defines critical processes and maximum outage times
Process owners develop fallback options
IT implements the technical support for them
The organization trains the procedures
Compliance validates the whole setup
The difference: In the first case, you have expensive IT infrastructure that may secure the wrong things. In the second case, you have an organization that knows how it functions when it matters.
How to Get Started
Don’t panic. You do not have to do everything at once.
Quick wins (4–6 weeks):
Business Impact Analysis for the top 10 business processes
Dependency mapping for the 3 most critical processes
Define and test one fallback scenario
Phase 2 (3–6 months):
Minimum Viable Operations for all critical processes
RACI matrix for crisis decisions
First quarterly drill with the leadership team
Full resilience architecture (12 months):
All 5 dimensions systematically implemented
ISMS integrated with the resilience framework
Continuous improvement based on tests and real incidents
The Short Version
5 dimensions build on one another: Business Impact → Process Resilience → Technical Architecture → Organizational Capability → Compliance
The order is non-negotiable – always start with the business
Dimension 1 is the key – without understanding critical processes, everything else is guesswork
The 70% rule – fast degraded operations beat perfect late recovery
Compliance as structure – use NIS2/FINMA as a checklist, not a burden
What Now?
Start with an honest question: Which 3 business processes generate 80% of our revenue?
If you can answer that, you have the starting point for Dimension 1. If not, you have your first task.
(And if you realize you need support to implement the framework systematically — that is exactly what we are here for.)
Read More
Business Impact Analysis: Identifying critical business processes – The first step toward Dimension 1
Crown jewel analysis: Focusing on what really matters – A related approach
CISO as a Service – How mid-sized companies leverage security expertise
