A fire at a data centre in Almere caused IT problems earlier this year for organisations including Utrecht University and the Dutch Chamber of Commerce. As a result, users were temporarily unable to log in, several systems became inaccessible and some digital services no longer functioned as usual. A physical incident at a single location therefore had an immediate impact on employees, students, businesses and other users.
The incident shows how dependent organisations have become on digital infrastructure. Even information stored ‘in the cloud’ ultimately runs on physical servers, networks and data centres. Major cloud service providers such as Microsoft, Amazon and Google take a significant amount of technical management off organisations’ hands. However, using the cloud does not automatically mean that information and systems are always available.
What happens, for example, if a data centre goes down, a cloud region becomes unavailable or users can no longer log in? And how long can your organisation actually operate without a particular system? In this blog, we look at what availability really means, what organisations can learn from the data centre fire and how to determine the level of availability your organisation needs.
Within information security, availability concerns whether authorised users can access information and systems when they need them. This means that information must not only be preserved, but must also remain accessible and usable within the required timeframe.
A backup, for example, helps prevent information from being permanently lost. However, this does not automatically ensure availability. Users must be able to authenticate, the required application must be accessible and essential connections to other systems must function. If one of these components fails, the information may still exist but may no longer be usable within the relevant business process.
Availability therefore depends on more than technical measures. Recovery procedures, assigned responsibilities and temporary alternative working methods also determine whether an organisation can continue operating during a disruption.
Cloud service providers (CSPs) such as Microsoft, Amazon and Google offer extensive measures to limit downtime. These include redundant infrastructure, backups and distribution across multiple data centres or regions.
However, the availability of these options does not mean that every environment is automatically protected against every type of disruption. Actual availability depends on several factors:
The chosen cloud service and its configuration: not every service provides the same level of availability by default. Organisations may need to make their own choices regarding backups, redundant storage, multiple availability zones or failover to another geographical region. The way these features are configured also determines whether and how they are used in practice.
Dependence on a single region or location: an environment may have redundant technical components while still operating entirely within one geographical region. If that region becomes unavailable, several components may be affected at the same time. Distributing services across multiple regions reduces this risk, but requires additional configuration and often results in higher costs.
Dependence on other services: the availability of an application often depends on other components, such as an authentication service, network connection, database or integration with another supplier. If one of these components fails, the application itself may still be available while users are unable to use it. Certain application functions may also stop working correctly.
Agreements on availability and recovery: Service Level Agreements (SLAs) often describe the availability percentage a supplier aims to provide. However, this does not automatically indicate how quickly a specific environment will be restored or what support will be available during a disruption. Exceptions and contractual conditions may also play an important role. Major CSPs often use standard SLAs with limited scope for customisation. Organisations should therefore understand these relevant conditions and limitations.
The organisation’s own preparations: a CSP may provide technical recovery options, but the organisation must still decide who takes action during a disruption, which systems are restored first and which working methods are followed while the disruption continues.
The key consideration is therefore not only which measures a CSP provides. Organisations must also understand which risks those measures address, which dependencies remain and which additional measures are needed to support their own operations.
The fire at the data centre in Almere shows that a physical disruption can have significant consequences for digital services. Without drawing conclusions about the organisations involved, the incident offers several relevant lessons for organisations that depend on data centres, external suppliers or cloud service providers.
Systems may be distributed across multiple locations, while specific components, connections or data still depend on a single environment. A failover procedure may also require manual checks or a specific recovery sequence.
Organisations should therefore determine in advance how long a process may be unavailable and how quickly the supporting systems must be restored. A Business Impact Analysis (BIA) helps identify these continuity requirements and dependencies.
An application may be technically available but still unusable if, for example, the authentication service, network connection, database or a supplier integration fails.
A BIA therefore looks beyond individual systems. It also considers the information, suppliers, locations and employees needed to carry out a critical process.
During a disruption, it must be clear who makes decisions, which systems take priority, how relevant parties are informed and which temporary working method should be followed.
These arrangements can be documented in a Business Continuity Plan (BCP). A BCP describes how the organisation will continue operating during a disruption and how it will restore its services.
During a tabletop exercise, the relevant participants work through a realistic scenario together. This helps determine whether roles and responsibilities are clear, whether the recovery sequence is feasible and where additional measures are required.
The results can then be used to improve the BCP and the underlying response plans.
The incident therefore underlines that availability does not depend on technical measures alone. Organisations must also understand their critical processes and dependencies, document their recovery arrangements and regularly test whether these work in practice.
The fire at the data centre in Almere shows that availability cannot be taken for granted. Even when information and systems are hosted by a professional cloud service provider or external supplier, organisations remain dependent on technical choices, interconnected services and recovery capabilities.
Availability therefore does not begin with the question of which technical measures a supplier provides. Organisations must first determine which processes are critical, how long they may be unavailable and which systems, information and suppliers those processes depend on. Only then can they assess whether the chosen configuration and agreements adequately support their operations.
The challenge often lies not only in implementing technical measures, but particularly in making well-founded decisions and testing whether these work in practice. ICTRecht can support organisations by carrying out a Business Impact Analysis, drafting or improving a Business Continuity Plan and conducting tabletop exercises.
This ensures that availability is not merely a technical principle on paper, but a concrete part of business continuity. Identify in advance which types of disruption your organisation can absorb and what is needed to continue operating in a controlled manner during an incident.
Ready to strengthen your continuity? Explore our approach.