How to use it

Eight areas, in the order we work through them. Each one is a question you can answer today, what it costs you when the answer is wrong, and what “fine” actually looks like.

Two rules make it worth doing. Answer from evidence rather than memory — “backups run nightly” is a belief until someone has restored one. And write down what you cannot answer: the gaps matter more than the passes, because an unknown is a risk you are carrying without pricing it.

Copy it, forward it, or take the questions into your next conversation with whoever runs your systems. Nothing here is behind a form.

One of eight

1. Capacity and monitoring

This is first because it is the most common cause of a serious outage and the most commonly skipped. Disks fill up. Nothing exotic happens.

Do you get an alert when a disk passes 80% full — and does someone receive it?
Is anyone monitoring free space on your database and log volumes specifically, rather than only the system drive?
When a server runs out of memory or CPU for an hour, do you find out from monitoring or from a member of staff?
Are certificate expiry dates monitored? TLS certificates, VPN certificates, code-signing, domain renewals.
Do you know the growth rate of your largest data store, and when it runs out of room at that rate?
Does an alert go somewhere a human reads, rather than to a mailbox nobody opens or a channel everyone has muted?

What it costs when it is wrong. A full disk rarely stops a service cleanly. Writes fail halfway, data structures are left inconsistent, and what should have been a restart becomes a recovery with a real risk of data loss. The failure is mundane, the consequence is not, and the warning sign — a volume trending towards full over weeks — is visible long in advance to anyone watching for it.

What good looks like. Thresholds on every volume that matters, alerts that reach a named person, and a quarterly look at growth trends rather than only at today’s number.

Two of eight

2. Backup and restore

Everybody has backups. Far fewer have restores, and the difference only becomes visible on the worst day you will have this decade.

When was the last time someone restored a file, a mailbox and a whole server from backup, and how long did each take?
Is there an off-site or offline copy that ransomware on your network could not reach or encrypt?
Are Microsoft 365 or Google Workspace backed up separately? Retention inside those services is not a backup — it will not survive a deletion nobody noticed for months.
Do you know your recovery time objective, and has it been measured rather than estimated?
Is anybody alerted when a backup job fails, or does it fail silently into a log?
Are the backups themselves protected by separate credentials, so an administrator account compromise does not also destroy the recovery path?
Do backups cover the things that are not servers: network device configurations, SaaS data, anything living on a laptop?

What good looks like. Three copies, two media, one off-site. A restore tested on a schedule with the duration written down, failures that page someone, and credentials for the backup system that are not the same ones used for everyday administration.

Three of eight

3. Identity and access

The most common finding in this section is also the easiest to fix: people doing ordinary daily work in accounts that can delete anything.

Does anyone read email or browse the web signed in as a domain or global administrator?
Is multi-factor authentication enforced for every account with administrative rights, with no exceptions?
Is it enforced for everyone else, including remote access and VPN?
How many accounts belong to people who have left? When did anyone last check?
Is there a joiner-mover-leaver process that does not depend on someone remembering to mention it?
Are shared or generic logins in use — admin, reception, a password in a spreadsheet?
Are credentials in a managed password system, or in a document, a drawer, or somebody’s head?
Do third parties and suppliers have standing access they no longer need?

What good looks like. Separate accounts for administrative work, MFA with no exemptions, offboarding that happens the same day, and an access review often enough to be boring.

Four of eight

4. Patching and supported software

Is anything in use past its end-of-support date — an operating system, a database, a firewall, a line-of-business application?
How long does a critical security patch take to reach every machine, measured rather than assumed?
Who is responsible for patching network devices, hypervisors and firmware, as opposed to laptops?
Are third-party applications patched, or only the operating system?
Is there a maintenance window people know about, or does patching happen when someone gets round to it?
Does any system remain unpatched because nobody is confident it will come back up afterwards?

What good looks like. Nothing unsupported in production without a written, dated reason and a plan. Critical patches applied within fourteen days. Someone named for every category of device, including the ones nobody thinks of as computers.

Five of eight

5. Network and segmentation

Is the internet-facing device a business firewall, or the router the ISP supplied?
Are guest wi-fi, staff devices, servers and payment systems on separate networks, or do they all see each other?
Can anything on the network reach a management interface — a hypervisor, a switch, a camera system?
Is remote access provided through a maintained VPN or zero-trust service, or by a port forwarded to a desktop?
Is anything exposed to the internet that nobody intended to expose? When did you last look from the outside?
Are printers, cameras, door entry and building systems on their own segment? They are rarely patched and frequently the way in.
Does a current network diagram exist, and does it match reality?

What good looks like. A supported firewall with rules somebody can explain, VLANs that separate things which have no business talking to each other, and an external scan often enough that you learn about an exposed service before someone else does.

Six of eight

6. Documentation and key-person risk

The question in this section is the one most businesses already know the answer to and would rather not say out loud.

Is there one person without whom nothing could be restored? What happens if they are on a plane?
Could somebody competent but new pick up your estate from the documentation and run it?
Is there an asset inventory — what you have, where it is, what it does, when it was bought, when support ends?
Are runbooks written for the things that actually go wrong, rather than for the things that are easy to document?
Do you know which systems the business genuinely cannot trade without, in priority order?
Does your supplier hold documentation you have never seen? Could you get it if the relationship ended tomorrow?
Are credentials recoverable without the one person who set everything up?

What good looks like. Documentation that is handed over rather than held as leverage, an inventory someone maintains, and no single human being who constitutes a dependency.

One observation worth passing on, because it catches people out: documentation is necessary and it is not sufficient. A complete set — architecture, runbooks, known issues — shortens a recovery considerably, but it does not transfer the judgement that tells you which of three plausible causes is the real one at two in the morning. Treat a handover as the start of someone learning a system, not as the moment they have learned it.

Seven of eight

7. Disaster recovery

If the office were unreachable on Monday morning, could people work? For how long?
If your main server or cloud tenancy were lost entirely, what is the recovery plan and who executes it?
Has any of it ever been rehearsed, even on paper?
Do you know your maximum tolerable data loss, and does your backup frequency match it?
Who declares an incident, who talks to customers, and who decides when it is over?
Are the contact details and credentials needed during an incident available when the systems holding them are down?
Does your insurer or a key client require a documented plan? Would the one you have satisfy them?

What good looks like. A plan short enough to be read under pressure, stating what is restored first and how long it takes because somebody timed it, rehearsed at least annually, and reachable when everything else is not.

Eight of eight

8. Cyber Essentials readiness

Increasingly a condition of bidding rather than a badge, particularly in public sector and defence supply chains. These are the five controls, and where assessments usually fail.

Firewalls. A supported boundary firewall, default passwords changed, inbound rules documented and justified.
Secure configuration. Default accounts removed or renamed, unnecessary software and services off, auto-run disabled.
User access control. Named accounts, least privilege, administrative rights granted deliberately and reviewed.
Malware protection. Active and updating on every in-scope device, including BYOD if it touches organisational data.
Security update management. Everything in support, critical and high-severity updates applied within fourteen days.

Where it usually fails. Two things, consistently: an unsupported operating system still in production, and administrative accounts used for day-to-day work. Both are in sections 3 and 4 above, which is why those come first.

Certification is issued by an IASME-accredited certification body, not by a consultant. What a consultant can do is tell you honestly what would fail today and fix it before you submit. Our SecOps work covers the evidence side in more depth.

If the list produced more questions than answers

That is the normal outcome, and it is not a judgement on anyone. Nobody builds this stuff wrong on purpose; it accretes while people are busy doing the actual job.

We run this checklist as a fixed-price engagement: two days on site, one writing it up, £1,950. You get an inventory, a diagram, the risks ranked by what they would cost you, and a twelve-month plan with indicative figures. If you would rather work through it yourself and only call about two of the eight sections, that is a perfectly good outcome too.

Talk to us Engagements and prices

The IT health check, in full.