7 Ways to Achieve Data Security in the Cloud

You achieve data security in the cloud by doing a handful of unglamorous things consistently: encrypt data everywhere, give every account only the access it needs, require strong multi-factor authentication, watch your logs, lock down APIs, keep less data, and test your defenses on a schedule. The cloud itself is rarely the weak point. Gaps in how teams run it usually are.

This guide is for IT, security and business leaders who own cloud systems holding employee, customer or financial data. A common mistake we see is treating cloud security as a one-time setup project, then assuming the settings chosen at launch still hold a year later.

Key takeaways

• Many cloud incidents start with misconfiguration, over-permissioned accounts and stolen credentials, not exotic attacks.
• Encryption, least privilege and phishing-resistant MFA close the largest gaps for the least effort.
• Logs only help if someone owns the alerts and has a plan for when they fire.
• Storing less data, for less time, shrinks what an attacker can take.
• Security settings drift. Schedule access reviews, configuration audits and testing rather than waiting for an incident.

Why is cloud data security different from on-premises security?

On-premises, many teams relied on a network perimeter: if you were inside the building or on the VPN, you were trusted. In the cloud, that perimeter mostly disappears. Your data sits in services reachable over the internet, administrators log in from anywhere, and applications talk to each other through APIs.

That's why NIST's Zero Trust Architecture guidance (SP 800-207) argues that network location shouldn't grant trust on its own. Each user and device is verified before it reaches a resource. The seven practices below are how that idea turns into day-to-day work.

The other big difference is shared responsibility. Your cloud provider secures the physical data centers and the underlying platform. You're still responsible for who has access, how services are configured and what data you put there. Many incidents happen in that second half.

The 7 ways to secure data in the cloud

1. Encrypt data at rest and in transit

Encryption at rest means that if someone gets into storage, the raw data is unreadable without the key. Encryption in transit protects data moving between users, your systems and cloud services so it can't be read if intercepted.

Most major providers offer built-in encryption, but defaults vary by service and aren't always on. Check each storage service, database and backup explicitly and write down what's covered. Use AES-256 for data at rest. For data in transit, NIST's TLS guidelines (SP 800-52 Rev. 2) require TLS 1.2 with approved cipher suites and support for TLS 1.3, which is a sensible bar for private organizations too.

Key management is where teams cut corners. Decide who can use and rotate keys, keep key administration separate from data administration where you can, and rotate on a schedule. If the same person can read the data and manage the keys, encryption protects you less than you think.

2. Apply the principle of least privilege

Over-permissioned accounts are one of the most common ways cloud environments get compromised. A developer who needs read access to one database shouldn't have write access to five. An application that only retrieves files shouldn't be able to delete them.

Least privilege means each user, service and application gets the minimum permissions its job requires. If one account is compromised, the damage is limited to what that account could do, not everything it was given "just in case." The same thinking applies inside business systems; our guide to UKG Pro role-based security for HR, payroll and managers shows what it looks like in an HCM.

Review permissions regularly, not only at onboarding. People change roles, contractors leave and applications are retired. Tie access removal to your offboarding process so it happens the same day, not at the next quarterly review.

3. Require multi-factor authentication everywhere

Passwords alone aren't enough. MFA adds a second check, such as an authenticator app, hardware key or biometric, so a stolen password isn't sufficient on its own.

Enforce MFA at the policy level for everyone who touches cloud resources, starting with administrators. Not all MFA is equal. CISA's MFA guidance calls phishing-resistant MFA, such as FIDO/WebAuthn security keys and passkeys, the standard to aim for, and suggests number matching for push approvals where that isn't possible yet. SMS codes are better than nothing but can be intercepted through SIM-swapping. If you're weighing options, see are biometrics better than passwords.

4. Monitor and audit access continuously

You can't protect what you can't see. Cloud services generate logs for logins, API calls, configuration changes and data access, and most of it goes unread. Continuous monitoring catches suspicious patterns early: logins at odd hours, access from unexpected countries, a sudden spike in downloads.

A security information and event management (SIEM) tool can do much of the correlation. The harder part is ownership. Decide which alerts matter, who receives them and what they do next. An alert that goes to a shared inbox nobody watches is the same as no alert.

