ASD ISM 1643 Maintain detailed software version and patch records
What it says
Software registers contain versions and patch histories of applications, drivers, operating systems and firmware.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep a record of software versions and update histories for system security.
To keep your computer systems secure, it's crucial to know what software you're using and to track its updates. If you don't keep an eye on software versions and make sure they're up-to-date, you might miss patches that fix security problems, leaving your system vulnerable to cyber attacks.
Free. Save your status, tasks and notes.
Why it matters
Failure to track software versions and patch histories can lead to missed security updates, exposing systems to exploitable vulnerabilities and potential breaches.
How to implement
The IT manager should create a software inventory: Make a complete list of all the software, including applications, drivers, operating systems, and firmware, that your business uses.
Use a simple spreadsheet to record the name, version, and installation date of each piece of software.
System administrators should regularly check for updates: Set a fixed schedule, like once a week, to review if there are any available updates or patches for the software listed in the inventory.
You can do this by visiting the official websites of the software vendors or setting up automatic notifications.
The IT team should document every update: When you apply updates or patches, write down what was updated, the date it happened, and any changes made.
Add this information to your software inventory spreadsheet so you have a clear record of security improvements.
Assign a dedicated person for software management: Choose someone responsible for maintaining the software inventory and tracking updates.
This could be an IT technician or a manager who understands the systems well enough to update and check the list regularly.
Consider using a software management tool: If you're struggling to keep track by hand, look into simple tools or software that can help automate the update tracking process.
These tools can notify you when updates are available and help apply them efficiently.
Keep it running
Regularly update and verify your software inventory to quickly identify outdated versions, ensuring timely patch deployments to mitigate security risks.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
The software inventory list: Request to see the document or record that logs all software versions in use. Look to ensure every software is listed with its version and installation date.
Good evidence
Is a comprehensive list that covers all critical systems with no significant omissions.
- Check 2 of 5What an auditor asks for
Ask for
A recent update log: Request to view records of the most recent updates to software.
Look at
Detailed entries that include the date and specifics of what was updated.
Good evidence
Includes recent entries that show regular updating activities.
- Check 3 of 5What an auditor asks for
Ask for
To see software management assignments: Request documentation that identifies who is responsible for managing software updates.
Look at
Names and roles clearly documented.
Good evidence
Is a clear organisational chart or assignment list showing dedicated personnel for this task.
- Check 4 of 5What an auditor asks for
Ask for
To inspect a tool or method in use for managing updates: Request a demonstration of any tools or methods used for tracking software versions and updates. Look to verify the functionality of the tool or method in capturing and alerting for updates.
Good evidence
Is a live demonstration showing current data and notifications.
- Check 5 of 5What an auditor asks for
Ask for
About the review schedule for updates: Request to see the schedule or calendar used for reviewing software updates.
Look at
A regular, consistent cycle that aligns with the organisation's security policy.
Good evidence
Is a documented schedule showing consistent past activities and future plans.
Mappings
Closest match in ISO/IEC 42001: A.4.4, Document the tooling resources used for AI systems, which partially overlaps with this control.
ISO/IEC 27001: 1 mapping
This control supports A.8.8.
ISM-1643 requires maintaining registers of software versions and patch histories across applications, drivers, operating systems and firmware. This supports ISO/IEC 27001:2022 Annex A 8.8 by improving the organisation's ability to obtain vulnerability information, evaluate exposure, and decide appropriate remediation based on accurate version/patch state. Annex A 8.8 is broader vulnerability management, while ISM-1643 is a specific recordkeeping practice that strengthens exposure evaluation and assurance.
ISO/IEC 42001: 2 mappings
This control partially overlaps A.4.4.
Annex A 4.4 requires documented information about tooling resources used by an AI system to support resource identification within the AIMS. ISM-1643 strengthens this by requiring software registers to include versions and patch histories, which are important attributes of AI tooling (e.g. framework versions, inference servers, data processing tools) and support traceability and reproducibility. ISM-1643 is focused on patch/version recordkeeping for general software, while Annex A 4.4 is focused on the AI system's tooling set (including non-installed or external tools such as managed services, MLOps platforms, and evaluation tooling).
This control partially overlaps A.4.5.
Annex A 4.5 requires the organisation to document the system and computing resources utilised for an AI system. ISM-1643 strengthens the documentation quality of those resources by requiring software registers to include versions and patch histories for applications, drivers, operating systems and firmware used in the computing environment. ISM-1643 is a depth requirement for software register content across the organisation, while Annex A 4.5 is broader across system/compute resources but requires AI-system-specific scoping and association.
ASD Essential Eight: 6 mappings
This control supports E8-PA-ML1.9.
E8-PA-ML1.9 requires organisations to remove software that is no longer vendor-supported. ISM-1643 supports this by maintaining software versions and patch histories in registers, which enables an organisation to determine which instances need to be removed. E8-PA-ML1.9 is an outcome, while ISM-1643 provides the necessary recordkeeping.
This control supports E8-PA-ML2.2.
E8-PA-ML2.2 requires patches/mitigations for non-critical applications to be applied within one month. ISM-1643 supports E8-PA-ML2.2 by requiring software registers to capture versions and patch histories, which helps evidence patch currency and identify lagging applications. ISM-1643 focuses on record-keeping and traceability, whereas E8-PA-ML2.2 is an implementation timeframe requirement.
This control supports E8-PA-ML3.2.
E8-PA-ML3.2 needs organisations to patch specified applications within two weeks for non-critical vulnerabilities. ISM-1643 enables this by requiring records of software versions and patch histories, allowing organisations to track and evidence compliance with E8-PA-ML3.2.
This control supports E8-PO-ML1.5.
ISM-1643 requires maintaining detailed records of operating system versions and patch histories in software registers. This supports E8-PO-ML1.5 by allowing validation that critical patches for internet-facing operating systems and network devices were applied within 48 hours. E8-PO-ML1.5 drives urgent patching actions, while ISM-1643 provides the recordkeeping needed to demonstrate compliance and identify gaps.
This control supports E8-PO-ML1.8.
E8-PO-ML1.8 requires the replacement of unsupported operating systems. ISM-1643 supports this through software registers to log OS versions, aiding in identifying end-of-support systems and planning replacements. ISM-1643 deals with visibility and record-keeping; E8-PO-ML1.8 targets the action of replacement.
This control supports E8-PO-ML3.3.
ISM-1643 requires software registers to record operating system versions and patch histories. This supports E8-PO-ML3.3 by enabling organisations to verify and audit that critical patches for non-internet-facing operating systems were applied within 48 hours of release. E8-PO-ML3.3 is about patch deployment SLAs, whereas ISM-1643 is about maintaining authoritative patch history records.
ASD Essentials for enterprise IT: 2 mappings
- IT.IDE-01.1Use an approved inventory with automated discovery of new and changed assetsPartially overlaps
This control partially overlaps IT.IDE-01.1.
IT.IDE-01.1 requires an approved asset inventory mechanism with automated discovery of new and changed physical and non-physical assets; ISM-1643 sets what software registers record, the versions and patch histories of applications, drivers, operating systems and firmware.
- IT.IDE-01.2Keep current records of infrastructure, software, identities, credentials and dataPartially overlaps
This control partially overlaps IT.IDE-01.2.
IT.IDE-01.2 requires current records of infrastructure, operating systems, applications, identities, credentials and data assets; ISM-1643 adds detail, requiring software registers to hold versions and patch histories of applications, drivers, operating systems and firmware.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.