ASD ISM 2012 Enforced screen lock with full re-authentication after inactivity
What it says
Systems are configured with a screen lock that: - activates after a maximum of 15 minutes of human user inactivity, or when manually activated - conceals all content on the screen - ensures that the screen does not enter a power saving state before the screen lock is activated - requires re-authentication by human users using all authentication factors to unlock the system - denies human users the ability to disable the screen locking mechanism.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishSystems lock within 15 minutes of inactivity (or on demand), hide everything on screen, stay awake until locked, need all authentication factors to unlock, and cannot be switched off by users.
When someone walks away from a logged-in computer, anyone nearby can read what is on the screen or use the session as if they were that person. A screen lock closes that window. This control sets out exactly how the lock must behave rather than leaving it to individual choice. Five things must all be true. The lock must kick in after no more than 15 minutes without keyboard or mouse activity, and the user must also be able to trigger it manually the moment they step away. Once locked, nothing on the screen may remain visible (no preview of the desktop, no notification text, no document titles). The screen must not drop into a power-saving or sleep state before the lock has actually engaged, because a dark screen that wakes straight back into an open session gives a false sense of safety. Unlocking must require the user to authenticate again with every factor they use to log on, not just a password when they normally also use a token or biometric. Finally, users must not be able to turn the lock off, lengthen the timeout, or otherwise bypass it. This matters because unattended, unlocked sessions are one of the simplest ways for a visitor, contractor, cleaner or disgruntled colleague to read sensitive information or act under someone else's identity, with the audit trail pointing at the legitimate user.
Free. Save your status, tasks and notes.
Why it matters
Without an enforced, correctly configured screen lock, an unattended system stays open to anyone who can physically reach it. Sensitive information on screen can be read or photographed, and a passer-by can send email, change data or install software under the logged-in user's account, leaving that user accountable for actions they did not take. If the timeout is too long, the screen only dims instead of locking, the lock shows screen content, or users can disable it, the protection is unreliable and the system falls short of the ISM requirement.
How to implement
System administrators configure a central policy (group policy, MDM or configuration management) that sets the screen lock inactivity timeout to 15 minutes or less and applies it to every system used by human users.
System administrators enable a manual lock option (for example a keyboard shortcut or menu item) and advise staff to lock their screen whenever they step away.
Desktop engineers configure the lock screen to conceal all content by disabling lock-screen notifications, message previews, window thumbnails and any 'peek' behaviour.
Desktop engineers set the display sleep and power-saving timers to a value equal to or greater than the screen lock timeout so the screen cannot enter a power saving state before the lock activates.
Identity and access administrators configure unlock so that it prompts for every authentication factor used at logon, and enforce the lock settings as non-editable so users cannot disable or weaken the screen locking mechanism.
Keep it running
In practice this is delivered through centrally managed configuration (for example group policy, MDM profiles or configuration management) applied to every system in scope, including workstations, laptops, servers accessed interactively and any shared or kiosk-style devices used by human users.
Day to day, the settings to watch are the inactivity timeout (15 minutes or less), the "require authentication on resume" behaviour, and the display sleep timer, which must be set to a value equal to or longer than the lock timeout so the screen never sleeps before it locks. Lock-screen notifications and previews should be turned off so that no content is shown while locked.
Where multi-factor authentication is used for logon, confirm that the unlock prompt also demands the second factor rather than falling back to password only. Check that the relevant settings are enforced (greyed out or overwritten on next policy refresh) so users cannot change them. Configuration drift is common after operating system upgrades, new device builds or new policy layers, so periodic re-checking of a sample of systems is worthwhile.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the central policy or configuration profile that governs screen locking on in-scope systems.
Look at
Look at the inactivity timeout value and whether the policy is set to enforced rather than a user-changeable default.
Good evidence
Good looks like a timeout of 15 minutes or less that is locked down so users cannot alter or disable it.
- Check 2 of 5What an auditor asks for
Ask for
Ask for a demonstration or screenshot of a locked system.
Look at
Look at whether any desktop content, notifications, message previews or document titles remain visible while locked.
Good evidence
Good looks like a lock screen that shows nothing from the user's session and offers a manual lock option that works.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the power management and display sleep settings applied to the same systems.
Look at
Look at the display sleep timer compared with the screen lock timeout.
Good evidence
Good looks like a display sleep timer equal to or longer than the lock timeout, so the screen locks before it can power down.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the authentication configuration used when unlocking a system.
Look at
Look at whether unlock requires the same factors as logon, particularly on systems where multi-factor authentication is used.
Good evidence
Good looks like an unlock prompt that demands all authentication factors, with no password-only fallback.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of compliance checking, such as a configuration report or a sample of systems tested.
Look at
Look at whether the sample covers different device types and whether any systems deviated from the policy.
Good evidence
Good looks like recent results showing all sampled systems meet every element of the control, with any drift corrected.
Mappings
Closest match in ISO/IEC 27001: A.7.7, Clear desk and clear screen policies, which this control partially meets.
ISO/IEC 27001: 2 mappings
This control partially meets A.7.7.
ISM-2012 requires systems to enforce a screen lock after a maximum of 15 minutes inactivity (or on manual activation), conceal screen content, prevent power saving before lock, require full re-authentication using all factors, and prevent users disabling the lock. ISO/IEC 27001:2022 Annex A 7.7 requires clear screen rules to be defined and appropriately enforced, which commonly includes locking sessions when unattended. ISM-2012 is a prescriptive technical implementation of one key part of Annex A 7.7 (clear screen/session locking), whereas Annex A 7.7 is broader and also covers behavioural/physical practices and non-technical aspects (e.g., papers and removable media via clear desk).
This control partially overlaps A.8.5.
ISM-2012 requires re-authentication using all authentication factors to unlock a locked screen and prevents users disabling the locking mechanism. Annex A 8.5 requires secure authentication technologies and procedures to be implemented based on access restrictions and access control policy. They overlap where ISM-2012 mandates a specific authentication procedure for session unlock, while Annex A 8.5 is broader across all authentication scenarios and does not prescribe inactivity timeouts or screen concealment.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.