How do you protect data in the cloud? A practical checklist

To protect data in the cloud, know where it lives and how sensitive it is, encrypt it in transit and at rest with keys you manage, restrict access to the minimum, log who touches it, and prove you can recover it. The cloud provider secures the platform. Your configuration decides who can read your data.

Who is responsible for what?

NIST SP 800-144, guidelines on security and privacy in public cloud computing, makes the central point: moving to a public cloud does not remove your accountability for data security and privacy. The provider handles parts of the stack, and the customer remains responsible for how data is classified, who can access it and how services are configured. Providers describe the same split as a shared responsibility model.

Where does the data actually live?

You cannot protect what you cannot find. Cloud data spreads into object storage, databases, backups, logs, analytics copies, developer test environments and SaaS tools. Each copy needs an owner. Begin with an inventory of data stores and a simple classification, such as public, internal, confidential and regulated, tied to handling rules.

What controls matter most?

Encryption. Encrypt data in transit with current TLS and at rest with provider managed or customer managed keys. NIST SP 800-57 Part 1 covers key management practice, including key lifecycles, separation of duties and protecting keys at least as well as the data they protect. Keep keys separate from the data they encrypt, and restrict who can use or delete them.

Access control. Apply least privilege through roles and groups instead of individual grants. Remove public access by default, and review it regularly. Prefer short lived credentials to long lived keys.

Logging. Record reads and writes on sensitive stores, and send logs to a separate protected location. Alert on unusual volumes, such as a service account reading far more than usual.

Backup and recovery. Keep copies in a separate account or region with different credentials, and make deletion hard. Test restores, since a backup you never restored is an assumption.

Data lifecycle. Delete data you no longer need. Less data means less to lose, and many privacy rules require retention limits.

Constructed example: the test copy

A team copies a production customer table into a test database to debug a report. The test environment has weaker access rules and shared developer accounts. Three months later, the test database is exposed by a mistaken network rule. The production system was well protected, but the copy was not.

The fix is process as much as technology: use masked or synthetic data in test, restrict who can create copies of regulated data, and include test stores in the data inventory.

What about code and dependencies?

Data leaks also start in application flaws, not just storage settings. An injection flaw or a vulnerable library can let an attacker read a database through the application, however well the storage is encrypted. Secure development, dependency management and secrets handling are part of data protection. Safeguard's scanning for dependencies, code and secrets supports that layer, and its compliance automation helps map the evidence to framework controls.

How to check or apply this

1. Inventory data stores, including backups, logs and test copies, and assign an owner to each.
2. Classify data and write handling rules for each class.
3. Block public access by default and review any exception monthly.
4. Encrypt in transit and at rest, and manage keys with separation of duties.
5. Turn on access logging for sensitive stores and alert on unusual reads.
6. Keep backups in a separate account, restrict deletion, and test restores quarterly.
7. Use masked or synthetic data outside production.
8. Set retention periods and delete on schedule.

Quick check

Sources

• NIST SP 800-144, Guidelines on Security and Privacy in Public Cloud Computing
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management
• AWS shared responsibility model

Last reviewed: 18 October 2026.