Outsourcing cloud and DevOps work: what to put in the contract

Scope and environments

Start by naming exactly what is covered. “Look after our cloud” is not a scope. List the cloud accounts or subscriptions, the environments (for example development, staging and production), the applications and databases, and the tools such as CI/CD pipelines, monitoring and DNS.

Be equally clear about what is excluded. Application code, end-user devices and third-party services are common grey areas. State who is responsible for each, and how new items are added to the scope.

Access model: your accounts, your control

The cloud accounts should belong to your organisation, and the partner should be given access to them — not the other way round. This keeps your data, billing and history in your hands if the relationship ends.

• Cloud accounts, domains and repositories registered to your organisation.
• Named user accounts for each engineer, with no shared logins.
• Multi-factor authentication required for every user.
• Least-privilege roles, with production access limited to the people who need it.
• Elevated or emergency access logged and reviewed.
• Access reviewed regularly, and revoked promptly when a person leaves the project or the contract ends.

Change management

Agree how changes reach production. Most changes should be made through code — infrastructure as code and pipelines — so they can be reviewed, tested and rolled back. Define which changes need your approval, which can be made under a standing agreement and how emergency changes are handled and reported afterwards.

Ask for a change log that records what changed, when, by whom and why. Agree maintenance windows for planned work, and how much notice you will get.

Monitoring, support hours and response targets

Write down what will be monitored, who receives alerts and what happens next. Then agree support hours and response targets in writing. Typical contracts set severity levels, with a target time to acknowledge and start work on each during the agreed support hours.

Be precise about hours and time zones. If the partner works in a different time zone, state their support hours in both zones. If you need on-call cover outside those hours, ask whether it is offered and how it works. Do not assume round-the-clock cover unless the contract says so.

• Services and metrics monitored, and alert thresholds.
• Severity definitions with examples.
• Support hours, time zone and public holiday calendar.
• Response targets for each severity, and how issues are reported.
• Escalation contacts on both sides.
• Incident reports after significant outages.

Backups, restore testing and documentation

A backup that has never been restored is a hope, not a plan. The contract should say what is backed up, how often, where copies are kept, how long they are retained and how often a test restore is carried out and reported to you.

Documentation should be a deliverable, kept up to date as part of the service. Ask for an architecture overview, an inventory of resources and accounts, runbooks for routine tasks and incident response, and a record of how to rebuild each environment.

Cost controls

The simplest arrangement is that you pay the cloud provider directly, on your own account, and pay the partner separately for their services. You then see every charge and keep billing history if you change partners.

Ask the partner to set up budgets and spending alerts in your account, tag resources by project or environment, and flag changes that will increase running costs before making them. Agree who can buy reserved capacity or other long-term commitments, since those bind your business.

Data protection obligations

If the partner can access personal data, data protection law will usually apply, and you may need specific contract terms with them. The rules depend on where you, your customers and the partner are. The main laws for the markets in this guide are:

• UK: the UK GDPR and the Data Protection Act 2018 (as amended by the Data (Use and Access) Act 2025), regulated by the Information Commission, which replaced the Information Commissioner’s Office on 30 September 2026 and still uses the ICO name.
• US: state privacy laws, such as California’s CCPA as amended by the CPRA, enforced by the California Attorney General and the California Privacy Protection Agency.
• Canada: the Personal Information Protection and Electronic Documents Act (PIPEDA), overseen by the Office of the Privacy Commissioner of Canada.
• Australia: the Privacy Act 1988 and its Australian Privacy Principles, regulated by the Office of the Australian Information Commissioner.
• Singapore: the Personal Data Protection Act 2012 (PDPA), administered by the Personal Data Protection Commission, which also places duties on data intermediaries that process data for others.
• UAE: Federal Decree-Law No. 45 of 2021 on the protection of personal data. The DIFC and ADGM financial centres have their own separate data protection laws and regulators.
• India: the Digital Personal Data Protection Act 2023, with the DPDP Rules 2025 notified in November 2025 and phased in over 18 months.

Exit and handover

Plan the ending at the beginning. The contract should require a handover period, an updated set of documentation and runbooks, the transfer of any remaining credentials, removal of the partner’s access and written confirmation that copies of your data have been returned or deleted. Agree a notice period that gives you time to bring in a new team.

Ask for a short exit test before you rely on it: can your own staff, or another provider, log in, deploy a change and restore a backup using only the documentation and the accounts you own? If not, fix the gaps while the relationship is still running smoothly.

Common questions