Cloud security best practices follow an order of work, and this guide gives ten steps, each with a check that it worked. This guide is for an IT manager at a firm in India or the GCC that runs workloads in a public cloud. It names no provider. The steps draw on the NCSC’s guidance on using a cloud platform. That UK guidance, published on 7 June 2023, speaks to cyber security professionals, large organisations, small and medium-sized organisations and the public sector. The guide covers how you configure and run the platform, not the services you deploy onto it. A check shows that a setting matches what you intended, but it does not show that the account is safe.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Security Best Practices in Short: Ten Steps, in Order
These cloud security best practices fall into three groups. The order and the checks are Signisys’ own method, not a standard, and the NCSC does not rank its 13 actions. Even with a secure-by-default provider, the NCSC’s principle on secure use of the service (UK, reviewed 7 June 2023) says configuration remains your responsibility.
| Step | Why it sits here | Check it worked |
|---|---|---|
| Workspaces | Later steps need a list to run against. | Production differs from test in who may enter. |
| Sign-ins | A shared sign-in hides who acted. | The latest leaver’s access ended on their last day. |
| Program identities | A borrowed sign-in hides which program acted. | One application runs as its own identity, with no stored password. |
| Access to the job | Narrow access limits a stolen sign-in. | One administrator role is granted for a set window. |
| Remote administration | While a management port is open, it is a way in. | A session from outside fails unless it uses the proxy or VPN. |
| Platform rules | Automatic checks run even when nobody remembers. | A forbidden change in a test workspace is blocked or alerted. |
| The data itself | If data is kept past its use, a breach can expose more of it. | One data store has a known location and deletion date. |
| Activity record | If an incident happens, there must be a record to reconstruct. | The oldest record reaches back as far as the period you set. |
| Bad-day plan | Until a backup is tested, it is unproven. | One restore and one rebuild from code are timed. |
| Re-check | If the platform changes, settings can fall behind it. | The oldest workspace matches the newest, or each gap has an owner and a date. |
Cloud Security Best Practices, Steps 1 to 3: People, Programs and Owners
If you work through them in order, these three settle who and what can act on the platform. Each step below says what to do, why it sits where it does and when it counts as done.
list them and name an owner for each.
tie every sign-in to one person.
give each program its own identity.
Key Takeaway Know your workspaces, tie every sign-in to one person, and give every program its own identity before you tune anything else.
Cloud Security Best Practices, Step 1: Set Up Workspaces for Separate Jobs
Give each project, product or component its own workspace, and name an owner for each one. A workspace is an environment for the cloud resources of one project or environment, and providers call it an account, subscription, project or tenancy. Separate workspaces where that helps, such as production from testing and internet-facing work from internal work. The NCSC says mirroring the structure of your reporting chains or cost centres may not be the best approach.
Also mark any workspace that holds sensitive data or faces the internet, with tags or a list you keep, and delete the ones nobody uses. The NCSC also adds that only administrators and automation should reach sensitive workspaces, and that you should deploy them using infrastructure as code. It also wants each new workspace to start secure: with guardrails, monitoring and activity logs from the day you create it. A guardrail is a provider feature that restricts how you can use a service, for example by stopping certain data from reaching other customers.
Signisys puts this step at the top of the order: every later step runs against the list of workspaces.
Does the production workspace differ from a test workspace in who may enter and whether data may be shared outside? Yes means you can show both differences.
Step 2: Lock Down Who Can Sign In
Use single sign-on, block common passwords, require multi-factor authentication and make sure nobody shares a sign-in. Also monitor sign-in events and any rise in privilege. Tie platform access to your joiners, movers and leavers process, and expect outside users to meet the same standard. The NCSC calls poor authentication practices “one of the most common causes of breaches in cloud platforms”, although it gives no figure for this.
Put particular effort into administrator accounts. The NCSC says to use all-powerful accounts only when initially setting up the platform and for emergency access. These are sometimes called super admin, global admin or root user accounts. That means no routine work with them, an alarm whenever someone uses one, and strong credentials. The multi-factor authentication entry explains the second check if the term is new to you.
This step comes second in Signisys’ order: the later steps assume a sign-in means one known person.
Did the latest leaver’s access to the platform end by their last day? Yes means you saw it in the access list. Second question: does a named person get an alert when an all-powerful account is used? Yes means you can name that person and show the alert rule.
Cloud Security Best Practices, Step 3: Give Each Program Its Own Identity and Secret Store
Programs act on the platform too, and each should do so as its own service identity. A service identity is the account a workload uses to reach data or other services. Use the provider’s service-identity function instead of a person’s sign-in, with a different identity for each use case. The NCSC wants any service-identity credential to be “a randomly generated high-entropy cryptographic secret, not a password”. It also wants the provider to manage that credential.
If a managed integration exists, avoid secrets altogether. If one does not, keep them in a secrets service the provider operates, and make changing a secret easy. The NCSC also advises monitoring access to secrets for anomalous activity. Its action 11 adds that the response to suspicious activity should include changing the secret and invalidating the previous version.
The NCSC sets no change interval, and neither does this guide. Signisys places this step third: you can trim access only once each program has an identity of its own.
Does one application run as its own identity, with no stored password or key in its code or settings? Yes means a search found none.
Cloud Security Best Practices, Steps 4 to 7: Limit What Can Be Reached and Changed
When one mistake or one stolen sign-in happens, these four decide how far it can go.
Key Takeaway Give each identity only the access it needs, close remote doors, automate the rules and keep data only while needed.
Step 4: Trim Access to the Job
Least privilege means an identity can reach only the data and services it needs, when it needs them. Apply permissions to named groups instead of individuals, and keep the configuration easy to understand. For administrators, the NCSC recommends “just in time” administration, which grants the role for a set window, reducing standing privileges. The NCSC also wants unused and unnecessary permissions detected and removed over time. It sets no schedule for this, and neither does this guide.
Start simple and easy to check, then use tooling to make it more granular where needed. External sharing needs the same care, including a view of all of it and a pragmatic approach. The NCSC notes that a blanket ban may force users to use unmanaged shadow IT instead.
Signisys places this step after sign-ins and programs: narrowing access only helps when you know each identity.
Is one administrator role granted for a set window rather than held all the time? Yes means you can show the window.
Cloud Security Best Practices, Step 5: Shield Remote Administration and Internet-Facing Services
Manage access between services, and to untrusted networks, including both inbound and outbound traffic. The NCSC names two common approaches, micro-segmentation and zero trust, and says either one needs least privilege. The zero trust entry explains the second if you want the detail.
Legacy management protocols such as RDP and SSH need particular attention. The NCSC calls them “a common source of cloud breaches” and advises replacing them with cloud-native alternatives. If you must keep them, protect them from untrusted networks, preferably with an administration proxy service that the platform includes, and otherwise with a VPN. Either way, the NCSC says to treat their use as high-risk access.
Signisys places this step mid-way: it limits what an outsider can reach, while the earlier steps decide who may act once inside.
From a network outside yours, does a remote-administration session to one of your own servers fail unless it goes through the proxy or VPN? Run it on a server you own, with its owner’s approval.
Step 6: Let the Platform Enforce the Rules
The NCSC’s action 5 says to run the bulk of your security approach through automation. In practice, that includes guardrails to prevent undesirable changes, autonomous checks, and infrastructure as code for all non-experimental deployments. Infrastructure as code means you define the environment in files and build it from them, instead of setting it up by hand. The NCSC also asks for automated checks of code and configuration before deployment. For the tools that run such checks, a plain comparison of the four kinds of cloud tool sets out what each kind looks at.
If a rule takes direct action, the NCSC says it should have a low false positive rate and clear messaging. Where a significant false positive rate is unavoidable, trigger alerts and investigate before acting. Action 1 adds that using a cloud platform like another data centre is a common cause of breaches. It advises managed services for solved problems, and the lift-and-shift guidance applies if a cloud-native approach is not possible. The NCSC lists preferring serverless and PaaS among its goals; this guide does not require either.
Signisys places this step here: automatic checks need settings that you have decided before they run.
In a test workspace, is the one change your policy forbids blocked or alerted? Yes means you saw the block or the alert.
Cloud Security Best Practices, Step 7: Protect the Data Itself
Protect data at rest using the provider’s data protection systems, and protect data in transit. The NCSC says the provider may enforce this by default, but you may need to enable it using automation. It also asks for appropriate separation between workloads, and for you to manage the provider’s access to your data.
Also know where the provider stores and processes your data, and make sure those places meet your needs. If local rules on data location matter to you, take advice, as this guide makes no claim about them. Finally, keep data in the cloud only while necessary. The NCSC says to use retention policies that delete data once you no longer need it. It adds that breaches include losing data that did not need to sit in the system at all. That makes the impact of compromise larger than it had to be.
Signisys places data after access and rules, while those steps decide who can reach it.
For one data store, can you say where it is held and the date it will be deleted? Yes means both are written down.
Cloud Security Best Practices, Steps 8 to 10: See, Recover and Re-check
These three assume that something will get through, even if the earlier steps hold.
Key Takeaway Keep the activity record, rehearse the restore, and keep checking while the platform changes.
Step 8: Keep Activity Logs Long Enough to Answer Questions
Keep a complete inventory of your resources and their configuration over time, and tag them with metadata such as owner, project and data sensitivity. Collect and combine activity logs from sources such as the provider, every service in use and your own applications. The NCSC wants security activity logs set up so that they “cannot be disabled, deleted, or modified”, with access limited to those who need them. Operations logs need less protection than security logs.
On retention, the NCSC advises storing your most important logs for at least 6 months, noting that detection can take months. It adds that the time may vary by source. Factors include cost, availability of storage, and the volume and usefulness of the data. Treat that as a suggestion from UK guidance, but not as a rule or as advice on Indian rules.
Signisys places this step at the start of the last group: a response needs a record to work from.
Does the oldest activity record you hold reach back at least as far as the period you chose? Yes means you read its date.
Cloud Security Best Practices, Step 9: Plan the Bad Day Before It Comes
Act on the alerts your provider sends, and give it current emergency contacts. The NCSC suggests a group, such as a shared mailbox, instead of named individuals. Back up critical data, including your infrastructure-as-code files. Set up an account recovery process with the provider before you need it, and plan which actions you take and which the provider takes. The incident response entry covers the wider plan if you do not have one.
The NCSC says to test periodically that backed-up data is recoverable and complete. A rebuild from code belongs in the same test. The NCSC also wants you to be able to recreate your environment from backed up infrastructure-as-code documents.
A restore counts as proven only when you write its time down. If it runs slower than the business can wait, that is what the test is there to find.
Have you restored one backup into a clean workspace and rebuilt one workspace from code, with both times written down? Yes means both are recorded.
Cloud Security Best Practices, Step 10: Re-check as the Platform Changes
The NCSC’s action 13 asks for periodic automated tests that your configuration is correct, as well as periodic checks that it meets your needs. It also asks you to keep up to date with new provider security features. It also names two gaps to look for: workspaces missing protections that newly created workspaces get, and changed guardrails that do not reach resources already created. In Principle 14, the NCSC notes that updated defaults may apply only to new accounts.
Include the cloud platform’s configuration when you penetration test the applications built on it. The NCSC adds that a test of the cloud service itself rarely helps and may be limited by the provider’s terms. The NCSC says poor configuration is a common cause of cloud-related data breaches. A penetration test can examine it, and the CSPM entry shows how posture management checks settings automatically. The NCSC sets no interval beyond “periodic”, and neither does this guide.
Signisys closes with this step while the platform keeps changing after you finish the other nine.
Does the oldest workspace have every protection the newest one has, or does each gap have an owner and a date? Yes to either means pass.
What This Guide Does Not Cover, and Where to Go Next
This guide covers the platform and its configuration. It leaves out the services and applications you deploy onto the platform, container and serverless code, provider-specific settings, tool choice, and Indian or GCC rules. The NCSC says you will separately need to consider how you configure the services you deploy. Get specialist help if a check is not possible to run, or if one fails and nobody owns the fix. For the AWS side, an account-by-account list of AWS checks picks up from here.
If you want the reasons behind the steps, see why cloud settings go wrong. A leadership audit list is a different post, while the same idea for an office network is a separate guide. The cloud security entry defines the field, while our page on securing cloud workloads shows the wider use case. This is a starting order of work. When one of your own checks fails, it points to the step to fix.
Signisys helps organizations find, prioritize and reduce security risks, and our VAPT and Cybersecurity Risk Assessment solution includes checks of cloud configuration against secure baselines. We provide this through our Cybersecurity Services page.
Cloud Security Best Practices FAQ
What are the cloud security best practices for a mid-size firm?
Where should a small IT team start?
How do I know a step is working?
Do these steps apply to every cloud provider?
How long should I keep cloud activity logs?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.