Score Your Legacy Risk Before It Scores You
A framework for measuring how much risk an ageing system carries, using evidence your team can gather. It gives you a result you can show to people who do not read code.
What The Assessment Delivers
Risk heat map
Each system scored across four areas and placed on one page. It shows where the risk is concentrated and which systems can wait.
Evidence checklist
A list of what to gather for each area, so scores rest on records and measurements and not on opinion.
Phased roadmap
A sequence of work ordered by risk. It starts with containment, then stabilisation, then modernisation in stages.
Why This Belongs On The Board Agenda
Legacy risk is usually discussed as a technical matter. Its effects are not technical. An outage stops revenue. A security gap exposes customer data. A system nobody can change delays every product decision that depends on it.
Boards are asked to approve modernisation budgets without a clear view of what happens if they decline. A scored assessment gives them that view. It states the risk in business terms, shows the evidence and sets out options with different costs.
It also protects the engineering team. When risk is written down and presented, the decision to accept it or act on it is shared with the people who control the budget.
The Scoring Model
Each system is scored in four areas. The highest level found in any area sets the overall level.
- Level 1
Controlled
The system is old, but it is understood and maintained.
- Runs on versions the vendor still supports
- Security patches are applied on a schedule
- More than one person can change and release it
- Backups are tested by restoring them
- Documentation matches how the system works
- Level 2
Elevated
The system works, but the margin for error is shrinking.
- Some components are near the end of vendor support
- Patching is irregular or behind
- Knowledge sits with one or two people
- Releases are rare and need manual steps
- Documentation is partial or out of date
- Level 3
Critical
A failure would be hard to recover from, and change is avoided.
- Core components no longer receive vendor support
- Known vulnerabilities cannot be patched
- Nobody on the team fully understands the system
- Recovery has never been tested
- The team avoids changes for fear of breaking it
The levels describe typical signs. Your own thresholds should reflect how much the business depends on each system.
The Evidence Checklist
What to gather in each area before you score.
Gather a list of operating system, runtime, framework and database versions with their vendor support dates. Add the latest vulnerability scan results, the patch history, a list of who has administrative access, and records of how secrets and credentials are stored. Include any past security incidents and what was done after each.
- Version inventory
- Scan results
- Access list
- Incident records
Gather the incident log with duration and cause for each outage, monitoring and alerting coverage, and backup schedules with the date of the last tested restore. Add the recovery procedure, hardware age and warranty status where the system runs on your own equipment, and the names of people able to respond out of hours.
- Incident log
- Backup and restore tests
- Recovery procedure
- On-call cover
Gather release frequency, the steps in a release and how many are manual, automated test coverage, and the time a typical change takes from request to production. Add the number of people who can make changes, the state of the documentation, and how hard it has been to hire for the technology.
- Release history
- Test coverage
- Lead time for changes
- Key person dependency
Gather the list of regulations and contractual obligations that apply to the system, the most recent audit findings and their status, and data retention and deletion records. Add audit log coverage and a map of where personal or regulated data is stored and who can reach it. Ask your compliance or legal team to confirm which obligations apply.
- Applicable obligations
- Audit findings
- Data map
- Audit logs
From Chaos To Control
- 1Step 1
Inventory
List every system, what it does, who owns it and what depends on it.
- 2Step 2
Gather evidence
Work through the checklist for each system. Note what could not be found, because a gap is a finding too.
- 3Step 3
Score
Assign a level in each of the four areas and place each system on the heat map.
- 4Step 4
Contain
Reduce the most serious risks first with measures that do not need a rebuild, such as tested backups and tighter access.
- 5Step 5
Plan in phases
Order the modernisation work by risk and dependency, with a decision point at the end of each phase.
Get The Framework
Tell us where to send it.
What is included
- The scoring model
- The evidence checklist
- A heat map template
- A roadmap template
Who it is for
- CTOs and heads of engineering
- IT directors
- Risk and audit leads
Want Help Running The Assessment?
Our engineers can gather the evidence with your team and help you present the result.
Related Insights
View All Articles- HiringHow to brief a remote developer so week one is productiveA short checklist covering access, context and a first task that is small enough to finish.
- Project ManagementStaff augmentation or a dedicated team: a decision you can make in ten minutesFour questions about ownership, runway and management time that settle the choice.
- ModernisationSigns your legacy platform has become a business riskWhat to look for in release frequency, incident history and hiring difficulty.