ASD ISM 0407Maintaining a Secure Lifetime Access Record for Each Human User
Official control statement
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.
In plain English
Keep 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.
What this means in practice
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.
Framework
ASD Information Security Manual (ISM)
Control effect (Control Stack)
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
29 Sept 2026
E8 maturity levels
N/A
Guideline
Guidelines for system accessTopic
Recording authorisation for personnel to access systems
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk 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 atCheck 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.GoodEvery sampled record is complete, the entries are consistent with each other, and former users show a recorded withdrawal date rather than a missing record.
- AskAsk for the signed system usage agreements for the sampled users and the method used to link them to access records.Look atConfirm the agreement is signed by the user, dated on or before the access grant date, and traceable to the user's unique identifier.GoodEach user's signed agreement is readily located from their access record and predates their access being granted.
- AskAsk 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 atCheck that retention covers the life of the system and its resources and that older records are still retrievable rather than purged.GoodRecords for long-departed users and older resources remain available and intact, and the retention setting explicitly ties the record to the system's lifetime.
- AskAsk for the access control settings, change logs and backup arrangements for the record store itself.Look atLook 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.GoodWrite access is limited to a small named group, every modification is logged and attributable, and backups are in place and tested.
- AskAsk for evidence of the most recent access review cycle and any access level changes made in the last year.Look atTrace 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.GoodReview 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.
Cross-framework mappings
How ISM-0407 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(3)expand_less | ||
| Annex A 5.15 | ISM-0407 requires maintaining a secure lifetime access record for each human user, including who authorised access, what level was grante... | |
| Annex A 5.16 | Annex A 5.16 requires the identity lifecycle to be managed, which relies on maintaining evidence of identity creation, authorisation, cha... | |
| Annex A 5.18 | ISM-0407 requires a secure, tamper-resistant record for each human user covering the full access lifecycle (authorisation, grant date, ac... | |
sync_altPartially overlaps(2)expand_less | ||
| Annex A 5.33 | Annex A 5.33 requires records to be protected from loss, destruction, falsification, unauthorised access and unauthorised release | |
| Annex A 8.2 | ISM-0407 requires a secure, life-of-system record for each user covering authorisation, access grant dates, access level, reviews, change... | |
handshakeSupports(1)expand_less | ||
| Annex A 5.1 | ISM-0407 requires keeping user access records including a signed agreement to abide by system usage policies and details of who authorise... | |
E8
| Control | Notes | Details |
|---|---|---|
extensionDepends on(1)expand_less | ||
| E8-RA-ML1.1 | E8-RA-ML1.1 requires organisations to validate privileged access requests when first requested | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in System access
See all Guidelines for system access controls, or browse the full ASD ISM library.