ASD ISM 1638 Outsourced cloud service register recording eight required details
What it says
An outsourced cloud service register contains the following for each outsourced cloud service: - cloud service provider's name - cloud service's name - purpose for using the cloud service - sensitivity or classification of data involved - due date for the next security control assessment of the cloud service - contractual arrangements for the cloud service - organisational point of contact for the cloud service - 24/7 contact details for the cloud service provider.
Quoted as published. Everything else on this page is written by Control Stack.
What it means
In plain EnglishKeep one register that records, for every outsourced cloud service, who provides it, why it is used, what data it holds, when it is next assessed, its contract, and who to call.
Most organisations rely on cloud services run by someone else, and it is easy to lose track of them. This control asks you to keep a single register, and for each outsourced cloud service to record eight specific things: the provider's name, the service's name, why you use it, how sensitive or classified the data in it is, when the next security control assessment is due, what the contractual arrangements are, who inside your organisation owns the relationship, and how to reach the provider 24 hours a day, 7 days a week. It matters because you cannot protect, assess or respond to what you do not know about. Without the register, sensitive data can sit in a service nobody remembers signing up for, assessments quietly lapse, contracts renew or expire unnoticed, and when an incident happens at 2 am nobody knows who owns the service or how to reach the provider. The register turns a scattered set of subscriptions into a known, managed list.
Free. Save your status, tasks and notes.
Why it matters
Without a complete register, the organisation can lose sight of which cloud services hold sensitive or classified data, miss security control assessment due dates, and be unable to find contract terms or the right internal owner when a decision is needed. During an incident or outage, missing 24/7 provider contact details and an unclear internal point of contact delay containment and recovery, increasing the chance of data compromise, prolonged disruption and contractual or regulatory exposure.
How to implement
The cyber security or IT governance team creates a single outsourced cloud service register (a spreadsheet, GRC tool or CMDB module) with one column for each of the eight required fields: provider name, service name, purpose, data sensitivity or classification, next security control assessment due date, contractual arrangements, organisational point of contact, and 24/7 provider contact details.
Service owners and procurement staff populate the register by working through existing contracts, invoices, subscription records and single sign-on application lists to identify every outsourced cloud service currently in use, then complete all eight fields for each one.
The data owner for each service records the sensitivity or classification of the data it holds by checking what information is stored or processed and applying the organisation's classification scheme, updating the entry whenever the service starts handling different data.
Procurement or contract management staff link each register entry to its contractual arrangements (contract reference, term, renewal date, key security obligations) and confirm the provider's 24/7 contact details from the contract or support agreement, re-verifying them at each renewal.
The register owner sets calendar reminders for each service's next security control assessment due date and makes updating the register a mandatory step in the onboarding, change and decommissioning process for cloud services, so new services are added and the internal point of contact is reassigned when staff change roles.
Keep it running
In practice the register is a living document rather than a one-off inventory. Each of the eight fields needs an entry for every outsourced cloud service, so gaps show up when a new service is onboarded or an existing one changes hands.
Day to day this means adding a row when a new cloud service is approved, updating the internal point of contact when staff move roles, refreshing the provider's 24/7 contact details when the provider changes its support arrangements, and moving the assessment due date forward each time a security control assessment is completed. Contract renewals, variations and terminations should flow through to the contractual arrangements field, and any change in what the service is used for should trigger a check of the recorded purpose and data sensitivity or classification.
It helps to review the register on a set cycle so that stale entries, decommissioned services and approaching assessment due dates are caught early rather than discovered during an incident or audit.
Evidence and audit
- Check 1 of 5What an auditor asks for
Ask for
Ask for the current outsourced cloud service register.
Look at
Check that every entry has all eight fields completed: provider name, service name, purpose, data sensitivity or classification, next assessment due date, contractual arrangements, organisational point of contact and 24/7 provider contact details.
Good evidence
A single register with no blank fields, a visible last-updated date and a named owner responsible for maintaining it.
- Check 2 of 5What an auditor asks for
Ask for
Ask for an independent list of cloud services in use, such as single sign-on application lists, procurement records or recent invoices.
Look at
Compare that list against the register to find outsourced cloud services that are in use but not recorded.
Good evidence
Every cloud service found in the independent source appears in the register, or there is a documented explanation for any exception.
- Check 3 of 5What an auditor asks for
Ask for
Ask for the security control assessment due dates recorded in the register and the most recent assessment reports for a sample of services.
Look at
Confirm that each service has a future due date recorded and that the date reflects when the last assessment was completed.
Good evidence
Due dates are populated for all services, none have passed without an assessment, and the dates line up with the assessment reports.
- Check 4 of 5What an auditor asks for
Ask for
Ask to see the contractual arrangements recorded for a sample of services and the underlying contracts.
Look at
Check that the register entry accurately reflects the contract reference, term and key arrangements, and that the contract is current.
Good evidence
Register entries point to real, current contracts and the details match what the contract actually says.
- Check 5 of 5What an auditor asks for
Ask for
Ask for the organisational point of contact and the provider's 24/7 contact details for a sample of services.
Look at
Confirm the internal contact is a current staff member in a relevant role and that the provider contact details are complete and have been recently verified.
Good evidence
Internal contacts are current employees who confirm they own the service, and provider 24/7 details are complete and match the provider's support agreement.
Mappings
Closest match in ISO/IEC 27001: A.5.23, Cloud service security management, which this control partially meets.
ISO/IEC 27001: 5 mappings
This control partially meets A.5.23.
ISM-1638 requires a specific register for each outsourced cloud service, including why it is used, the sensitivity/classification of data involved, contract arrangements, a next assessment due date, and operational/provider contacts. This is directly aligned to ISO/IEC 27001:2022 Annex A 5.23 because a cloud service register is a common mandatory input to acquisition, ongoing management and governance of cloud services under Australian cloud assurance practices. Annex A 5.23 is broader because it expects end-to-end processes for acquisition, use, management and exit, while ISM-1638 mandates a defined minimum set of register fields rather than the full lifecycle processes.
This control partially overlaps A.5.9.
Annex A 5.9 requires maintaining an inventory of information and associated assets with ownership. ISM-1638 (Maintain a Comprehensive Outsourced Cloud Service Register) overlaps by mandating detailed inventory fields for outsourced cloud services. ISM-1638 is limited to cloud services and adds supplier/contact/security-assessment detail beyond Annex A 5.9's scope.
This control supports A.5.21.
ISM-1638 requires visibility of outsourced cloud services via a register that records the provider, contract arrangements, data classification/sensitivity, and responsible contacts for each service. This supports ISO/IEC 27001:2022 Annex A 5.21 by enabling an organisation to identify and track which ICT supply chain services (cloud) are in use and who owns the relationship, which is necessary to manage and treat supply chain security risks. Annex A 5.21 is broader because it requires defined processes/procedures for managing supply chain risk, beyond maintaining the service register.
This control supports A.5.22.
ISM-1638 requires an organisation to maintain an outsourced cloud service register capturing, per service, the provider, purpose, data sensitivity/classification, next security assessment due date, contract arrangements, and points of contact (including 24/7). This supports ISO/IEC 27001:2022 Annex A 5.22 because the register provides the core supplier inventory, ownership and review cadence inputs needed to monitor, review and manage change in a cloud supplier's security practices and service delivery. Annex A 5.22 is broader because it requires the ongoing monitoring/evaluation activities themselves, whereas ISM-1638 is primarily an artefact/record-keeping requirement.
This control depends on A.5.19.
ISM-1638 requires maintaining a comprehensive register of outsourced cloud services, including purpose, data sensitivity/classification, contractual arrangements, assessment due dates, and contacts. Annex A 5.19 requires defined processes and procedures to manage information security risks in supplier relationships, and a cloud service register is a practical input that supports identifying, tracking, and governing those supplier risks. Annex A 5.19 is broader (covers all suppliers and risk processes), while ISM-1638 is a specific record-keeping/control artefact focused on cloud outsourcing details.
Mappings show how controls relate across frameworks. They do not imply full equivalence or certification.