Watch for systems your security team doesn't know about, too. Business-built apps and unsanctioned SaaS tools often hold sensitive data with none of these controls. Our shadow IT governance playbook covers how to find and manage them. Free online file converters fall into this category too, so see our guide to converting OST to PST without online tools for a safer way to handle mailbox data.

5. Secure your APIs

Cloud applications talk to each other through APIs, and an unsecured API is an open door. Common problems include APIs that return more data than the caller needs, endpoints with no authentication and old authentication methods that were never retired.

• Authenticate every API call. Don't rely on network controls alone.
• Use an API gateway to centralize authentication, rate limiting and logging.
• Return only the fields the function needs.
• Test for injection, broken authentication and excessive data exposure in every release cycle.
• Rotate API keys and tokens, and never store them in code repositories.

Automation projects deserve extra attention here, because bots and integrations often run with broad service-account permissions that nobody revisits.

6. Classify your data and set retention rules

Not all data needs the same protection, and treating everything as top secret makes security too heavy to sustain. Classify data by sensitivity, for example public, internal, confidential and restricted, and apply controls to match each tier.

Then decide how long you need each type. The less you store, the less you can lose. Automated lifecycle policies can archive or delete records on schedule. Restricted data, such as payroll, health or ID information, may also need tighter access than even your own IT admins have; see how to protect confidential HR files from IT admin access.

7. Test your security posture regularly

Cloud environments change constantly. New services are added, configurations drift and new vulnerabilities are published. Testing tells you whether your defenses hold up in practice.

• Configuration audits check that settings match your policy, not what someone assumed was set.
• Vulnerability scanning finds known weaknesses before attackers do.
• Penetration testing has authorized testers use real attacker techniques to show where you're exposed.
• Incident response drills confirm people know who to call and what to shut off.

Cloud data security checklist

Control	What "done" looks like	Review how often
Encryption	Every storage service, database and backup verified; keys rotated	Quarterly and when adding services
Least privilege	No standing admin rights without justification; same-day offboarding	Quarterly access review
MFA	Enforced by policy; phishing-resistant for admins	Twice a year
Monitoring	Named owner for each high-priority alert	Monthly alert tuning
APIs	All endpoints authenticated; keys out of code	Every release
Data retention	Classification applied; lifecycle rules running	Annually
Testing	Scans running; pen test findings tracked to closure	Scans continuous, pen test yearly

Who should own cloud security?

The thread running through all seven practices is that they work best as habits, not projects. Cloud providers' built-in tools have improved a lot, and much of this can be automated or enforced by policy. The question for most organizations isn't whether the tools exist. It's whether someone clearly owns making sure they're used.

Give each control a named owner, report on it in the same meeting where you review other operational risks, and budget for the testing. Cloud security is rarely broken by sophisticated attacks on well-maintained environments. It's usually broken by gaps that could have been closed months earlier. If your organization also handles customer payments or personal data online, the same principles apply; see how to protect customer data online.

FAQ

Is data safer in the cloud than on-premises?

It can be. Major cloud providers invest more in physical and platform security than most organizations can on their own. But you remain responsible for access, configuration and the data you upload. A well-run cloud environment is usually safer than a neglected server room; a misconfigured cloud storage bucket can be far worse.

What is the most important cloud security control to start with?

If you can only do one thing this month, enforce multi-factor authentication for every account that can reach cloud resources, starting with administrators. Stolen credentials are one of the most common ways in. Then review who holds admin rights and remove any that aren't clearly needed. Both steps are cheap and fast.

What does zero trust mean in practice?

Zero trust means no user or device is trusted just because it's on your network or owned by your company. Every request is checked for identity, device health and permission before access is granted, and access is limited to the specific resource. In practice that means strong MFA, least privilege, device checks and continuous logging.

What to do next

1. Turn on MFA enforcement for all cloud admin accounts this week, and plan a move to phishing-resistant methods.
2. Run an access review on your most sensitive system and remove permissions nobody can justify.
3. Verify encryption settings for every storage service and backup, and write down the results.
4. Assign a named owner to each row of the checklist above and put the review dates on a calendar.

Sources

• NIST, SP 800-207, Zero Trust Architecture
• NIST, SP 800-52 Rev. 2, Guidelines for TLS Implementations
• CISA, More than a Password (multi-factor authentication)

Last reviewed: October 2026.