ASD ISM 1569 Document and share a supplier customer shared responsibility model
What it says
A shared responsibility model is created, documented and shared between suppliers and their customers to articulate the security responsibilities of each party.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishCreate, write down and share a shared responsibility model so suppliers and customers each know which security tasks they own.
When you buy a service from a supplier (for example a cloud platform or a software provider), some of the security work is theirs and some is yours. A shared responsibility model is a simple written agreement that spells out who looks after what, such as who patches the servers, who manages user accounts and who backs up data. This control says that model must be created, written down and shared between the supplier and the customer so there are no gaps where each party assumes the other is handling security.
Free. Save your status, tasks and notes.
Why it matters
If responsibilities are never written down or shared, both the supplier and the customer may assume the other is handling a security task, leaving gaps that attackers can exploit.
How to implement
The business owner or contract manager requests a written shared responsibility model from each supplier before signing, asking the supplier to list exactly which security tasks they handle and which the customer must handle.
The IT manager maps each security responsibility (patching, backups, user access, monitoring, incident response) to either the supplier or your organisation, so every task has a clear owner and nothing falls between the two.
Whoever manages the supplier relationship stores the agreed model in your contract file or supplier register and references it in the service agreement so it is binding, not just a conversation.
The IT manager schedules a review of the model whenever the service changes or the contract renews, because suppliers sometimes shift responsibilities (for example moving from a managed to a self-service tier).
The contract manager shares the relevant parts of the model with the staff who actually do the work, so the people responsible for backups or access reviews know which tasks are now theirs to perform.
Keep it running
Revisit the shared responsibility model at each contract renewal or service change, and keep the agreed version stored with the supplier contract so the split of duties stays clear over time.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
the documented shared responsibility model for a sample of suppliers.
Good evidence
is a written document (or a clearly labelled section of the contract) that names both parties and lists who is responsible for each security task.
- Check 2 of 5What an auditor asks for
Look at
how the responsibilities are split and check there are no unassigned items.
Good evidence
model leaves no security task marked as 'unknown' or owned by neither party.
- Check 3 of 5What an auditor asks for
Ask for
whether the model was shared with and acknowledged by both the supplier and the customer.
Good evidence
shows evidence such as a countersigned contract, an email acceptance or a supplier-published model that the customer has formally accepted.
- Check 4 of 5What an auditor asks for
Look at
the dates and version of the model and compare them to when the service or contract last changed.
Good evidence
shows the model is current and was reviewed when the arrangement changed.
- Check 5 of 5What an auditor asks for
Ask for
how staff who perform the customer-side tasks were told about their responsibilities.
Good evidence
points to the model being communicated to the relevant teams, not just filed away with the contract.
Mappings
Closest match in ISO/IEC 27001: A.5.19, Managing information security in supplier relationships, which partially overlaps with this control.
ISO/IEC 27001: 3 mappings
This control partially overlaps A.5.19.
ISM-1569 requires a documented and shared shared-responsibility model between supplier and customer to clearly assign security responsibilities. ISO/IEC 27001:2022 Annex A 5.19 requires defined processes and procedures to manage information security risks in supplier relationships, which commonly includes clarifying who does what across the engagement. Annex A 5.19 is broader around supplier risk management overall, while ISM-1569 is more specific on mutual documentation and communication of responsibility boundaries.
This control partially overlaps A.5.20.
ISM-1569 requires a documented and shared shared-responsibility model so both parties understand their respective security duties. ISO/IEC 27001:2022 Annex A 5.20 requires agreeing relevant information security requirements with each supplier in supplier agreements, which is a common mechanism to formalise responsibility allocation. Annex A 5.20 focuses on specifying requirements/clauses, whereas ISM-1569 focuses on the explicit responsibility model and its communication between parties (not only contractual requirements).
This control partially overlaps A.6.5.
Annex A 6.5 requires ongoing information security obligations to be defined, enforced and communicated when employment terminates or roles change. ISM-1569 overlaps because a documented shared responsibility model commonly includes continuing obligations after an engagement changes (e.g., confidentiality, return/handling of customer data, and notification responsibilities), which are analogous to post-termination duties. However, ISM-1569 is focused on supplier-customer accountability rather than internal employee offboarding, so it does not fully cover Annex A 6.5's personnel termination/role-change requirement.
ISO/IEC 42001: 1 mapping
This control partially overlaps A.10.2.
Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle between itself and external parties so duties are not left unowned. ISM-1569 directly relates by requiring a documented and shared supplier-customer shared responsibility model that articulates each party's security responsibilities. ISM-1569 is typically scoped to security responsibilities in supplier services, whereas Annex A 10.2 is broader and AI-system-life-cycle oriented (including partners, customers and other third parties beyond suppliers).
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.