Scope note: This article supports business planning but does not replace a current security, regulatory or legal assessment for the specific system.
Start with the current system, not the assumed design
A legacy system security assessment is a structured examination of an older application's defences, carried out before you rely on it further, integrate it with newer systems, or hand it to a different supplier. It is not a full penetration test, nor is it a code-quality review. Its purpose is to establish what risks the system carries right now and whether those risks are acceptable for your intended use.
The assessment typically covers four areas: how users prove their identity and what they are allowed to do; how data is stored, transmitted and protected; what the underlying infrastructure and dependencies look like; and whether the system produces any evidence of suspicious activity. Each of these areas reveals different kinds of exposure.
| Assessment area | What to establish | Evidence to retain |
|---|---|---|
| Authentication and access controls | Older systems often store passwords using outdated hashing methods, lack multi-factor authentication entirely, or apply permissions in ways that no longer match the business's current roles. | Access records, test evidence, unresolved risks and the person accountable for remediation. |
| Data handling and encryption | Legacy applications may transmit data over unencrypted connections, store sensitive fields in plain text, or hold personal data far longer than necessary. | Validated samples, reconciliation results, a named data owner and logged exceptions. |
| Infrastructure and dependencies | The server operating system, the database version, the programming language runtime and any third-party libraries all form part of the attack surface. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
| Logging and monitoring | Many legacy systems were built without considering how an incident would be investigated. | A named owner, current-state evidence, unresolved questions and a dated decision record. |
Authentication and access controls
Older systems often store passwords using outdated hashing methods, lack multi-factor authentication entirely, or apply permissions in ways that no longer match the business's current roles. An assessment checks whether a user who left the organisation three years ago can still log in, whether an ordinary user can reach admin functions, and whether session handling leaves accounts open after a browser is closed.
Data handling and encryption
Legacy applications may transmit data over unencrypted connections, store sensitive fields in plain text, or hold personal data far longer than necessary. An assessment identifies where personal data, payment details or commercially sensitive information sits, whether it is encrypted at rest and in transit, and whether the system's data-retention practices align with current UK data-protection requirements.
Infrastructure and dependencies
The server operating system, the database version, the programming language runtime and any third-party libraries all form part of the attack surface. An assessment checks whether these components still receive security patches from their maintainers, whether known vulnerabilities exist in the specific versions in use, and whether the hosting environment itself is properly configured.
Logging and monitoring
Many legacy systems were built without considering how an incident would be investigated. An assessment looks at whether the system records who did what and when, whether those logs are protected from tampering, and whether anyone is actually reviewing them. A system that cannot produce an audit trail creates a separate category of risk, particularly if regulatory compliance is a factor.
Before a modernisation project
Starting a rebuild or integration without understanding the current system's security posture is a common error. If the legacy application holds personal data that will be migrated, you need to know whether that data has already been exposed. If the old system will continue running alongside the new one during a transition period, its weaknesses become the new system's weaknesses until the cutover is complete.
After a supplier takeover
When you gain control of a system previously managed by another company, you inherit its security decisions. An assessment at this stage establishes a baseline: what you have, what state it is in, and what needs immediate attention before your own team takes responsibility. This is distinct from a documentation review, which tells you how the system is supposed to work; the security assessment tells you how it actually behaves under scrutiny.
During compliance or due-diligence processes
If your organisation is subject to regulatory requirements, or if you are acquiring a business that relies on a legacy system, an independent security assessment provides evidence of the current risk level. It does not guarantee compliance, but it gives your legal, compliance and information-security teams the information they need to make informed decisions.
After a suspected incident
If there is reason to believe a legacy system has been accessed without authorisation, an assessment shifts from proactive to investigative. The focus moves to log analysis, access-pattern review and identification of any changes to data or configuration. This scenario requires careful handling to preserve evidence and should involve specialists with forensic experience.
Scoping the assessment realistically
A useful assessment requires access to the live environment or a faithful replica, sample data that reflects real usage patterns, and a clear statement of which user roles and processes are in scope. Without these, the result will be generic and unactionable. You should expect to provide access credentials, network diagrams, a list of integrations and a description of the data classifications in use. The assessor should be able to explain what they will test, what they will not test, and why.
Treating the assessment as a one-off exercise
Security is not a property you acquire and keep. A legacy system that passes an assessment today will accumulate new risks as vulnerabilities are discovered in its dependencies, as user accounts change, and as the business context shifts. The assessment should produce a prioritised list of findings with a clear indication of which items are time-sensitive and which can be addressed as part of planned maintenance.
Confusing security assessment with code review
A code review examines how the application was written. A security assessment examines how it behaves. For legacy systems, the behaviour is what matters: a perfectly structured codebase can still expose data if the server is misconfigured, and a messy codebase can be adequately protected by strong network controls. If you need both, say so explicitly in the scope, but do not assume one substitutes for the other.
Skipping dependency analysis
The application code may be sound while the framework it runs on has a publicly known critical vulnerability. This is one of the most common findings in legacy assessments. Any worthwhile assessment will include a software bill of materials or equivalent dependency map, cross-referenced against current vulnerability databases. If a supplier proposes an assessment without mentioning dependencies, question the scope.
Not testing with real user roles
An assessment carried out entirely with administrator access will miss permission flaws that affect ordinary users. The testing should reflect the actual role structure of the business, including any temporary or restricted-access roles. Ask the assessor which roles they plan to test and whether they will attempt privilege escalation from each.
Ignoring the hosting layer
If the legacy system runs on infrastructure you do not fully control, or on a server that also hosts other applications, the assessment must account for that shared environment. A vulnerability in a neighbouring application or an overly permissive network rule can undermine everything the application itself does correctly.
Key checks to request
- Authentication testing with each distinct user role, including any service or API accounts
- Verification that session tokens expire and cannot be reused
- Confirmation that sensitive data is encrypted at rest, with the specific encryption methods identified
- A dependency inventory cross-referenced against current vulnerability databases
- Testing of any file-upload mechanisms for unrestricted execution
- Review of log coverage, protection and retention
- Network-level checks on open ports, unnecessary services and inter-system trust relationships
Limitations to accept
No assessment can guarantee that a system is free of vulnerabilities. It can only identify risks within the scope tested, during the period tested. A legacy system that cannot be safely tested in a live-like environment will produce findings with lower confidence. A system with no test environment at all presents a practical limitation that should be documented and factored into your modernisation planning.
Keep the decision traceable
Security assessments also do not fix anything. The value comes entirely from what happens afterwards: which findings you accept, which you mitigate, and which make continued operation untenable. That decision is a business one, not a technical one, and it should be made with the assessment report in one hand and your risk appetite in the other.