Cloud Security Best Practices: A Practical 2026 Guide

The practices that matter have not changed much in five years. What has changed is that most teams now know them and still do not have them switched on. The gap is not knowledge, it is implementation: nobody wrote down which account owns the control, which command turns it on, and what evidence proves it is still on next quarter.

This guide is built to close that gap. Every practice below names the control, gives the enabling command or policy on AWS, Azure and Google Cloud, and maps to the benchmark item an assessor will actually test. It ends with a 90-day checklist you can hand to an engineer, and a section on the Indian obligations — the DPDP Act and the CERT-In directions — that global guides omit entirely.

What actually causes cloud incidents

Cloud breaches cluster into four root causes, and only one of them looks like an attack in the way people imagine.

The industry reports worth reading on this are the Verizon Data Breach Investigations Report, the IBM Cost of a Data Breach Report and the Thales Data Threat Report. Read the current edition rather than a quoted figure, because the ranking moves: the 2026 DBIR reports that 31% of breaches now start with software vulnerabilities, beating stolen passwords as the top way attackers get in, where earlier editions put credentials first.

The practical consequence is where you spend the first thirty days. Exposed, unpatched internet-facing services now deserve the same urgency as identity hygiene, and neither displaces the configuration work underneath both — a week spent removing long-lived keys, patching what faces the internet and turning on organisation-level public-access prevention buys more risk reduction than a quarter spent evaluating detection tooling.

The shared responsibility model, stated precisely

"The provider secures the cloud, you secure what you put in it" is true and too vague to act on. The line moves with the service model.

Three things are yours on every provider and every service model, without exception: who can access what, how long your logs are kept and where, and what your data is and how long you keep it. Those three are also where teams most often assume the provider has it covered.

The authoritative statements of the boundary are the AWS Well-Architected Security Pillar, the Microsoft Cloud Security Benchmark and the Google Cloud enterprise foundations blueprint.

Identity: the real perimeter

Eliminate long-lived keys

A static access key in a CI pipeline is one of the findings worth looking for first, because it is durable, widely reachable and easy to fix. Replace it with federation: GitHub Actions and most CI systems can exchange an OIDC token for a short-lived cloud role, so no secret exists to leak.

Start by finding what you have.

# AWS: who has keys, how old, and when they were last used
aws iam generate-credential-report
aws iam get-credential-report --query 'Content' --output text | base64 -d

# AWS: block instance-metadata credential theft via SSRF
aws ec2 modify-instance-metadata-options \
  --instance-id i-0123456789abcdef0 \
  --http-tokens required --http-endpoint enabled

IMDSv2 (--http-tokens required) is a configuration change, not a project, and it closes the mechanism behind several well-known cloud credential thefts.

On Google Cloud, stop the keys being created at all rather than hunting them later:

gcloud resource-manager org-policies enable-enforce \
  constraints/iam.disableServiceAccountKeyCreation \
  --organization=ORGANIZATION_ID

Phishing-resistant MFA, and a break-glass path

Every human identity needs MFA, and privileged humans need a phishing-resistant factor — a hardware security key or platform authenticator, not SMS. Then handle the root or global-administrator account deliberately: no access keys, hardware MFA, credentials split and stored offline, and an alert that fires whenever it is used. Two break-glass accounts, excluded from conditional access, tested twice a year, is the pattern that survives an identity-provider outage without becoming a standing risk.

Least privilege you can maintain

Least privilege fails when it is enforced by review rather than by architecture. Use the layer that prevents rather than reports: Service Control Policies on AWS, Azure Policy with a deny effect, Organization Policy constraints on GCP. A deny at the organisation boundary cannot be undone by a developer with administrator rights inside an account, which is the whole point.

{
  "Version": "2012-10-17",
  "Statement": [{
    "Sid": "DenyUnapprovedRegions",
    "Effect": "Deny",
    "NotAction": ["iam:*", "sts:*", "cloudfront:*", "route53:*", "support:*"],
    "Resource": "*",
    "Condition": {
      "StringNotEquals": { "aws:RequestedRegion": ["ap-south-1", "ap-south-2"] }
    }
  }]
}

