Document and Share a Supplier Customer Shared Responsibility Model
Create, write down and share a shared responsibility model so suppliers and customers each know which security tasks they own.
Plain language
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.
Framework
ASD Information Security Manual (ISM)
Control effect
Preventative
Classifications
NC, OS, P, S, TS
ISM last updated
June 2026
Control Stack last updated
18 June 2026
E8 maturity levels
N/A
Official control statement
A shared responsibility model is created, documented and shared between suppliers and their customers to articulate the security responsibilities of each party.
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.
Operational notes
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.
Implementation tips
- 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.
Audit / evidence tips
- Askthe documented shared responsibility model for a sample of suppliersGoodis a written document (or a clearly labelled section of the contract) that names both parties and lists who is responsible for each security task
- Look athow the responsibilities are split and check there are no unassigned itemsGoodmodel leaves no security task marked as 'unknown' or owned by neither party
- Askwhether the model was shared with and acknowledged by both the supplier and the customerGoodshows evidence such as a countersigned contract, an email acceptance or a supplier-published model that the customer has formally accepted
- Look atthe dates and version of the model and compare them to when the service or contract last changedGoodshows the model is current and was reviewed when the arrangement changed
- Askhow staff who perform the customer-side tasks were told about their responsibilitiesGoodpoints to the model being communicated to the relevant teams, not just filed away with the contract
Cross-framework mappings
How ISM-1569 relates to controls across ISO/IEC 27001, ISO/IEC 42001, Essential Eight, and ASD ISM.
ISO 27001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(3)expand_less | ||
| Annex A 5.19 | ISM-1569 requires a documented and shared shared-responsibility model between supplier and customer to clearly assign security responsibi... | |
| Annex A 5.20 | ISM-1569 requires a documented and shared shared-responsibility model so both parties understand their respective security duties | |
| Annex A 6.5 | Annex A 6.5 requires ongoing information security obligations to be defined, enforced and communicated when employment terminates or role... | |
ISO 42001
| Control | Notes | Details |
|---|---|---|
sync_altPartially overlaps(1)expand_less | ||
| Annex A 10.2 | Annex A 10.2 requires the organisation to allocate responsibilities across the AI system life cycle between the organisation and external... | |
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.