ASD ISM 0407 Maintaining a secure lifetime access record for each human user
What it says
A secure record is maintained for the life of systems and their resources that covers the following for each human user: - their unique identifier - their signed agreement to abide by system usage policies - who authorised their access - when their access was granted - the level of access they were granted - when their access, and their level of access, was last reviewed - when their level of access was changed, and to what extent (if applicable) - when their access was withdrawn (if applicable).
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep a tamper-resistant record, for as long as each system and its resources exist, of who was given access, by whom, at what level, when it was reviewed or changed, and when it was removed.
Every system needs a reliable history of who has been allowed to use it. This control requires organisations to keep a secure record for each human user that covers their unique identifier, their signed agreement to follow the system's usage policies, who authorised their access, when it was granted, what level of access they received, when their access and access level were last reviewed, when their level of access was changed and by how much, and when their access was withdrawn. The record has to be kept for the life of the system and its resources, not just while the user is active. Why it matters: without this history, nobody can confidently answer basic questions such as "who approved this person's administrator rights?" or "did this contractor's access get removed when they left?". Access decisions become impossible to verify, stale or excessive privileges go unnoticed, and investigators cannot reconstruct who could have touched a system at the time of an incident. Keeping the record secure matters too, because an attacker or insider who can alter or delete it can hide unauthorised access or fabricate a legitimate-looking approval trail.
Free. Save your status, tasks and notes.
Why it matters
If no secure, lifetime record of user access is kept, the organisation cannot demonstrate that access was properly authorised, reviewed or withdrawn. Orphaned and over-privileged accounts persist unnoticed, incident investigations lack the evidence needed to establish who had access and when, and disputes about whether a user agreed to usage policies cannot be settled. If the record exists but is not protected, it can be altered to conceal unauthorised access, undermining every audit and investigation that relies on it.
How to implement
System owners define the mandatory fields for every access record (unique identifier, signed usage agreement, approver, grant date, access level, last review date, access level changes and withdrawal date) and configure the identity and access management or ticketing tool so that a request cannot be completed with any of these fields empty.
The onboarding team captures each user's signed agreement to the system usage policy before access is provisioned and links the signed copy, or a reference to it, to the user's access record so the two are never separated.
Access administrators record approvals by name and date inside the access workflow rather than in email, so that who authorised access and when it was granted are stored with the record itself.
Access reviewers log the outcome and date of every periodic access review against each user's record, and administrators record the date and extent of any change in access level, including reductions, so the review and change history is complete.
The security team protects the record by restricting write access to a small set of administrators, enabling change logging on the record store, backing it up, and setting a retention rule that keeps entries for the life of the system and its resources rather than deleting them when a user leaves.
Keep it running
In practice the access record is usually a combination of an identity and access management system, a ticketing or workflow tool that captures approvals, and signed usage agreements held in HR or a document repository. Whatever the mix, the organisation needs to be able to produce, for any named user on any system, a single coherent history covering all eight elements in the statement.
Day-to-day, each access request should generate an entry that captures the requester's unique identifier, the approver, the date, and the level of access granted. Periodic access reviews should be logged against each user with the review date, and any change in access level should be recorded with the date and the nature of the change. Deprovisioning must record the withdrawal date rather than simply deleting the account, because deletion erases the very history the control is meant to preserve.
Two points are easy to overlook. First, the record must be retained for the life of the system and its resources, so retention rules that purge user data after a user leaves will breach the control. Second, the record must be secure: write access should be tightly restricted, changes should be logged, and backups should protect it from loss or tampering.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the complete access record of a sample of current and former users across several systems, including at least one privileged user and one user who has left.
Look at
Check that each record contains all eight elements: unique identifier, signed usage agreement, approver, grant date, access level, last review date, access level changes with their extent, and withdrawal date where applicable.
Good evidence
Every sampled record is complete, the entries are consistent with each other, and former users show a recorded withdrawal date rather than a missing record.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the signed system usage agreements for the sampled users and the method used to link them to access records.
Look at
Confirm the agreement is signed by the user, dated on or before the access grant date, and traceable to the user's unique identifier.
Good evidence
Each user's signed agreement is readily located from their access record and predates their access being granted.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the retention policy and configuration for the access record store, and for records relating to a system resource that was decommissioned or a user who left some time ago.
Look at
Check that retention covers the life of the system and its resources and that older records are still retrievable rather than purged.
Good evidence
Records for long-departed users and older resources remain available and intact, and the retention setting explicitly ties the record to the system's lifetime.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the access control settings, change logs and backup arrangements for the record store itself.
Look at
Look at who can create, modify or delete record entries, whether changes are logged with the actor and time, and whether backups exist and are protected.
Good evidence
Write access is limited to a small named group, every modification is logged and attributable, and backups are in place and tested.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of the most recent access review cycle and any access level changes made in the last year.
Look at
Trace a sample of review outcomes and changes back to the individual user records to confirm the review date, the change date and the extent of the change were recorded.
Good evidence
Review dates and access level changes appear in the user records, match the review and change tickets, and the recorded extent of each change matches what is actually configured on the system.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 6 mappings
This control partially meets A.5.15.
ISM-0407 requires maintaining a secure lifetime access record for each human user, including who authorised access, what level was granted, and when it was reviewed/changed/removed. ISO/IEC 27001:2022 Annex A 5.15 requires the organisation to establish and implement access control rules and procedures for physical and logical access based on business and security requirements. ISM-0407 provides concrete evidentiary recordkeeping that supports and evidences those procedures, but Annex A 5.15 is broader because it covers the overall access control policy framework beyond record retention for individual users.
This control partially meets A.5.16.
Annex A 5.16 requires the identity lifecycle to be managed, which relies on maintaining evidence of identity creation, authorisation, changes, reviews and withdrawal. ISM-0407 supports this by mandating a secure record for each user over the life of the system, capturing authorisation, access grants, reviews, changes and withdrawal dates. ISM-0407 is primarily a recordkeeping/audit trail requirement, while Annex A 5.16 is the overarching lifecycle management expectation that those records enable and evidence.
This control partially meets A.5.18.
ISM-0407 requires a secure, tamper-resistant record for each human user covering the full access lifecycle (authorisation, grant date, access level, reviews, changes, and withdrawal) for the lifetime of systems/resources. ISO/IEC 27001:2022 Annex A 5.18 requires access rights to be provisioned, reviewed, modified and removed in accordance with access control policy, which implies maintaining records/evidence of those actions. ISM-0407 is more specific and prescriptive about exactly what must be recorded and retained for life, whereas Annex A 5.18 is broader and policy/process-oriented and does not mandate the same record content or lifetime retention.
This control partially overlaps A.5.33.
Annex A 5.33 requires records to be protected from loss, destruction, falsification, unauthorised access and unauthorised release. ISM-0407 overlaps by mandating a secure, lifecycle record of user access authorisations and reviews, which underpins accountability and helps prevent or investigate unauthorised access to records. ISM-0407 focuses on access administration evidence, while Annex A 5.33 is broader and includes protecting the records' integrity/availability and preventing unauthorised release.
This control partially overlaps A.8.2.
ISM-0407 requires a secure, life-of-system record for each user covering authorisation, access grant dates, access level, reviews, changes and withdrawal. Annex A 8.2 relies on strong governance of privileged access allocation and use, and secure access records provide the audit trail and accountability needed to demonstrate privileged access was properly approved, reviewed and adjusted. Annex A 8.2 focuses on restricting and managing privileged rights, whereas ISM-0407 focuses on maintaining evidence of access decisions for all users (not only privileged users).
This control supports A.5.1.
ISM-0407 requires keeping user access records including a signed agreement to abide by system usage policies and details of who authorised access. Annex A 5.1 requires information security policies to be communicated and acknowledged, and ISM-0407's signed agreement record is a concrete mechanism to evidence that acknowledgement. Annex A 5.1 is broader policy governance, while ISM-0407 is operational recordkeeping for user access.
ASD Essential Eight: 1 mapping
This control depends on E8-RA-ML1.1.
E8-RA-ML1.1 requires organisations to validate privileged access requests when first requested. ISM-0407 supports this by requiring secure records showing who authorised access, when it was granted, and the level of access, which provides evidence that the initial validation/approval occurred. ISM-0407 is primarily about recordkeeping across the access lifecycle, while E8-RA-ML1.1 is the control activity of validating the request itself.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.