Then let the provider tell you what is actually over-permissioned:

# AWS: find resources shared outside your organisation.
# Run from the management or delegated administrator account.
# --type ACCOUNT would set the zone of trust to the single account only.
aws accessanalyzer create-analyzer --analyzer-name org-external --type ORGANIZATION
aws accessanalyzer list-findings --analyzer-arn <arn>

# GCP: role recommendations based on 90 days of observed usage
gcloud recommender recommendations list \
  --recommender=google.iam.policy.Recommender \
  --project=PROJECT_ID --location=global

Mapping for the auditor: this section covers the IAM chapter of the CIS Foundations Benchmark for each provider, the Identity Management and Privileged Access controls of the Microsoft Cloud Security Benchmark, NIST CSF 2.0 PR.AA, and CIS Controls v8.1 Controls 5 (Account Management) and 6 (Access Control Management), whose Safeguards are numbered within each — 5.1, 5.2, 6.1 and so on — if your mapping sheet needs that level.

Configuration: stop the leading cause

Eight misconfigurations are worth checking before any other configuration work, because each one is independently sufficient to cause an incident:

1. Storage readable by anyone, usually through a bucket policy rather than an ACL.
2. Security groups or NSGs open to 0.0.0.0/0 on management ports.
3. Volumes and managed databases without encryption at rest.
4. Audit logging disabled, or enabled in one region only.
5. Snapshots and machine images shared publicly.
6. IAM policies with wildcard actions on wildcard resources.
7. Databases with public endpoints and weak network ACLs.
8. Unrestricted egress, so anything that lands can call home.

Guardrails beat audits. A preventive control stops the bad state existing; a detective control tells you it existed. You need both, in that order. The most valuable single change most organisations can make is turning on account-level public access prevention:

# AWS: account-wide, not per bucket
aws s3control put-public-access-block --account-id 111122223333 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# GCP: organisation-wide public access prevention
gcloud resource-manager org-policies enable-enforce \
  constraints/storage.publicAccessPrevention --organization=ORGANIZATION_ID

An Azure Policy with a deny effect does the equivalent job declaratively:

{
  "if": {
    "allOf": [
      { "field": "type", "equals": "Microsoft.Storage/storageAccounts" },
      { "field": "Microsoft.Storage/storageAccounts/allowBlobPublicAccess", "equals": "true" }
    ]
  },
  "then": { "effect": "deny" }
}

Baseline the rest against the CIS Benchmarks — there is a separate Foundations Benchmark for AWS, Azure and GCP, plus service-level benchmarks for Kubernetes and the major databases. Use the Foundations Benchmark for the account baseline and the service benchmark for the workload.

A CSPM or CNAPP platform finds these continuously and is worth having. What it will not tell you is whether two individually acceptable settings combine into an attack path, or whether a role that looks over-broad is actually justified. Those need a person.

Data protection and encryption

Classify before you encrypt. Encryption applied uniformly to everything costs the same as encryption applied deliberately and proves much less, because you cannot answer the regulator's question — which of your systems hold personal data — from a blanket setting.

At rest is now default on all three providers for most services and is rarely the gap. In transit is usually enforced at the load balancer and forgotten between services inside the VPC. Confidential computing matters for a narrow set of workloads and is not where a general programme should start.

Key management is where the regulator's interest actually lands. Provider-managed keys are fine for most data. A customer-managed key (KMS CMK, Azure Key Vault key, Cloud KMS) gives you the ability to revoke access and produce a separate audit trail of key use, and that ability is what a regulated buyer is asking about when they ask whether you control your keys. Hold-your-own-key arrangements add operational risk and should be adopted only against a specific requirement.

Backups deserve the same rigour as production, because ransomware now targets them first. Object Lock on S3, immutable vaults in Azure Backup, and bucket retention policies on GCP make deletion impossible rather than merely restricted — and the copy should live in a different account, subscription or project from the workload, so a compromise of the workload identity cannot reach it. Test a restore on a schedule; an untested backup is a belief, not a control.

Network, workloads and pipelines

