A cloud service can remove work such as operating physical servers or maintaining a building's power supply. It does not automatically decide who should access your records, which information should be uploaded or how your team will recover from an accidental deletion. Shared responsibility means understanding the boundary for the particular service you use.
Begin with the service, not the slogan
AWS describes security responsibilities divided between the provider and customer, with the customer's work depending on the selected service. Running your own application on a rented virtual server involves different duties from using a finished hosted document application. The word “cloud” alone does not tell you who patches which component or configures which control.
Write the name and purpose of each service. Then read its official security and operational documentation. Ask specific questions: who manages the operating system, who configures access, what logs are available and what recovery options are included? A provider's general security statement is useful context, but the service-level details determine your actual maintenance work.
Give identities a clear owner
Your team still decides who joins, which roles they receive and when access ends. Use individual accounts and appropriate roles where supported. Keep administrator access limited to the people who need it, with supported additional sign-in protection. A hosted system can have strong infrastructure controls while an unnecessary administrator account remains active for months.
For a small organisation, a simple joiner-and-leaver checklist can be enough to start. On joining, identify the services required for the role. On leaving, remove access, transfer ownership of shared work and check any integrations the person managed. Record the authorised owner rather than leaving the organisation dependent on a private email address.
Own the information and configuration
Decide what belongs in the service and who may share it. Review default settings before adding sensitive material. A storage location intended for public website images should not become a convenient place for private customer documents. Organising services by purpose makes those distinctions visible and reduces surprising consequences from a single permissive setting.
Keep a brief change record for important configurations. If you alter access or connect a new application, record why, who approved the change and how to undo it. The record does not need to reproduce every technical detail. Its value is helping the next person understand the intended behaviour and identify a setting that no longer matches it.
Plan recovery and service continuity
Check which data can be exported, which backups or versions the service provides and how restoration works. Test a small recovery task. A provider keeping its service available is a different question from recovering a document your team deleted. Understand the retention periods and any limitations before relying on them as your only recovery route.
For important workflows, identify a temporary alternative if the service or your account becomes unavailable. A booking team might need a protected export of upcoming appointments and a documented contact route. An editorial team might need a copy of drafts and publication instructions. Build the alternative around the task you must continue, not a vague promise to “switch providers.”
Review the map together
Create a short table with responsibility, owner and evidence. Examples include account recovery owned by the operations lead, data exports owned by the project manager and platform patching covered by the provider's documentation. If a line has no owner or uncertain evidence, investigate it instead of assuming the responsibility sits somewhere else.
Review the map when you change services, add integrations or change staff. Include billing ownership because a failed payment can interrupt an otherwise healthy service. The useful outcome is a division of work that your team can describe: what the provider handles, what you configure and what you must still test yourself.
Sources and further reading
This original guide was prepared with AI assistance. Examples are illustrative. The edition date is an assigned date in this 2026 catalogue. See our editorial policy and report a correction.