What is an unpatched system?¶

An unpatched system is missing one or more available software or security updates. That status may increase vulnerability exposure, but it does not by itself prove negligence, vulnerability to a particular exploit or actual compromise.

An update may be delayed for testing or availability reasons, superseded by another package, incompatible with the deployed version or accompanied by a separate mitigation.

Patch question	Evidence to preserve
Which update was absent?	package/update inventory and management records
When was it available?	vendor release and organisational patch records
Was the affected component in use?	version, service and configuration evidence
Was it reachable?	firewall, gateway and exposure history
Was the weakness actually used?	incident requests, processes, files, accounts or data access

Identify the precise missing protection¶

Establish which update was absent, when it became available, the component and vulnerability it addressed, and whether that component was enabled and reachable. Check the organisation's patch process, maintenance records, risk decisions and alternative controls.

Patch state can differ between clustered hosts or replicated services. Tie evidence to the exact affected asset rather than applying one result across the environment. Preserve native update logs and management records because later remediation changes the state.

Keep patch status and incident cause separate¶

A missing patch can explain why a weakness remained available, but exploitation still requires matching requests and effects. A fully patched system may be compromised through stolen credentials, configuration weakness, supplier access or a newer flaw.

Avoid turning incident reconstruction into a general compliance judgment unless policy or duty is relevant to the case. The immediate evidential question is how patch state changed the opportunity, what other controls existed and whether the weakness was used.