Private connectivity — PrivateLink, Private Endpoints, Private Service Connect — keeps traffic to managed services off the public internet and removes a whole class of exposure. Segmentation between environments matters more than segmentation within them.

Egress control is the practice almost nobody implements and the one that most reliably limits blast radius. If a compromised workload cannot open an arbitrary outbound connection, exfiltration and command-and-control both become much harder. Default-deny egress is disruptive to introduce later and nearly free to introduce at the start.

For containers and Kubernetes: enforce admission control, apply pod security standards, scan images before deployment rather than after, and require signed images from a registry you control. For serverless the risk is permissions, not patching — a function with a broad execution role is a privilege escalation path with a very small footprint.

In the pipeline, the practices that pay are secret scanning on every commit, short-lived tokens in place of stored credentials, infrastructure-as-code scanning before apply, and drift detection after. The OWASP Cloud-Native Application Security Top 10 is the best short list of what goes wrong between code and cloud. Cloud penetration testing sits on top and answers a different question: not whether a setting matches a benchmark, but whether an attacker can chain what exists into access to data. Check each provider's testing policy first — all three permit customer-initiated testing of your own resources within stated limits, and the limits differ.

Detection, logging and response

The minimum viable log set is the same conceptually on every provider and named differently on each.

Enabling the detection layer is a two-line job, and it is worth confirming rather than assuming — it is off by default:

# AWS
aws guardduty create-detector --enable
aws securityhub enable-security-hub --enable-default-standards

# Azure (per plan, per subscription)
az security pricing create --name VirtualMachines --tier Standard
az security pricing create --name StorageAccounts --tier Standard

Send the logs somewhere the application team cannot write to — a dedicated logging account, subscription or project — and set retention explicitly. Defaults are either "never expire" (expensive) or shorter than your obligation (non-compliant). Neither is a decision.

Two things differ from on-premise incident response. Containment is an identity action before it is a network action: revoke the session, rotate the key, detach the role. And evidence is ephemeral — snapshot the volume and preserve the instance metadata before terminating anything. Write both into the runbook now. MITRE ATT&CK for Cloud is the right starting point for choosing which detections to build first.

The India layer: DPDP Act, CERT-In and sectoral rules

This is the part global guides leave out, and it is the part that decides whether your configuration passes an Indian audit.

CERT-In directions (28 April 2022) require reporting of specified cyber incidents within six hours of noticing them, and retention of ICT system logs for 180 days, maintained within India. In configuration terms that means log group and workspace retention set to at least 180 days on every group — not just the ones somebody remembered — with a copy in an Indian region where residency applies, and an alerting path that reaches a human rather than an inbox. A six-hour clock cannot be met by reading Friday's logs on Monday. Our guide to the CERT-In directions sets out the reporting mechanics.

The DPDP Act pulls the other way on the same infrastructure. It pushes you to erase personal data once the purpose it was collected for is served, and to apply reasonable security safeguards to what you still hold. Security logs and personal data are different data classes with different lifecycles; a single blanket retention rule applied to both is a common and expensive mistake. The Act also makes breach notification an obligation in its own right, separate from the CERT-In clock.

Sectoral regulators add cadence and assurance requirements on top. Regulated entities should read their own instrument for testing frequency and third-party or cloud outsourcing expectations — our notes on the RBI cybersecurity directions and on how often VAPT should be done cover the intervals.

The efficiency worth knowing: one well-built logging and posture baseline produces evidence for ISO/IEC 27001:2022 Annex A, SOC 2 Common Criteria, your DPDP Act safeguards position and your CERT-In retention position simultaneously. Teams that run these as four separate exercises pay four times for one set of controls.

The 90-day cloud security checklist

Assign an owner and an evidence artefact to every line. A control without a named owner drifts; a control without evidence cannot be proven in an audit.

Days 1-7, stop the bleeding

Days 8-30, baseline and instrument

Days 31-90, govern and prove

After day 90: posture scorecard monthly, access review quarterly, restore test quarterly, runbook exercise twice a year, cloud penetration test annually and after any material change.

