ASD ISM 2136 Enforcing risk-based access decisions informed by contextual signals
What it says
Risk-based access decisions, informed by contextual signals, are enforced for access to systems and their resources.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishAccess to systems and their resources is granted, stepped up or denied according to the risk of each request, judged from signals such as the user, device, location and behaviour.
A valid username, password and second factor prove that someone holds the right credentials. They do not prove that the request is safe. A login from a brand-new device in a country the user has never visited, at three in the morning, a few seconds after a login from the office, looks very different from the same user's normal Monday sign-in, even though both present the same credentials. This control requires that access to systems and their resources is decided on risk, not just on credentials, and that those decisions are enforced rather than merely reported. The decision is informed by contextual signals: things like who is asking, what device they are on and whether it is managed and healthy, where the request comes from, when it happens, what resource is being requested and how sensitive it is, and whether the pattern of activity matches what is normal for that user. Low-risk requests proceed. Higher-risk requests are challenged with stronger authentication, limited to a reduced level of access, or blocked outright. It matters because most successful intrusions use legitimate credentials that have been phished, guessed, reused or bought. Static access rules treat a stolen credential exactly like the rightful owner. Risk-based decisions give the system a way to notice that something about the request does not fit, and to act on it before the attacker reaches the resource. The statement applies to access to both systems and the resources within them, so the same thinking covers the initial sign-in and the subsequent requests for applications, data and administrative functions.
Free. Save your status, tasks and notes.
Why it matters
Without risk-based access decisions, every request that carries valid credentials is treated identically, regardless of how anomalous it is. An attacker who phishes a password and defeats or bypasses the second factor, hijacks a session token, or uses a compromised device gains the same access as the legitimate user, from anywhere, at any time, to any resource that user can reach. Contextual signals that would have flagged the request (unfamiliar device, impossible travel, unmanaged or non-compliant endpoint, unusual resource) are either not collected or not acted upon, so the intrusion proceeds silently until it is discovered by other means. The organisation also loses the ability to apply stronger protection to sensitive systems and resources without imposing that friction on every routine request, which in practice pushes it towards weaker blanket settings. The likely outcomes are account takeover, lateral movement into higher-value systems, data theft and administrative compromise that could have been challenged or stopped at the point of access.
How to implement
Identity and access owners define the risk model in writing: list the contextual signals available (user identity and role, device identity and compliance state, network location, time, requested resource and its sensitivity, sign-in and behavioural anomalies), describe how they combine into risk levels, and map each level to an enforced outcome (allow, step-up authentication, reduced access, deny).
Platform engineers connect every signal source to the policy engine: enrol endpoints in device management so posture and compliance are reported, integrate identity protection or user and entity behaviour analytics for anomaly detection, and tag systems and resources with sensitivity so the engine knows what is being requested.
Security architects route access to systems and their resources through an enforcement point that can act on the decision, such as the identity provider's conditional access, a zero trust access gateway or an application proxy, rather than relying on individual applications to interpret risk on their own.
Identity administrators build the policies in the engine and deploy them in report-only mode first, review what each policy would have challenged or blocked over a few weeks, adjust thresholds and exceptions, then switch the policies to enforced, applying the strictest outcomes to privileged access and highly sensitive resources.
Security operations and the help desk set up the run-state processes: forward risk decisions and denials to the SIEM with alerting on repeated high-risk events per account, publish a user re-verification path for legitimate blocked access, and schedule a periodic review of policies, signal feed health and exception lists with the policy owner.
Keep it running
Day to day, this control lives in the policy engine of the identity provider, access gateway or zero trust platform that sits in front of systems and their resources. Someone owns the policy set: which signals are collected, how they combine into a risk assessment, and which outcomes (allow, step-up authentication, restricted access, deny) apply at each level, including stricter thresholds for sensitive resources and privileged access.
Signals only work if they are fed. Device posture depends on endpoint management and health attestation reporting into the policy engine; behavioural signals depend on identity and sign-in telemetry; resource sensitivity depends on systems and data being classified and tagged. Operations teams need to watch that these feeds stay connected, because a broken feed quietly turns a risk-based decision into a static one.
Expect tuning. New policies are usually run in report-only mode first to see what they would have blocked, then enforced. False positives (staff travelling, new device rollouts, network changes) generate help desk tickets and need a clear path for users to re-establish trust, such as verifying on a known device, without opening a bypass that an attacker could use. Denied and stepped-up decisions should feed security monitoring, since a burst of high-risk decisions for one account is often the first sign of a credential compromise. Policies and thresholds should be reviewed when new systems or resources are onboarded, when threat intelligence changes, and after any incident where a risky request was allowed.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the documented risk-based access policy or design that describes which contextual signals are used and how they drive access decisions.
Look at
Check that it names concrete signals (user, device state, location, time, resource sensitivity, behaviour), explains how they are combined into risk levels, and states the enforced outcome for each level.
Good evidence
A current, owned document that maps specific signals to specific outcomes such as allow, step-up, restrict or deny, and that covers access to resources within systems as well as initial sign-in.
- Check 2 of 5What an auditor asks for
Ask for
Ask to see the live policy configuration in the identity provider, access gateway or zero trust platform that enforces these decisions.
Look at
Confirm the policies are in enforced mode rather than report-only, that they apply to the in-scope systems and resources, and that stricter rules cover privileged access and sensitive resources.
Good evidence
Enforced policies whose scope matches the documented design, with no broad exclusion groups or legacy authentication paths that let requests bypass the risk assessment.
- Check 3 of 5What an auditor asks for
Ask for
Ask for evidence that the contextual signal feeds are actually connected and healthy, such as device compliance reporting, identity risk detection and resource classification.
Look at
Look at integration status, the proportion of devices reporting posture, and whether risk detections are populating in the console.
Good evidence
All signal sources the design relies on are integrated and reporting for the great majority of users and devices, with a monitoring check that flags when a feed stops.
- Check 4 of 5What an auditor asks for
Ask for
Ask for sign-in and access logs showing decisions over a recent period, including examples that were challenged or denied.
Look at
Look for records that show the signals evaluated, the risk level reached and the outcome applied, and check that high-risk requests were actually stepped up or blocked rather than only logged.
Good evidence
Logs that demonstrate the policy working in practice, with a mix of allowed, challenged and denied requests, and that show the rationale for each decision.
- Check 5 of 5What an auditor asks for
Ask for
Ask how blocked or challenged users are handled and how the policies are reviewed and tuned over time.
Look at
Look at the help desk re-verification procedure, records of policy changes, exception lists with justification and expiry, and any review after incidents or new system onboarding.
Good evidence
A defined re-verification path that does not simply disable the policy, a change history showing periodic tuning, and exceptions that are limited, justified and time-bound.
Mappings
Closest match in ISO/IEC 27001: A.5.15, Access control policies and procedures, which this control partially meets.
ISO/IEC 27001: 4 mappings
This control partially meets A.5.15.
ISM-2136 requires enforcing risk-based access decisions using contextual signals (e.g. user, device, location, behaviour) to grant, step up, or deny access. Annex A 5.15 requires the organisation to establish and implement access control policies and procedures for physical and logical access based on business and security requirements. Annex A 5.15 provides the governance and rules framework within which a risk-based/conditional access approach in ISM-2136 can be defined and enforced, but it does not specifically mandate contextual, per-request risk evaluation.
This control partially meets A.8.3.
ISM-2136 requires dynamic enforcement of access decisions driven by contextual risk signals at the time of each access request. Annex A 8.3 requires restricting access to information and assets in accordance with an established access control policy. Annex A 8.3 underpins the baseline restriction model (who can access what), while ISM-2136 adds conditional, context-aware decisioning and step-up/deny behaviour that is not explicit in Annex A 8.3.
This control partially overlaps A.5.18.
ISM-2136 requires enforcing access decisions per request based on contextual signals and risk, including granting, stepping up, or denying access. Annex A 5.18 requires provisioning, reviewing, modifying, and removing access rights according to access control policy and rules. Both influence whether access is granted, but Annex A 5.18 focuses on administrative access-rights lifecycle, while ISM-2136 focuses on runtime, context-aware enforcement even for correctly provisioned users.
This control depends on A.5.17.
ISM-2136 requires enforcing risk-based access decisions that may step up authentication or deny access based on contextual risk. Annex A 5.17 requires controlled allocation and management of authentication information (e.g. credentials and secrets) through a defined process. ISM-2136 relies on strong, well-managed authentication information to ensure that any risk-based decisions (including step-up challenges) are meaningful and resistant to credential compromise, but Annex A 5.17 does not address contextual signal-driven decisioning.
ASD Essential Eight: 1 mapping
This control partially overlaps E8-RA-ML1.1.
ISM-2136 requires enforcing risk-based access decisions using contextual signals to allow, step up, or deny access to systems and resources. E8-RA-ML1.1 requires validating privileged access requests when first requested, which is a risk-based gate at the point of requesting elevated access. Both address making access decisions based on risk, but ISM-2136 is broader and continuous (per-request, context-driven), whereas E8-RA-ML1.1 is focused on initial approval/validation for privileged access rather than ongoing conditional access enforcement.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.