A 12 month IT roadmap is a plan for the technology work your business needs over the coming year. It shows what needs changing, which business goal each project serves, what it may cost and who will deliver it. For a small UK business without an IT department, a carefully maintained spreadsheet is usually enough.
Begin with what the business wants to achieve: protect booking income, take on staff or cut time spent on administration. Then check the technology you already run. Tackle risks that could seriously interrupt work before spending on improvements that can wait, and review the plan every quarter.
What a 12 month IT roadmap includes
Each project row should name its business goal, the problem being addressed and the proposed change. Include priority, estimated total cost, when payments are due, dependencies, available people, an owner and a target date. Add a completion check and a way back for changes that could disrupt operations.
- Goal and project: What the business wants and how this change helps.
- Reason and priority: Evidence of the problem and the consequence of delaying it.
- Cost and timing: Estimated total, confirmed quotations and payments expected each quarter.
- Delivery: Dependencies, responsible person, supplier availability and target month.
- Acceptance: A practical test of the result and a safe recovery route where needed.
- Status: Planned, approved, in progress, completed or postponed.
Keep the roadmap readable by an office manager. Store detailed technical instructions separately. The spreadsheet names weak spots and suppliers, so restrict access to people who need it and retain version history to see what changed. Name one person to update it and someone with authority to change priorities; they may be the same person.
How detailed should a small-business roadmap be?
Include enough to approve and track a project, without pretending you know every technical task a year ahead. The next quarter needs a defined scope, available people and a credible estimate. Later work can remain provisional until requirements and supplier dates are confirmed.
Before approving a replacement file service, for example, identify the records it must hold and who needs them. State what counts as a successful transfer, and how the original service can be restored if the change fails.
Step 1: list what you run today
Use the business goals to decide which systems matter first. The ICO's records management guidance recommends an information asset register showing where records are kept. A minimum viable IT asset register provides more detail on organising the inventory.
- Equipment: Record computers and network equipment, including anything staff use away from the office. Compare the list with physical devices and purchasing records.
- Services: List email and file storage alongside the applications staff need to work. Use supplier invoices and account pages to find subscriptions nobody has mentioned.
- Account control: Record the authorised administrator and how another person can regain access. Verify the arrangement without putting passwords in the roadmap.
- Dates: Note when agreements renew and when software support ends. Match the entries against supplier terms or the manufacturer's current support page.
- Records: Locate the business information each system holds. Ask the people using it to confirm which copy is current and where it can be recovered.
Do not overlook the website. Identify who controls the domain and DNS, when certificates need renewing, who supports hosting and who applies CMS or plugin updates. Test where website forms and booking emails arrive, then confirm who can access the analytics account.
For each essential service, confirm its business owner and who can contact the supplier. If a key account belongs to a former employee, record an access-recovery task rather than attempting an unplanned change. A short set of usable system notes can hold the contacts and recovery procedures outside the roadmap.
Step 2: find the risks
Look for failures that could stop essential work or expose information. The NCSC's small-business incident guidance recommends identifying critical systems and considering the impact of losing them. Record what you know, what still needs checking and who will investigate it.
- Recovery: Ask how much recent data the business could afford to lose and how long each essential service could be unavailable. Compare those limits with the actual backup schedule and supplier recovery arrangements.
- Backup copies: Confirm that at least one copy is kept separate from everyday systems, under a login the everyday administrator account cannot use to delete it, so an incident affecting the main environment cannot easily affect it. Examine job records and the age of available copies.
- Restore tests: Restore a sample using test data where possible, to a separate location with controlled access. Open the result and remove the test copy securely afterwards. Restoring one file proves only that file; recovering an entire service requires a separate, larger test with the relevant supplier.
- Accounts: Review access to important online services and former staff accounts. Before changing authentication, verify another authorised administrator or the provider's recovery method, then test on a limited account.
- Updates: Check both manufacturer support and whether available security updates have actually been installed. Name who applies updates. For unsupported software, record interim restrictions or isolation agreed with a specialist while replacement is arranged.
The NCSC's backup guidance covers recoverable copies, while its incident recovery guidance advises keeping backups offline or separated. A successful backup notification alone is not a restore test.
For sign-in, the NCSC recommends passkeys for important accounts where supported. If that account still allows a password, the NCSC says it must remain strong and unique, with two-step verification. If a pilot sign-in fails, stop changes to other accounts and use the documented recovery path.
An active compromise is an incident, not a future roadmap project. Follow the incident plan, arrange containment with qualified help immediately and preserve evidence for investigation. Avoid uncoordinated shutdowns or account changes; isolating systems or resetting passwords is often right, but as part of the containment the responder directs, as the NCSC's incident guidance linked above explains. If personal data is involved, decide quickly whether the breach must be reported: the ICO's guide to personal data breaches says a reportable breach goes to the ICO within 72 hours of becoming aware of it, where feasible.
Privacy and suppliers need separate checks
The ICO's DPIA guidance says an assessment is required before personal-data processing likely to create a high risk to individuals. Separately, the ICO's controller-processor guidance says a written binding agreement is required when a supplier processes personal information on your behalf, whether or not a DPIA is required.
Confirm the supplier's role and the contract before approving a replacement. When leaving a service, take an export and check it holds what must move, comparing record counts and attachments, not only that the file opens, before removing access. After the handover is accepted, revoke accounts and API access, and obtain confirmation of the return or deletion of personal data under the agreed terms. Seek data protection advice for uncertain cases.
Step 3: rank the projects
Give each project a short comparison against five questions. What is the risk of leaving it undone? Is there a fixed deadline? What benefit will the business notice? What is the rough cost? Are staff and suppliers available to deliver it? Record the answers in plain words rather than using invented scores.
Start with confirmed serious risks and commitments that cannot move. Then look at improvements with a clear benefit. For a time-saving project, note the current problem before the change: how staff carry out the task and where delays arise. After delivery, repeat the same observation and ask the affected people whether it improved.
Illustrative decision: A made-up office is choosing between testing recovery of its booking records and replacing a meeting-room display. Recovery has a potentially serious consequence if left unchecked; the display has a visible convenience benefit but no fixed deadline. The office schedules the recovery work first, subject to confirming who can perform the test safely. The display stays on the plan.
Where a problem is not understood, commission diagnosis before committing to a replacement. Identify prerequisite work and ask the business decision-maker to approve any risk being deferred. Re-rank when the evidence changes rather than defending the original order.
Step 4: put numbers on it
Estimate the full commitment, not merely the purchase price. Ask suppliers to quote against the same scope, explaining what data transfer and acceptance testing they will provide. Mark unconfirmed amounts clearly so an early guess cannot be mistaken for an approval. The IT procurement guide covers comparing those quotations and approving the order.
- One-off charges: Include equipment, installation and specialist work. Compare written quotations on scope as well as total.
- Continuing charges: Record subscriptions and support fees, including when each payment starts and any overlap with the previous provider. Reconcile the entries with invoices.
- Internal effort: Ask the relevant staff how much time they can devote to preparation and training without leaving normal work uncovered.
- Payment calendar: Put renewals and monthly charges into their due quarters. Add supplier milestone payments, so the owner can see cash required in each quarter alongside total cost.
- Approval: Confirm available funds and who can authorise extra spending. Update estimates after new quotes arrive and record the reason for changes.
Consider keeping an existing service where that is safe and meets the business goal, instead of assuming replacement is necessary. Do not cancel it until the new service works, required records are accounted for and the old contract's termination terms have been checked.
Step 5: set owners and dates
Every approved project needs a business owner, a delivery lead and an acceptance check. Before fixing a month, ask staff how many working hours they can realistically provide and get the supplier's available dates in writing. Move the date if those people are unavailable; an empty slot in a calendar is not delivery capacity.
- Responsibility: Name who authorises decisions and who performs the work. Obtain their agreement before recording the date.
- Scope: Record what changes and what stays untouched. Have the delivery lead acknowledge the boundaries.
- Acceptance: Agree a task someone can demonstrate, such as an authorised sign-in or a transferred booking opening correctly. Keep the result with the project record.
- Way back: For disruptive work, confirm a usable backup or export and a rollback procedure before starting. Agree who may stop the change, and at what point going back becomes difficult.
The ICO's change management guidance recommends risk assessment, testing and backups before software changes. That guidance belongs to an audit framework the ICO says is not directly applicable to small businesses, which it points to its advice for small and medium organisations instead. Give another authorised person access to essential contacts and recovery instructions; a library of support handover procedures can help if the owner is away.
A roadmap quarter by quarter
The following is a made-up business example, not client work or a prescribed schedule. Each entry gives a target month, accountable role, dependency and completion check. A business that discovers a problem requiring an immediate response should not wait for the month shown here.
- Quarter 1, January - inventory: Office manager; depends on agreed business goals. Complete when the owner and access route for each essential system have been confirmed.
- Quarter 1, February - backup review: IT supplier; depends on the inventory. Complete when backup coverage and frequency match agreed needs and the required restore tests are recorded.
- Quarter 2, April - account protection: Office manager with supplier; depends on account ownership being confirmed. Complete when approved staff can sign in securely and recovery access has been tested.
- Quarter 3, July - booking email check: Website provider; depends on domain access being verified. Complete when test bookings reach the right mailbox and a failure contact is documented.
- Quarter 3, September - admin workflow pilot: Operations manager; depends on the booking process check. Complete when staff can finish the trial task and compare it with the recorded old process.
- Quarter 4, November - renewal review: Business owner; depends on the updated service inventory. Complete when contract decisions and payment dates for the following year are recorded.
For a migration pilot, keep the former service usable until acceptance. Agree which system is the source of truth during testing and, where possible, freeze changes in the other. Before switching back, reconcile new, changed and deleted records between the two systems, and get the business owner's approval to revert. Have a responsible person resolve duplicates or missing entries against the original records; test ordinary work again before declaring the rollback complete.
How to review and change the plan
Put the quarterly review dates into the calendar now. The named roadmap keeper should update progress and store decisions; only the business owner or another explicitly authorised person should change project priorities. Ask delivery leads for evidence rather than treating installation or invoice payment as completion.
How often should I review my IT roadmap?
A quarterly review is a practical starting point, with shorter check-ins during disruptive work. Reopen the plan after a serious incident or an unavoidable deadline change. Refresh it before the next planning year so that deferred tasks are assessed again rather than copied forward automatically.
- Finished work: Compare each project with its acceptance test and keep anything unverified open.
- New information: Update supplier terms or security findings from their original sources.
- Capacity: Confirm whether booked staff hours and supplier dates still stand. Assign a new owner to any blocker before moving a deadline.
- Costs: Compare invoices with the payment calendar and update future commitments.
- Decisions: Record who moved a project and why, then check its remaining risk at the next review.
Keep version history and limit spreadsheet access. This is an operational plan that names systems and weak points, so it should not be circulated as an unrestricted staff document.
When to bring in outside help
An owner or office manager can prepare the first roadmap. Ask for specialist assessment when recovery cannot be demonstrated, a migration could interrupt booking income or the business cannot judge a security finding. For a major incident, follow the response plan and get incident support immediately rather than treating it as routine project work.
The NCSC's guidance on choosing a managed service provider recommends clarifying security responsibilities and supplier contracts. Ask who controls access, how a failed change is recovered and what evidence you will receive. A larger provider may suit work requiring substantial coverage; a focused review may be enough for a smaller decision.
Start with the next decision
Choose the business goal that matters first, check the system supporting it and give the proposed change an owner. If outside advice would help, you can get help ranking your IT projects. Record the completion test and make a date to review your 12 month IT roadmap.