Skip to content
Procurement and outsourcing
ASD ISMISM-1576

ASD ISM 1576 Treating unauthorised service provider access as a reportable incident

What it says

If an organisation's systems are accessed or administered by a service provider in an unauthorised manner, it is treated as a cyber security incident and the organisation is immediately notified.

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

What it means

In plain English

Any unauthorised access to, or administration of, your systems by a service provider is handled as a cyber security incident, and the provider tells you straight away.

Service providers such as managed service providers, cloud operators and outsourced administrators often hold privileged access to an organisation's systems. That access is granted for defined purposes and within defined limits. This control says that if a provider (or someone acting through the provider) accesses or administers your systems outside those limits, the event is not treated as a minor contractual slip or a support ticket. It is treated as a cyber security incident, and the organisation must be notified immediately. This matters because unauthorised provider activity looks almost identical to a real compromise. A provider's engineer using credentials for an unapproved task, a provider's account being misused by a former employee, or an attacker who has compromised the provider's environment and is riding its legitimate access path all produce the same result: someone administering your systems without your authorisation. If the organisation is not told promptly, it cannot contain the activity, assess what was touched, preserve evidence or meet its own incident reporting obligations. Immediate notification ensures the organisation, not just the provider, decides how serious the event is and what to do about it.

Why it matters

Without this control, unauthorised access or administration by a service provider can go unreported or be quietly resolved on the provider's side. The organisation loses the chance to contain the activity while it is happening, may never learn which systems or data were touched, and cannot meet its own incident response and reporting timelines. A compromised or misbehaving provider account then becomes a hidden path into the environment that looks legitimate to everyone except the organisation that should have been told.

How to implement

  1. Contract and vendor management owners write the requirement into each service provider agreement: any access to, or administration of, the organisation's systems in an unauthorised manner is a cyber security incident and the provider must notify the organisation immediately, with the notification channel, contact and timeframe spelled out.

  2. The security lead defines with each provider what "authorised" access and administration means in practice (approved accounts, approved tasks, approved change windows and approval records) so that both sides can recognise when activity falls outside those bounds.

  3. The incident response manager adds a specific incident category for unauthorised service provider access in the organisation's incident response plan, with triage, containment and evidence-preservation steps that begin as soon as a provider notification is received.

  4. The security operations team sets up and maintains a dedicated notification path (for example a monitored incident mailbox or on-call phone number) that providers use for immediate reporting, and keeps the provider-side and organisation-side contact lists current.

  5. The vendor relationship owner runs a notification exercise with each key provider, walking a simulated unauthorised administration event through the provider's escalation and the organisation's incident process to confirm the report arrives promptly and lands with the right people.

Keep it running

Day to day, this control lives in two places: the service provider's incident handling and the organisation's own incident response process. The provider needs to recognise when access or administration falls outside what was authorised and raise it as an incident straight away, rather than logging it as a change or a support note. The organisation needs a named contact point and an agreed channel for that notification, so "immediately" means minutes, not the next scheduled service review.

On receipt of a notification, the organisation's incident response team should open its own incident record, capture what the provider reports (who, what, when, which systems), and run its normal triage and containment steps. Because the trigger is unauthorised access rather than confirmed harm, the incident should be opened even if the provider believes the activity was benign. Contracts and service agreements are the usual place to make the obligation explicit, and periodic service reviews are a good point to confirm the notification path still works and the contacts are current.

Evidence and audit

  1. Check 1 of 5What an auditor asks for

    Ask for

    Ask for the current agreements or service schedules with providers that access or administer the organisation's systems.

    Look at

    Look for a clause stating that unauthorised access or administration is treated as a cyber security incident and that the organisation is notified immediately, including how and to whom.

    Good evidence

    Every in-scope provider agreement contains the obligation with a defined notification channel and contact, not just a general security or confidentiality clause.

  2. Check 2 of 5What an auditor asks for

    Ask for

    Ask for the organisation's incident response plan or procedures.

    Look at

    Check whether unauthorised service provider access is recognised as an incident type and whether there are steps for handling a provider's notification.

    Good evidence

    The plan explicitly covers provider-originated incidents, names who receives the notification and describes the triage and containment actions that follow.

  3. Check 3 of 5What an auditor asks for

    Ask for

    Ask for the incident register or ticketing records for the review period.

    Look at

    Look for any incidents raised because a provider accessed or administered systems in an unauthorised manner, and compare the provider's notification time with the time the activity occurred.

    Good evidence

    Any such events appear as incidents in the organisation's own records, opened promptly after the activity, with the provider's notification attached.

  4. Check 4 of 5What an auditor asks for

    Ask for

    Ask how each provider defines what access and administration is authorised for the organisation's systems.

    Look at

    Look for documented approved accounts, tasks and change approvals that would let the provider recognise an unauthorised event.

    Good evidence

    There is a clear, agreed baseline of authorised activity so that both the provider and the organisation can tell when a boundary has been crossed.

  5. Check 5 of 5What an auditor asks for

    Ask for

    Ask for evidence that the notification path has been tested or used.

    Look at

    Look at exercise records, contact list reviews or real notifications showing the message reached the organisation's incident contact without delay.

    Good evidence

    A recent exercise or real event shows the provider notifying the organisation immediately and the organisation opening an incident in response.

Mappings

Closest match in ISO/IEC 27001: A.5.19, Managing information security in supplier relationships, which partially overlaps with this control.

ISO 27001

ISO/IEC 27001: 3 mappings

  • A.5.19Managing information security in supplier relationshipsPartially overlaps
  • A.5.24Information security incident management planning and preparationPartially overlaps
  • A.5.20Integrating security clauses in supplier agreementsDepends on

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