Skip to content
System access
ASD ISMISM-1591

ASD ISM 1591 Remove or suspend access when users are detected acting maliciously

What it says

Access to systems and their resources are removed or suspended as soon as practicable when users are detected undertaking malicious activities.

Quoted as published. Everything else on this page is written by Control Stack.

What it means

In plain English

When a user is caught doing something malicious, their access to systems and the resources within them is cut off or frozen without unnecessary delay, so the harm cannot continue.

This control is about what happens in the moments after you discover that a user (an employee, contractor, administrator or any other account holder) is deliberately doing something harmful, such as exfiltrating data, tampering with records, disabling security settings or accessing information they have no business seeing. The requirement is simple: take their access away, or at least suspend it, as soon as it is practical to do so. That covers access to the systems themselves and to the resources inside them, such as files, databases, shared drives, applications and administrative functions. Why it matters is a question of time. Once malicious intent is confirmed, every minute the account stays live is a minute the person can copy more data, cover their tracks, create backdoor accounts or escalate the damage. Detection alone achieves nothing if the account keeps working. The phrase "as soon as practicable" recognises that there may be a short interval needed to confirm what is happening, to coordinate with the incident response lead or HR, or to preserve evidence, but it rules out leaving a known-hostile user with working credentials while paperwork or approvals grind along. The control also deliberately covers both removal and suspension: suspension is often the right first move because it stops the activity immediately while an investigation decides whether the account is permanently removed.

Why it matters

If access is not removed or suspended promptly, a user already known to be acting maliciously can keep operating with valid credentials, extending the data loss, sabotage or fraud well beyond the point of detection. The organisation loses the chance to contain the incident early, evidence may be destroyed by the user, and the delay is difficult to defend to regulators, insurers or affected parties because the threat had already been identified.

How to implement

  1. The security or incident response lead documents a rapid access suspension procedure that names who can authorise and who can execute a suspension, sets an expected time target from detection to action, and lists every system and resource type (directory, cloud consoles, databases, SaaS tools, VPN, privileged accounts) that must be covered.

  2. Identity administrators build and test a repeatable suspension runbook or script that disables the account, revokes active sessions and tokens, resets or blocks credentials, and removes the user from privileged groups across all connected systems in one pass.

  3. The SOC or monitoring team defines a direct escalation route so that any analyst who detects malicious user activity can trigger the suspension procedure immediately, including out of hours, rather than routing it through a general change or approval queue.

  4. System owners maintain a current inventory of which resources each user or role can reach, including local and non-federated accounts, so that when a suspension is needed nothing is missed and the runbook can be applied quickly.

  5. The incident response lead runs a periodic tabletop or live drill that simulates detection of a malicious user and times how long it takes to suspend all of their access, then fixes any system or step that slowed the response.

Keep it running

Day to day, this control lives at the intersection of security monitoring, the service desk and identity administration. The people who detect malicious activity (a SOC analyst, a system owner, a manager who notices something) need a clear, fast path to the people who can actually disable or suspend an account, and those people need authority to act without waiting for a lengthy approval chain.

In practice that means having a defined "suspend now" procedure that covers every system where the user holds access, not just the corporate directory. A user may have separate credentials on cloud consoles, databases, SaaS tools, VPNs or privileged access solutions, and suspending only the primary login leaves those doors open. Active sessions and tokens should be terminated as well, because disabling an account does not always end a session that is already running.

Timing decisions should be recorded: when the activity was detected, when suspension was decided, when it was actioned, and who did it. Where a short delay was necessary (for example to preserve evidence or to coordinate with HR for an insider case), note the reason. Suspension is usually reversible, so it is the safe default while the facts are confirmed; permanent removal follows once the investigation concludes.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the procedure that governs removing or suspending a user's access when malicious activity is detected.

    Look at

    Check that it names who can decide and who can act, states an expected timeframe, and covers access to systems and the resources within them rather than just the main login.

    Good evidence

    A short, current procedure that gives named roles clear authority to suspend quickly, with removal following once the case is confirmed.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for records of incidents in the last twelve months where a user was found undertaking malicious activity.

    Look at

    Compare the timestamp of detection with the timestamp when access was suspended or removed, and read any explanation for delays.

    Good evidence

    Suspension happened within minutes or hours of detection, and any longer gap has a documented, reasonable justification such as evidence preservation.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the technical runbook, script or workflow used to carry out a suspension.

    Look at

    Look for steps that disable the account, terminate active sessions and tokens, and cover cloud, SaaS, database, VPN and privileged accounts, not only the central directory.

    Good evidence

    One documented, tested process that reaches every system the user could access and can be executed by the on-call administrator without further approval.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask for evidence that the SOC or monitoring team can escalate a detected malicious user straight to the people who suspend access.

    Look at

    Review the escalation path, contact details and out-of-hours coverage, and check a recent example where it was used.

    Good evidence

    Analysts can reach an authorised administrator at any time and the record shows the path was actually followed during a real or simulated event.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for results of any drill or test of the suspension process.

    Look at

    Look at the measured time from detection to full suspension and at any gaps found, such as a system where access remained active.

    Good evidence

    Drills are run regularly, the time to suspend is measured, and identified gaps have been closed with follow-up actions.

Mappings

Closest match in ISO/IEC 27001: A.5.16, Identity life cycle management, which this control partially meets.

ISO 27001

ISO/IEC 27001: 4 mappings

  • A.5.16Identity life cycle managementPartially meets
  • A.5.18Managing access rights to information assetsPartially meets
  • A.5.26Response to information security incidentsPartially meets
  • A.8.2Management of privileged access rightsPartially overlaps

Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.