Ask an organisation to describe its operational resilience and you will usually get a list of artefacts: the incident response plan, the recovery runbooks, the backup policy, the vendor escalation paths. Ask it to demonstrate resilience, under scrutiny from a board, a regulator or a major client, and the conversation changes.
The artefacts still matter. But demonstration requires something documentation cannot supply on its own: a set of operating agreements, made and tested before disruption arrives, that determine how the organisation actually behaves under pressure. This is the thread running through Triangle’s operational resilience series: resilience is not only what is designed or documented, but what can be operated, tested and evidenced.
In our experience, five agreements separate organisations that can demonstrate resilience from those that can only describe it.
1. Agree the minimum viable business
Resilience becomes concrete when the organisation agrees what good enough looks like under stress: the essential services that must remain available, the level at which they must perform, and the order in which they matter. This is a business agreement, not a technical one, and it should be written in plain language covering services, dependencies and priorities.
In cyber recovery design, this often starts with identifying the minimum viable company dataset, with remaining workloads recovered in phases. Applied to the whole organisation, it is also one of the fastest ways to expose gaps between board expectations and operational reality.
The test
>> If disruption hit a core service tomorrow, would every leader in the room name the same priorities?
2. Make decision rights explicit
In a disruption, speed comes from clarity. Agree in advance who can isolate systems, pause change or trigger failover. Agree who owns the business trade-offs when priorities collide, and who is responsible for integrity decisions, not only restoration actions.
Many organisations discover under pressure that they have escalation paths but not decision rights. The distinction buys your team time at moments that matter: an escalation path finds someone senior; a decision right defines who is authorised to act and what they are authorised to do. These agreements can be uncomfortable, because they make accountability visible. That is also why they work.
The test
>> Would the people managing the incident know what they can decide without waiting for a meeting?
3. Define recovery confidence, not just recovery time
Recovery speed is the headline metric in most programmes. It is not the whole story. Demonstrable resilience also requires recovery confidence: agreed criteria for validating that what you are restoring is trustworthy before services resume. That means integrity checks, dependency validation and a clear definition of what safe to resume looks like.
In cyber events, where clean restoration cannot be taken for granted, bringing a service back quickly is of little value if what comes back cannot be trusted.
The test
>> Could you show, rather than assume, that a restored service was validated before it returned to production?
4. Rehearse in conditions that produce evidence
Tabletop exercises have value, but they are not enough on their own. Demonstration requires rehearsal that includes technical steps, communications, dependencies and decision-making under time pressure, and that leaves a record: what was tested, what failed and why, and what changed as a result.
Evidence is what turns resilience from a promise into an assurance. It also reduces the organisation’s reliance on heroics and memory. The everyday discipline that makes rehearsal meaningful, from patching and lifecycle management to monitoring and configuration control, is covered across our operational resilience series. The agreement here is simpler: rehearsal is not complete until it has produced evidence.
The test
>> When did you last rehearse the full recovery path end-to-end, and what did it change?
5. Keep improvement visible and measurable
Resilience is a capability that has to keep pace with the environment, which means improvement needs a rhythm: review, prioritise, implement, validate, repeat. Operational data becomes the strategic asset. Which incidents recur? Where does change introduce instability? Which dependencies create fragility?
When that rhythm works, the results are measurable. As Liz McGing explains in the operational resilience series, Triangle’s managed services reporting has shown a 14% decrease in incidents year on year, with over 50% reduction in the first year of service. Numbers like these are themselves a form of evidence: proof that resilience is operating, not just documented.
The test
>> Could you show a board how the organisation is measurably more resilient than it was a year ago?
An operating model, in practice
An operating model is simply a way of working that is consistent, measurable and repeatable. These five agreements are what make it demonstrable. None of them requires a new platform or a larger document set. They require decisions, made in calm conditions, that hold in difficult ones.
We have written separately about how resilience is shaped in the design and running of IT platforms, and our operational resilience video series shows how it is delivered in practice, from leadership intent to the everyday discipline of managed services. This article sits alongside them as a practical framework for turning resilience activity into something an organisation can stand over.
-----------------
Explore related:
