A growing business assembles an IT to-do list from several directions at once: an incident, a customer questionnaire, an insurer, a director who read something, and whatever the current supplier is recommending.
The list is usually reasonable. What is missing is an order, and the order is what decides whether the programme works — because most of these items depend on other items, and doing them in the wrong sequence means doing several of them twice.
This article is about sequencing. Each stage is covered in depth elsewhere and is linked rather than repeated; what is set out here is what has to come first, and why.
The dependency that governs everything else
Almost every worthwhile control depends on knowing two things: what you have, and who your people are. Nearly every failed programme skipped one of them.
| Later work | Depends on |
|---|---|
| Patching everything | Knowing what everything is |
| Endpoint protection coverage | An asset inventory to compare the console against |
| Offboarding that actually revokes | One authoritative directory |
| Least privilege | Individual accounts, not shared logins |
| Segmentation | Knowing what talks to what |
| Any audit or questionnaire answer | All of the above being true rather than assumed |
That table is the whole argument. An asset inventory and a single identity source are not exciting and they are not optional, because six later programmes each silently assume them.
The order
Stage one — know what you have and who you are
- 1
Asset inventory that maintains itself
Something that discovers devices rather than a spreadsheet that ages. The machine nobody knew about is the machine nobody patched.
- 2
One authoritative directory, one account per person
Shared logins defeat every control downstream — revocation, attribution, least privilege. This is a prerequisite, not an improvement.
- 3
MFA on everything reachable from outside
The highest value per unit of cost available, and it can be done immediately rather than waiting for the rest.
- 4
A backup that has been restored
Not configured — restored, timed, with the number written down. Until that has happened, the recovery capability is unverified.
Nothing in stage one requires a project. All of it is achievable in weeks and it removes the majority of the realistic risk. A business that stops here is in a defensible position.
Stage two — make it operable
- 1
A patch schedule with a named owner
Monthly for workstations, defined windows for servers, an emergency path for advisories that cannot wait.
- 2
Monitoring that alerts on the things that predict outages
Certificate expiry, backup age, disk trend, business outcome stopped. Not CPU.
- 3
Logs off the machines that produce them
Because logs on a compromised host are logs an attacker can edit, and because the machine may be gone when you need them.
- 4
Joiner, mover and leaver as a written process
Covering every system rather than the email account, and covering both sides of a hybrid estate.
- 5
A written incident response plan
Who decides, who calls the insurer, who talks to customers, and where the offline copy is.
Stage three — reduce the blast radius
- 1
Segment the network
Users, servers, voice, management, guest, and a segment for the devices that cannot be patched or authenticated.
- 2
Remove standing administrative rights
Local admin from daily accounts, and standing access from administrators where it can be requested instead.
- 3
Take secrets out of code and configuration
Credentials in a repository have no expiry and no audit trail.
- 4
Decide retention, and enforce it automatically
Data you no longer hold cannot be stolen or disclosed.
Stage four — build capability
Only now do the projects that businesses usually want to start with become worth doing: custom software, automation, AI, cloud migration, high availability.
The reason is not caution. It is that each of them is cheaper and more likely to succeed once the foundations exist. Automation needs monitoring or it fails silently. Custom software needs identity and backup. A cloud migration built on two unreconciled directories inherits that problem permanently.
What changes the order
The sequence above is a default, not a rule. Three things legitimately reorder it.
- A dated external requirement — a customer contract, an insurer, a regulator, or a support end-of-life date. Those have deadlines the business does not control.
- An active incident or a near miss. Whatever it exposed moves to the front, and the temptation to fix only the specific instance rather than the class should be resisted.
- A component approaching end of support. That is a known date with a known consequence and it does not wait for a roadmap.
What should not reorder it is enthusiasm for a specific technology, or a supplier's product cycle.
Making a roadmap that survives contact with the year
- Give every item an owner by name. Items owned by a team are owned by nobody.
- Put lifecycle dates in the same calendar as contract renewals, with eighteen months of warning on anything requiring a migration.
- Review quarterly against what actually happened, not annually against what was planned.
- Write down what was deliberately not done and why. Otherwise the same decision gets re-litigated every year.
- Keep one document. A roadmap split across a slide deck, a spreadsheet and somebody's notes is three roadmaps that disagree.
What should a growing business do first in IT?
Build an asset inventory that maintains itself and consolidate to one authoritative directory with one account per person, then add MFA on everything reachable from outside and verify a backup by actually restoring it. These come first because almost every later control silently depends on them — patching depends on knowing what exists, endpoint coverage depends on having something to compare the console against, and offboarding depends on there being one place to revoke.
Why does the order matter more than the list?
Because most items depend on other items, so attempting them in the wrong sequence means doing several of them twice. Segmentation requires knowing what talks to what; least privilege requires individual rather than shared accounts; any audit answer requires the foundations to be true rather than assumed. A reasonable list executed in a poor order produces a programme that stalls repeatedly for reasons nobody attributes to sequencing.
When should a business start on automation, custom software or AI?
After the foundations and the operability work, not before. This is not caution — each becomes cheaper and more likely to succeed once the prerequisites exist. Automation without monitoring fails silently; custom software without identity and backup inherits both problems; a cloud migration built on two unreconciled directories carries that flaw permanently. Starting at this stage because it is the interesting one is the most common sequencing error.
What legitimately changes the order?
Three things: a dated external requirement such as a customer contract, insurer or regulator; an active incident or near miss, where the class of problem it exposed moves forward rather than only the specific instance; and a component approaching end of support, which is a known date with a known consequence. Enthusiasm for a technology and a supplier's product cycle are not among them.
How often should an IT roadmap be reviewed?
Quarterly, against what actually happened rather than annually against what was planned. Every item should have an owner by name, since items owned by a team are owned by nobody, and decisions to deliberately not do something should be recorded with the reason — otherwise the same debate is repeated every year. Lifecycle dates belong in the same calendar as contract renewals, with eighteen months of warning on anything that requires a migration.
Sources and further reading
- A cybersecurity checklist for growing businesses— the control set stages one to three are drawn from
- Infrastructure planning for growing businesses— the estate-level planning this sequences
- MFA strategy for business— stage one, and the highest value per unit of cost
- Access control and offboarding— the directory and process work in stages one and two
- Server health monitoring— the alerts that belong in stage two
- Network segmentation for growing businesses— stage three, and why it comes after visibility
- The technology stack for a growing business— what each stage is actually built from
- IT for banking and financial services— the same stages, with an evidence standard applied
- IT for healthcare providers— where access control has to be strict and permissive at once
- IT for education providers— peak load, annual identity churn, and a network under test from inside
- Replacing infrastructure without stopping the business— how to execute the migrations this roadmap schedules
- CIS Implementation Groups— the published prioritisation this sequence is consistent with
Services This Relates To
Written by KYCONNECTS Engineering. Client names are withheld under confidentiality.