Most major infrastructure failures do not come out of nowhere. They are preceded by months of small signals: a server that went out of support, a backup that was never tested, a certificate close to expiry. The ten questions below need no technical expertise to ask, but their answers reveal where your organisation really stands.

How to use these questions

Put them to your technical team or service provider, and ask for a written answer to each one with evidence: a report, a screenshot from the monitoring system, or the date of the last test. An answer of "yes, everything is fine" with no evidence counts as "we don't know".

1. Are any systems or devices running outside the manufacturer's support period?

Why it matters: an operating system or firmware that has reached end of support no longer receives security fixes, and any vulnerability found in it stays open for good. Spare parts and technical support for old hardware also become slower and more expensive.

A good answer: an inventory of all servers, network devices and storage with the end-of-support date for each, and a replacement plan for anything that reaches it in the next twelve months.

2. How often are security updates applied, and who follows them up?

Why it matters: many breaches exploit vulnerabilities for which a fix was released weeks or months earlier and never applied.

A good answer: a regular, known update cycle (monthly, for example), a faster track for critical updates, and a report showing which devices are behind on updates and why.

3. What stops if just one component fails?

Why it matters: a single point of failure is any component with no alternative: one power supply, one storage unit, one internet line, or one network switch that everything passes through. Sometimes it is a person: a lone systems administrator who knows all the passwords.

A good answer: a list of critical systems, with what happens to each when power, storage or the network fails, and what the alternative is. And on the human side: at least two people able to manage each critical system.

4. When was a backup restore last tested?

Why it matters: having a backup does not mean you can restore from it. Many organisations discover that their backups are incomplete or corrupt on the day they need them.

A good answer: the date of the last actual restore test, how long it took, and at least one isolated copy that cannot be deleted or encrypted from the same network. For more detail, see An Untested Backup Is Not a Backup.

5. How much capacity is left before we hit the limit?

Why it matters: running out of storage or memory stops systems suddenly, and it usually happens at peak business hours.

A good answer: current utilisation of storage, CPU, memory and network, how fast it is growing, and an estimate of how long remains before expansion is needed, with alert thresholds set well before the limit is reached.

6. What does the monitoring watch, and who sees the alert?

Why it matters: if the first person to notice an outage is an employee or a customer, monitoring effectively does not exist. And an alert that goes to a mailbox nobody reads at night is no different from no alert at all.

A good answer: a list of what is monitored (servers, services, network, backups, certificates), who receives the alert at any given time, including outside working hours and during holidays, and the expected response time.

7. When do security certificates and domain registrations expire?

Why it matters: an expired website certificate or domain registration takes the website or email down immediately, and it is one of the easiest outages to prevent.

A good answer: a list of all certificates and domains with their expiry dates, automatic renewal where possible, an alert well before expiry, and registration accounts held in the organisation's name, not in the name of an employee or a former supplier.

8. Who has administrator rights, and is multi-factor authentication enabled?

Why it matters: a compromised administrator account means full control of the systems. Old accounts belonging to staff who have left, or suppliers whose contracts have ended, are among the most forgotten doors.

A good answer: an up-to-date list of everyone with administrative rights and why, multi-factor authentication enabled on every administrative account and all remote access, and a periodic review that removes unused rights.

9. Is there current documentation and a network diagram?

Why it matters: during an outage, the time lost trying to understand how systems connect to each other prolongs the downtime. Without documentation, knowledge stays in individuals' heads.

A good answer: a network diagram that matches reality, an inventory of servers and services and where they are, written procedures for recurring tasks, and the date each document was last updated.

10. Do we have a disaster recovery plan, and when was it tested?

Why it matters: a fire, a ransomware attack or a data centre failure is rare, but its impact can last for days. A plan that has never been tested is an assumption, not a plan.

A good answer: a written plan that sets the order in which systems are restored, the acceptable downtime for each, and the acceptable amount of data loss, with the date of the last real exercise and what the team learned from it. To set restore priorities, it helps to calculate the cost of an hour of downtime (in Arabic) for each system.

How to read the result

Do not expect every answer to be perfect; the goal is to know where you stand, not to get full marks. Classify each question as one of three states:

State Meaning Action
Reassuring A clear answer with recent evidence Periodic review only
Needs follow-up An answer exists but is incomplete or out of date A remediation plan with a date and an owner
At risk No answer, or "we don't know" A priority for the coming weeks

Start with the questions classified "at risk" that affect the systems with the highest impact when they stop, and repeat the check every six months or after any major change to the infrastructure.

The bottom line

Infrastructure health is not measured by the absence of outages so far, but by how clear the answers to these ten questions are. One hour with your technical team is enough to draw the picture, and the gaps it reveals are far cheaper to fix now than after they turn into an incident.