How is infrastructure resilience assessed before systems become business-critical?

Infrastructure resilience is assessed by comparing the business impact of disruption with the strength, independence and recoverability of the controls protecting each service. The assessment considers how technology supports business processes, what can fail, how failure would spread, and whether the organisation can restore an acceptable service using documented and tested procedures. It should be completed before a system becomes essential, because resilience is more difficult and costly to establish after dependencies, data and user expectations have become fixed.

1. Establish the business context

The assessment starts with the services the organisation needs to operate, rather than with servers or software in isolation. Each service is linked to the business activities it enables, such as order processing, production control, customer communication, document access or financial administration. The review should identify which activities are time-sensitive, which can tolerate a degraded service, and which depend on accurate or recent data.

This provides a basis for defining acceptable recovery objectives. A recovery time objective sets out how long a service can be unavailable before the business impact becomes unacceptable. A recovery point objective defines how much data loss, measured from the last usable copy, the business can tolerate. These objectives should be agreed with business owners; they should not be inferred solely from technical preferences.

2. Create a complete dependency map

A resilient service may depend on more components than its primary application. The assessment maps relationships between:

• servers, storage, networks and internet connections;
• identity services, authentication and access permissions;
• cloud platforms, hosted applications and external suppliers;
• power, premises, environmental controls and physical equipment;
• data sources, integrations, APIs and scheduled processes; and
• specialist knowledge, administrative accounts and recovery documentation.

Dependency mapping reveals indirect failure paths. For example, an application may remain operational while users cannot sign in because an identity service is unavailable, or a restored database may be unusable because an integration or encryption key has not been recovered. These relationships are often more important than the specification of any individual device.

3. Examine failure modes and control independence

Each significant component is reviewed for the ways it could fail, including hardware faults, software defects, configuration errors, cyber incidents, supplier outages, connectivity loss and accidental deletion. The assessment then considers whether protective controls fail independently or share the same weakness.

Redundancy only improves resilience when the alternative is genuinely separate. Two virtual machines on the same host, two backup copies in the same location, or two network connections using the same underlying carrier may appear resilient but still have a common point of failure. The review therefore considers physical separation, administrative separation, supplier concentration and the effect of a major incident affecting several systems at once.

4. Assess capacity and the ability to operate in a degraded state

Resilience is not limited to recovering from a complete outage. Systems should also be assessed against gradual pressure, such as increasing data volumes, more users, heavier network traffic, limited storage or reduced processing capacity. Monitoring trends and known constraints helps identify when a system may become unstable rather than waiting for performance to deteriorate during a critical business period.

The review should also document how the service behaves when part of the environment is unavailable. This may include reduced functionality, manual workarounds, read-only access or prioritised access for particular teams. A degraded operating procedure is useful only when its limitations, ownership and steps are understood by the people expected to use it.

5. Validate backup and recovery arrangements

Backup status alone is not evidence that a service is recoverable. Assessment should cover whether backups include the required data, configurations, system states and recovery keys; whether they are protected from unauthorised alteration; and whether retention matches the organisation’s obligations and recovery objectives.

Recovery validation should restore representative data or systems in a controlled environment and confirm that the result is usable. This includes checking application dependencies, permissions, integrations, data integrity and the sequence in which components must be brought back. A technically successful restore may still fail the business test if users cannot access the service or if essential information is incomplete.

6. Review operational readiness

People and procedures form part of the infrastructure’s resilience. The assessment checks whether recovery responsibilities are assigned, contact information is maintained, privileged access is available when needed, and documentation is sufficiently clear for someone other than its original author to follow. It should also identify decisions that require business approval, such as operating with reduced functionality or accepting a temporary data gap.

Exercises can test these arrangements without waiting for a real incident. A tabletop exercise examines decisions and communication, while a technical recovery exercise tests restoration and dependencies. Findings should be recorded as actions with an owner, priority and review date.

7. Produce a prioritised resilience plan

The result should be a risk-based view of the environment, not simply a list of technical observations. Each finding can be assessed by considering the likelihood of failure, the scale of business impact, the time available to recover, the strength of existing controls and the effort required to reduce the risk. This helps distinguish urgent weaknesses from improvements that can be planned alongside normal infrastructure changes.

Resilience assessment is also a continuing activity. New applications, acquisitions, office moves, supplier changes, cloud migrations and business growth can introduce new dependencies or alter recovery objectives. Reassessment after significant change, supported by monitoring and periodic testing, keeps the resilience position aligned with the way the organisation actually operates.

A managed IT infrastructure service can support this process by maintaining accurate asset and dependency records, reviewing technical controls, coordinating recovery tests and translating findings into practical improvement work. The important measure is not whether an environment contains more equipment or backup copies, but whether the business can continue or restore its essential services in a controlled and understood way when part of that environment fails.