The Settings You Did Not Choose: A UK Review of Inherited Cloud Configurations

Cloud procurement rarely fails at the point of signature. It fails months later, when a team discovers that a backup has been replicated outside the UK, that a sharing link was open to anyone with the URL, or that audit logs disappear after thirty days. None of these outcomes required a decision. They were inherited.

That is the central problem with provider defaults. They are not neutral. They reflect a vendor's attempt to make a service easy to adopt, not a UK organisation's attempt to meet its own obligations under UK GDPR, its retention policy or its incident-response plan. The settings a provider chooses before a customer arrives become, in practice, unnegotiated clauses in the operating model.

Defaults are commercial and legal choices

A default is a decision made on the customer's behalf by someone who does not know the customer's data, sector or risk appetite. It may be sensible for a small team testing a product. It may be unsuitable for a firm handling client records, payroll data or regulated communications.

For UK buyers, the accountability principle matters here. The organisation remains responsible for how personal data is processed, even when a platform supplies the mechanism. The ICO's expectations around data protection by design, records of processing and security do not pause because a console toggle was left untouched.

Procurement teams therefore need to treat inherited settings as part of the deal. They should be reviewed before renewal, after major product changes and whenever a new department or subsidiary is onboarded.

Begin with the contract and the console

Start by reading the data processing addendum, subprocessor list and service description alongside the actual administrative console. The contract may permit a region, but the console shows which region is active. The contract may describe deletion on termination, but the console shows retention periods and backup behaviour.

Record the gap between the two. That gap is where assurance work begins.

Data residency and transfer risk

Check the primary storage region, disaster-recovery region, backup replication and support-access arrangements. A UK tenant does not automatically mean UK-only processing. Remote support staff, subprocessors and content-delivery networks may create transfers that need a lawful mechanism and a transfer risk assessment.

Ask the provider to document where data is stored at rest, where it is replicated and which entities can access it for support. Then compare that with your own record of processing activities. If the answer is opaque, treat opacity as a procurement finding rather than a technical detail.

Retention and deletion

Default retention periods are often designed for product convenience. Chat messages may persist indefinitely, file versions may be kept for a fixed period, and audit logs may expire faster than an investigation requires. Conversely, some services may delete data sooner than a UK firm's regulatory or contractual obligations demand.

Set retention labels and deletion rules explicitly. Confirm how backups are treated when a user deletes a file or leaves the organisation. Ask whether legal hold overrides default deletion and how that hold is documented. Retention is not a storage-cost question alone; it is an evidence and minimisation question.

Sharing permissions and guest access

Default sharing settings are among the most consequential and least reviewed controls. A platform may allow external sharing by link, guest invitations or third-party application consent with little friction. The result is a shadow collaboration estate that sits outside the usual joiner-mover-leaver process.

Audit who can share externally, what defaults apply to new files and folders, and whether links expire. Review guest accounts and third-party app integrations. Where possible, restrict external sharing to named domains or approved use cases, and make exceptions visible rather than silent.

Logging and monitoring

Audit logs are only useful if they exist when needed. Some tiers retain them briefly, some expose only a subset of events, and some require an additional licence for export. A UK firm should know whether it can reconstruct a security incident, a data-sharing event or an administrator change.

Confirm log coverage, retention and export options. If the default window is too short, either upgrade the tier, export logs to a controlled repository or document the accepted risk. Do not assume that a dashboard equals an evidential record.

Backup and replication

Backup defaults can create both resilience and compliance surprises. Geo-redundant storage may improve availability while placing copies in another jurisdiction. Immutable backups may support recovery but complicate deletion requests. Restore testing may be available only at a higher support tier.

Document the replication map, the restore process and the responsible owner. Test a restore before an incident, not during one. For UK organisations with sector-specific continuity expectations, the backup default should be aligned with the business-impact analysis, not left to the platform's standard configuration.

Support tier and escalation

Default support is usually a queue, not a relationship. Response times, named contacts, status notifications and escalation paths may be weaker than the business assumes. For systems that support payroll, client services or regulatory reporting, that mismatch becomes an operational risk.

Use the renewal conversation to align support with criticality. Ask for service credits, escalation contacts and incident communications in writing. A support-tier default is a procurement term in all but name.

A repeatable audit checklist

1. Inventory every cloud and productivity platform holding business or personal data.
2. Identify the administrator account and confirm who can change settings.
3. Export the current configuration for residency, retention, sharing, logging, backup and support.
4. Compare those settings with the contract, the data processing addendum and your record of processing activities.
5. Classify each gap by security, compliance, cost and operational impact.
6. Decide whether to accept, remediate or escalate each default.
7. Record the decision, the owner and the review date in a configuration register.
8. Re-test after product changes, renewals and major organisational changes.

Turn inherited settings into explicit decisions

The aim is not to change every default. Some are appropriate. The aim is to ensure that a UK business knows which settings it has inherited, why they are acceptable and who is accountable for them.

That discipline belongs in IT procurement because it affects cost, risk and contractual leverage. It also belongs on the board's technology agenda, because a default is still a decision. The provider made the first move. The buyer should make the next one deliberately.