ASD ISM 2125Independently Log and Analyse All Service Provider System Access
Keep 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.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Detective
Classifications
NC, OS, P, S, TS
ISM last updated
Sept 2026
Control Stack last updated
05 Sept 2026
E8 maturity levels
N/A
Topic
Access to systems by service providers
Official control statement
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.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- AskAsk for the register of service providers with system access and the list of access paths they use.Look atCompare the register against the sources actually being collected by the organisation's logging system, checking that each provider account and connection method appears.GoodEvery 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.
- AskAsk for the permission configuration of the log repository and the accounts held by the service provider.Look atCheck whether any provider account, or any system the provider administers, holds rights that could modify, purge or shorten retention of the logs.GoodLog 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.
- AskAsk for a sample of raw log entries covering a recent service provider session.Look atConfirm 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.GoodThe 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.
- AskAsk for the documented analysis procedure, including the defined time frame for review and the detection rules applied to provider activity.Look atCheck 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.GoodA written procedure names responsible reviewers, states a concrete review interval or alerting target, and includes rules tied to the provider's approved access baseline.
- AskAsk for evidence of analysis actually being performed over the past few months, such as review records, alert histories and tickets raised.Look atCheck 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.GoodDated 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.
Cross-framework mappings
How ISM-2125 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
layersPartially meets(1)expand_less | ||
| Annex A 8.15 | ISM-2125 requires a specific logging and monitoring outcome: independently log all service provider access such that the provider cannot ... | |
handshakeSupports(4)expand_less | ||
| Annex A 5.21 | ISM-2125 requires the organisation to independently log and analyse service provider access in a tamper-resistant manner to identify unau... | |
| Annex A 5.22 | ISM-2125 requires the organisation to maintain independent, tamper-proof logs of service provider access and to analyse them promptly to ... | |
| Annex A 5.25 | ISM-2125 requires timely analysis of independently held service provider access logs to detect anomalous, unexpected or unauthorised acti... | |
| Annex A 5.28 | ISM-2125 requires the organisation to independently log service provider access in a way that the service provider cannot modify or delet... | |
E8
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(4)expand_less | ||
| 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-r... | |
| E8-AH-ML2.14 | ISM-2125 requires independent logging of service provider access and timely analysis to detect anomalous, unexpected or unauthorised acti... | |
| E8-AH-ML3.4 | ISM-2125 requires independent logging of service provider access and timely analysis to detect anomalous, unexpected or unauthorised acti... | |
| E8-AC-ML3.5 | ISM-2125 requires that service provider access is independently logged and analysed in a timely manner to detect anomalous or unauthorise... | |
These mappings show relationships between controls across frameworks. They do not imply full equivalence or certification.
Related ASD ISM controls in Procurement and outsourcing
See all Guidelines for procurement and outsourcing controls, or browse the full ASD ISM library.