What to do first, by stage

Under twenty engineers and one account: identity and storage exposure, then logging. Nothing else. Get MFA everywhere, remove static keys, block public storage, turn on the audit log and the native threat detection, and write the one-page standard.

Multi-account or multi-subscription: build the landing zone properly — a dedicated logging account, a security account, organisation-level guardrails, and federated access through a single identity provider. Retrofitting this at three hundred engineers is a year of work. Note that the organisational hierarchy differs by provider — organisations and OUs, management groups and subscriptions, folders and projects — and that determines where a guardrail can be applied.

Regulated and multi-cloud: the additional work is evidence, not controls. Continuous compliance mapping, key custody decisions documented against the specific regulatory instrument, log residency, tested six-hour reporting, and an independent annual test.

Five findings worth checking for by hand

1. At least one log group left at default retention, almost always an application group nobody configured.
2. A CI role that can assume a production administrator role, created for a migration two years ago.
3. Public access blocked per bucket but not at the account level, so the next bucket is exposed.
4. Threat detection enabled in the primary region only, while workloads run in three.
5. Backups in the same account as the workload they protect, reachable by the same identity.

None of these is exotic, and none of them needs a tool to find — each is a query against configuration you already have. Check them before you commission anything larger.

How SecureRoot helps

We run a cloud security configuration assessment across AWS, Azure and GCP accounts against the CIS Foundations Benchmarks, separating real exposure from benchmark noise and handing over a scorecard with fix guidance rather than a scanner dump. We then run cloud penetration testing to find what an attacker could chain together from what is actually deployed — a different question from whether a setting matches a benchmark. Retesting after remediation is included. Where the issue starts in the application, secure code review covers it, and managed services cover the continuous monitoring the six-hour clock assumes.

SecureRoot Risk Advisory LLP holds an ISO/IEC 27001:2022 certificate and works to ISO 9001:2015, with our registered office in Kanpur and a branch office in Greater Noida West.

Scoping takes a 30 to 45 minute call, after which you get a written scope and a fixed price. Request an assessment to start.

Frequently asked questions

What are the most important cloud security best practices?

Ranked by risk reduction per hour of effort, five stand out. First, eliminate long-lived credentials — enforce MFA on every human identity and replace static access keys with federated, short-lived tokens. Second, apply preventive guardrails at the organisation level: block public storage, deny unapproved regions, and stop service account key creation, so the bad state cannot exist rather than being reported after the fact. Third, enable audit logging in every region, centralise it in an account the application team cannot write to, and set retention explicitly. Fourth, classify your data and protect backups with immutability in a separate account. Fifth, test what you built — a benchmark review finds misconfigurations, a penetration test finds the chains between them. Everything else on a twenty-item list is refinement on top of these five, and refinement applied before the basics is wasted effort.

What causes most cloud security breaches?

Configuration error, credential misuse and unpatched internet-facing software, in an order that changes with the report and the year — so do not plan from a single ranking. In the 2026 Verizon DBIR, unpatched software overtakes stolen credentials as the most common way in, at roughly three breaches in ten; read its current edition alongside the IBM Cost of a Data Breach Report and the Thales Data Threat Report rather than quoting any one figure. What the failures have in common is that they are unremarkable: storage left publicly readable through a permissive bucket policy, a role with wildcard permissions created for a migration and never removed, an access key committed to a repository, a management port open to the internet, an internet-facing service running an image nobody has rebuilt. That is good news operationally — most of what prevents these is configuration and patching discipline, not a purchase.

What are the five pillars of cloud security?

Most frameworks converge on the same five. Identity and access management: who and what can reach each resource, enforced with MFA, short-lived credentials and least privilege. Data protection: classification, encryption at rest and in transit, key management and immutable backup. Infrastructure security: secure configuration of compute, storage and network, segmentation, private connectivity and egress control. Threat detection and response: the minimum log set, centralised and retained, native threat detection enabled, and a tested cloud-specific incident runbook. Compliance and risk management: mapping those controls to the frameworks you claim, producing evidence continuously rather than at audit time. The AWS Well-Architected Security Pillar, the Microsoft Cloud Security Benchmark and the Google Cloud enterprise foundations blueprint each express this structure with different names, and the CIS Foundations Benchmark for each provider turns it into specific settings. Treat the five as owners rather than topics: each pillar needs one accountable person, or the gaps open between them.

