ASD ISM 2125 Independently log and analyse all service provider system access
What it says
All access to an organisation's systems by a service provider is independently logged by the organisation in a manner that the service provider cannot modify or delete, and analysed in a timely manner to detect any anomalous, unexpected or unauthorised activity.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep your own tamper-proof record of everything a service provider does in your systems, and review it promptly to catch anything odd, unexpected or unauthorised.
When an outside service provider (such as a managed service provider, software vendor or outsourced support team) is given access to your systems, you are trusting people you do not directly manage. This control says the organisation must keep its own record of every instance of that access, stored somewhere the service provider cannot alter or erase, and must actually look at those records quickly enough to spot activity that is anomalous, unexpected or unauthorised. The two halves matter equally. Independent, tamper-proof logging means the evidence of what a provider did is under your control, not theirs. If you rely on the provider's own logs, a careless or malicious operator, or an attacker who has compromised the provider, could quietly remove the trail. Timely analysis means the logs are used for detection rather than sitting untouched until after an incident. Service provider accounts are attractive targets precisely because they often carry broad privileges and are used across many customers, so the ability to notice misuse early is a real-world safeguard against supply chain compromise, insider misuse and undetected data theft.
Free. Save your status, tasks and notes.
Why it matters
If service provider access is not independently logged, or the logs can be changed or deleted by the provider, the organisation has no reliable way to know what was done in its systems under those accounts. Misuse by provider staff, or by an attacker who has compromised the provider, can continue undetected, and any subsequent investigation depends on evidence the provider controls. If the logs exist but are not analysed in a timely manner, anomalous or unauthorised activity may be discovered only after damage has occurred, when the window for containment has already closed.
How to implement
Have the security or infrastructure team route every service provider access path (remote access gateways, jump hosts, privileged access management sessions, administrative consoles and API activity) into a central log repository that the organisation owns and administers, so no provider access occurs without a record captured by the organisation.
Have platform administrators configure that repository so service provider accounts and provider-managed systems have no write, modify or delete permissions on the logs, using organisation-controlled credentials, write-once or append-only storage, and integrity protections such as hashing or signed forwarding.
Have the access management owner maintain a register of service provider accounts and connection methods, and add a mandatory step to provider onboarding, scope change and offboarding procedures that verifies logging coverage for each account before access is enabled.
Have the security operations team build detection rules and alerts that compare provider activity against its approved baseline (agreed staff, systems, time windows and actions), flagging access outside scope, outside hours, from unexpected sources, or involving unrecognised accounts or unusual commands.
Have the security operations lead set a documented time frame for analysis (for example, automated alerting in near real time plus a daily human review of provider sessions), assign named reviewers, and link confirmed anomalous, unexpected or unauthorised activity directly into the incident response process.
Keep it running
Day to day, this control depends on three things staying true: every path a service provider uses to reach your systems is feeding the organisation's log store, the provider has no write or delete rights to that store, and someone (or something) is reviewing the records within an agreed time frame.
Keep an inventory of service provider accounts and access paths (remote access gateways, privileged access tools, administrative consoles, API credentials) and confirm each one is captured whenever a provider is onboarded, changes scope or is offboarded. Logs should flow to a repository owned and administered by the organisation, with retention and integrity protections that the provider cannot influence. Define what "timely" means for your context (for example, automated alerts within minutes and human review within the same business day) and record who is responsible. Tune detection rules around the provider's expected pattern: approved maintenance windows, named staff, agreed systems and typical actions. Anything outside that pattern, such as access at unusual hours, from unexpected locations, to systems outside scope, or using unrecognised accounts, should raise a review. Feed confirmed anomalies into your incident response process and periodically check that log collection has not silently stopped.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the register of service providers with system access and the list of access paths they use.
Look at
Compare the register against the sources actually being collected by the organisation's logging system, checking that each provider account and connection method appears.
Good evidence
Every provider account and access path in the register maps to a log source the organisation collects, with no gaps for out-of-band methods such as vendor support tools or API keys.
- Check 2 of 5What an auditor asks for
Ask for
Ask for the permission configuration of the log repository and the accounts held by the service provider.
Look at
Check whether any provider account, or any system the provider administers, holds rights that could modify, purge or shorten retention of the logs.
Good evidence
Log storage is administered solely by organisation staff, provider accounts have read-only or no access, and integrity protections such as append-only storage or signed forwarding are in place.
- Check 3 of 5What an auditor asks for
Ask for
Ask for a sample of raw log entries covering a recent service provider session.
Look at
Confirm the entries were generated and stored by the organisation rather than supplied by the provider, and that they identify who accessed what, when and from where.
Good evidence
The organisation can produce its own contemporaneous record of the session without needing anything from the provider, and the record is detailed enough to reconstruct the activity.
- Check 4 of 5What an auditor asks for
Ask for
Ask for the documented analysis procedure, including the defined time frame for review and the detection rules applied to provider activity.
Look at
Check that the rules address anomalous, unexpected and unauthorised activity, for example access outside agreed hours, scope or sources, and that the time frame is specific rather than vague.
Good evidence
A written procedure names responsible reviewers, states a concrete review interval or alerting target, and includes rules tied to the provider's approved access baseline.
- Check 5 of 5What an auditor asks for
Ask for
Ask for evidence of analysis actually being performed over the past few months, such as review records, alert histories and tickets raised.
Look at
Check that reviews occurred within the stated time frame, that alerts on provider activity were triaged, and that any genuine anomalies were escalated through incident response.
Good evidence
Dated review records and alert triage notes show consistent, timely analysis, with at least one example of an anomaly being investigated and closed out with a documented outcome.
Mappings
Closest match in ISO/IEC 27001: A.5.22, Monitoring and managing supplier services, which this control partially meets.
ISO/IEC 27001: 3 mappings
This control partially meets A.5.22.
ISM-2125 requires the organisation to maintain independent, tamper-proof logs of service provider access and to analyse them promptly to detect unauthorised activity. Annex A 5.22 focuses on monitoring, reviewing and managing supplier service delivery and changes in supplier security practices. ISM-2125 supports Annex A 5.22 by providing concrete, auditable telemetry and detection evidence to monitor supplier behaviour in operational environments, but Annex A 5.22 also covers broader supplier governance beyond access logging.
This control partially meets A.8.15.
ISM-2125 requires a specific logging and monitoring outcome: independently log all service provider access such that the provider cannot alter logs, and analyse them promptly for suspicious activity. Annex A 8.15 requires organisations to produce, store, protect and analyse logs for relevant activities and events more generally across the environment. ISM-2125 is a more specific instance of Annex A 8.15 focused on supplier access and independence from the service provider, while Annex A 8.15 covers broader event categories and does not explicitly require independence from a third party.
This control supports A.5.21.
ISM-2125 requires the organisation to independently log and analyse service provider access in a tamper-resistant manner to identify unauthorised activity. Annex A 5.21 requires processes and procedures to manage information security risks in the ICT supply chain. ISM-2125 supports Annex A 5.21 by providing an operational control that reduces and detects supplier-borne risk (especially privileged/remote access risk), but Annex A 5.21 is broader and includes many other supply chain risk treatments beyond logging and monitoring.
ASD Essential Eight: 4 mappings
This control partially overlaps E8-AC-ML3.5.
ISM-2125 requires that service provider access is independently logged and analysed in a timely manner to detect anomalous or unauthorised activity. E8-AC-ML3.5 relates because timely analysis of workstation logs can detect suspicious actions performed by service provider accounts or remote support tools on endpoints. ISM-2125 adds requirements for independence and tamper-resistance against the service provider and is scoped to service provider access, while E8-AC-ML3.5 is scoped to all workstation activity regardless of who performs it.
This control partially overlaps E8-AH-ML2.13.
ISM-2125 requires that all service provider access to an organisation's systems is independently logged by the organisation in a tamper-resistant way and analysed promptly for anomalous or unauthorised activity. E8-AH-ML2.13 aligns with the tamper-resistance portion by requiring event logs be protected from unauthorised modification or deletion, which supports the 'service provider cannot modify or delete' requirement. However, ISM-2125 is narrower in focus on service provider access and adds the requirement for independent organisational logging and timely analysis, which E8-AH-ML2.13 does not explicitly cover.
This control partially overlaps E8-AH-ML2.14.
ISM-2125 requires independent logging of service provider access and timely analysis to detect anomalous, unexpected or unauthorised activity. E8-AH-ML2.14 relates by requiring timely analysis of logs (specifically for internet-facing servers), which would help detect suspicious service-provider activity if it occurs on those servers. ISM-2125 is broader regarding log independence/tamper resistance and applies to all service provider access (not only internet-facing servers), while E8-AH-ML2.14 is broader in that it is not limited to service providers.
This control partially overlaps E8-AH-ML3.4.
ISM-2125 requires independent logging of service provider access and timely analysis to detect anomalous, unexpected or unauthorised activity. E8-AH-ML3.4 relates by requiring timely analysis of event logs from non-internet-facing servers, which may include systems accessed by service providers for administration. ISM-2125 additionally mandates that logging is controlled by the organisation and cannot be altered by the service provider, and it covers service provider access across systems, not only non-internet-facing servers.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.