What is the shared responsibility model, and what is always my responsibility?

The provider secures the infrastructure the cloud runs on; you secure what you deploy on it. Where the line sits depends on the service model — with infrastructure services you own the operating system and its patching, while with platform and serverless services the provider takes that and you keep the code and its permissions. Three responsibilities never move, on any provider or service model. Identity and access is always yours: no provider decides who may read your data. Data classification and retention is always yours, including deciding what personal data you hold and how long. Logging enablement and retention is always yours; providers give you the capability and generally leave it off or at a default that does not match your obligation. Most shared-responsibility gaps we find sit in exactly those three, and all three are cheap to close once someone owns them.

What should be on a cloud security checklist?

Sequence it by time rather than by topic, because everything looks equally urgent otherwise. Days one to seven, stop the bleeding: MFA everywhere, root account locked down, account-level public storage prevention, unused access keys removed, management ports closed, audit logging on in every region, native threat detection enabled, secrets scanned out of repositories, log retention set to at least 180 days. Days eight to thirty, baseline and instrument: run the CIS Foundations Benchmark, enable posture management, enforce IMDSv2, replace CI static keys with federation, deploy organisation-level guardrails, centralise logs, classify data and vault secrets. Days thirty-one to ninety, govern and prove: access reviews, egress control, tested restores, ATT&CK-mapped detections, framework mapping, a penetration test and a retest. Give every line an owner and an evidence artefact. A control without a named owner drifts within a quarter, and a control without evidence cannot be proven when an auditor or an enterprise buyer asks.

Do cloud security best practices differ between AWS, Azure and Google Cloud?

The controls are identical; the names and the enforcement points differ. Preventive policy is a Service Control Policy on AWS, an Azure Policy with a deny effect, and an Organization Policy constraint on GCP. Posture management is Security Hub, Defender for Cloud and Security Command Center. Threat detection is GuardDuty, Defender for Cloud and Event Threat Detection. Private connectivity is PrivateLink, Private Endpoint and Private Service Connect. Three genuine differences matter in design. The organisational hierarchy differs — organisations and OUs, management groups and subscriptions, folders and projects — and that determines where a guardrail can be applied. Default encryption and default network behaviour vary by service, so verify rather than assume. And the identity models differ enough that a policy pattern does not transfer literally. CIS publishes a separate Foundations Benchmark for each provider for exactly this reason.

Is a CIS Benchmark review the same as a cloud penetration test?

No, and most teams need both. A benchmark review compares your live configuration to a published control set and tells you which settings deviate. It is broad, repeatable, largely automatable, and the right first step because it finds the misconfigurations that cause most incidents. A cloud penetration test starts from an attacker's position and asks what can actually be reached and chained — a role that can assume another role, a storage bucket reachable through a function, a metadata endpoint exposed through a request-forgery flaw in the application. Those chains are invisible to a benchmark, because each individual setting in the chain may be compliant. Run the configuration review first, fix what it finds, then test. Testing an environment that has never been benchmarked mostly rediscovers the benchmark at a higher cost. The review also gives the test a better starting point, because the tester knows what is meant to be true.

What do the DPDP Act and CERT-In directions require from cloud deployments in India?

The CERT-In directions of 28 April 2022 set two requirements that land directly on cloud configuration: specified cyber incidents must be reported within six hours of being noticed, and ICT system logs must be retained for 180 days and maintained within India. In practice that means log retention set to at least 180 days on every log group rather than the ones somebody remembered, logs held in an Indian region where residency applies, and an alerting path that reaches a person who can recognise a reportable event as it happens. The DPDP Act pulls the other way on the same estate: erase personal data once its purpose is served, apply reasonable security safeguards to what remains, and notify breaches. Security logs and personal data are different classes needing different lifecycle rules. One blanket retention policy fails both.