Cloud security risks in a firm of your size come down to three questions about each resource. Who can reach it, who can change it, and who owns it? This guide is for an IT manager, IT head or owner in India or the GCC who runs workloads in a public cloud. It helps you see which risks could be true in your own accounts. In this guide, a risk is what could go wrong. A cloud security issue is a risk that is already true in one of your accounts, with a setting you can point to. It explains the causes instead of the fixes. For how people define and rank risk in general, see our plain-words guide to cyber security risk.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Security Risks in Short: Reach, Change and Ownership
Every risk in this guide traces back to a setting or a person. When you ask three questions of each resource, write down any answer you can’t give.
Key Takeaway Ask three questions of every cloud resource: who can reach it, who can change it, and who owns it. A misconfiguration is a setting that differs from what you meant, and it sits behind a wrong answer to one of the three.
The cloud security issues a review turns up trace back to one of these questions. Below, a table pairs each with the misconfiguration behind it.
| The question | What goes wrong | The misconfiguration behind it |
|---|---|---|
| Who can reach it | When something meant for staff opens to the internet, outsiders can reach it. | A storage container, database or admin page sits open to the public, while a path opened for a quick job stays open. |
| Who can change it | When a person or program can do more than the job needs, one mistake reaches further. | Permissions grew one request at a time, a service credential stays valid indefinitely, or a hand-made change left no record. |
| Who owns it | When nobody owns a resource, nobody notices that it drifts. | An account has no owner and no logging, or it holds older default settings than newer accounts. |
The grouping is Signisys’ own method, built on NCSC and NIST statements, and it isn’t a standard. Each section below also names the source behind its cause.
Who Answers for What in the Cloud
You and the provider each answer for part of the security. Where the line falls depends on the service you use.
The NCSC’s principle on secure use of the service is UK guidance that the NCSC reviewed on 7 June 2023. It speaks to cyber security professionals, large organisations, small and medium-sized organisations and the public sector. The configuration of the cloud services you use remains your responsibility, it says. That holds even if your provider embraces a secure by default approach. It adds that you stay responsible for some aspects of the security of your data. How much depends on the service, and also on how you use it.
NIST SP 800-144 is US guidance from December 2011, for system managers, executives and security professionals. It says the responsibilities of each side vary with the service model. Ultimately, it adds, the organization is accountable for the choice of public cloud. It is also accountable for the security and privacy of the outsourced service. This is 2011 guidance, but this guide uses it for that principle only.
The NCSC makes one more point about defaults. It says some platforms apply newer, safer default settings only to new accounts or tenants, and it names none. For you, this means an older account may hold older settings than a new one. The NCSC advises reviewing your existing configuration against the platform’s good-practice guides.
Key Takeaway You and the provider each answer for part of the security, and the configuration of the services you use stays with you.
For the model itself, see the fuller explanation of the shared responsibility model.
Cloud Security Risks by Cause, 1: Who Can Reach It
The first group is anything that someone outside your intended audience can reach. A public storage container is a cloud security issue only if nobody meant it to be public. That is why the question is “could I explain this?” and not “is this public?”.
Exposed data. Storage, databases and copies of production data kept in test systems. In our reading, someone can open one for a deadline and leave it open when the job ends and nobody closes it.
Open network paths and admin interfaces. NCSC principle 11 (UK) lists APIs, web consoles and command-line interfaces among the interfaces to know about. It wants the provider to show which of them face the internet, and which of those have no authentication. Each of these cloud security risks comes down to a setting that someone chose or left alone.
Sign-in and keys. A service credential is a key that a program uses instead of a person’s password. NCSC principle 10 wants the provider to rotate and revoke service credentials so that none stays valid indefinitely. It also wants user credentials tied to joiners, movers and leavers processes, to reduce the likelihood of leavers keeping working credentials. In our reading, a key made for a job that has ended is easy to forget when nobody owns it.
If I listed everything reachable from the internet, could I explain each item?
Cloud Security Risks by Cause, 2: Who Can Change It
The second group is about power. If a person or program can change more than its job needs, one stolen password or one mistake reaches further than it should.
Over-wide permissions. Least privilege means a role keeps only the access its job needs. NCSC principle 9 (UK) describes it. It wants the provider to supply tools that identify and remove permissions you no longer need. A cloud security issue of this kind can build up one approved request at a time. Each request is easy to grant and easy to forget.
Changes made by hand. NCSC principle 14 wants configuration that you can set and audit with infrastructure as code, or through an API. Principle 13 also wants audit information that records configuration changes. In our reading, a setting changed by hand in a console can fall outside both. That makes it harder to tell who did it, or why.
Machine access. Programs also hold identities. NCSC principle 10 wants service identities to get equally robust authentication as users do. A program with broad permissions raises the same question as a person with them. In our reading, these cloud security risks are easy to miss when a program does not ask for access in a meeting.
Before I trust this setting, can I see who changed it last?
Cloud Security Risks by Cause, 3: Who Owns It
The third group, unlike the first two, is about attention. Something can work well on the day you build it and still drift, if nobody looks after it.
Accounts nobody watches. NCSC principle 14 wants a single place where you can see all of your deployed resources. If you can’t list your accounts and their owners, you can’t review them. A cloud security issue in this group can sit unnoticed when no one owns the account.
No logs, no way to tell what happened. NCSC principle 13 (UK) wants audit information that records creating, changing and deleting resources, configuration changes and sign-in events. It also wants you to know how long it keeps that information. If it is missing, you can’t say how or when something happened.
Shadow data and services. In our reading, copies of data and small services set up outside IT’s view belong here too. No source we read covers them, so treat this as a prompt to ask, not a finding.
Continuous checks of settings against a baseline are what a cloud security posture management tool does. How posture management finds drift has its own page. The risks in this group also come down to a setting: a setting with no owner is less likely to draw questions, in our reading.
If an account looked wrong tomorrow, who would hear about it?
Cloud Security Risks Check: Five Questions for Your Own Account
These five questions are Signisys’ own working test, built on the three causes and the NCSC goals above. They are not a standard or a scan. Run them against one account before the rest. Log what the answers turn up as cloud security issues, each with an owner and a date.
Can you list every account and name its owner? A good answer names an owner for each.
Can you list what the internet can reach and explain each item? A good answer gives each item a reason and a person who vouches for it.
Can you name who holds the broadest permissions and what job each covers? A good answer ties each one and each service credential to a named person.
Pick one setting and find the record of who changed it last. A good answer shows a name, a time and the change.
Can you say how long you keep the change record, and who can switch it off? A good answer is a known retention period, with no everyday role able to delete or disable it.
Platform-specific checks are outside this guide. If a question has no answer, or an answer shows data open to the internet, ask for a review. For AWS, a worked list of AWS account checks covers the platform-specific side.
What the Sources Do Not Tell You, and Where to Go Next
As of November 2026, the pages we read name several causes of cloud breaches but do not say which is largest. The NCSC’s guidance on using a cloud platform comes from the UK. The NCSC published and reviewed it on 7 June 2023, for cyber security professionals, large organisations, small and medium-sized organisations and the public sector. It calls poor authentication practices “one of the most common causes of breaches in cloud platforms”. It also calls legacy management protocols such as RDP and SSH “a common source of cloud breaches”, and using a cloud platform like another data centre “a common cause of breaches”. The same guidance has a note on penetration testing applications built on the cloud. There the NCSC says poor configuration is “a common cause of cloud-related data breaches”.
No source we read says which cause is largest. The NCSC gives no figure, and NIST SP 800-144 ranks nothing. This guide therefore carries no figures and does not rank the causes. It also makes no claim about Indian or GCC rules, and it gives no fixes, product checks or tool comparison.
Vendor pages we read give figures that disagree, and we could not trace them to a primary report.
Guides That Cover the Fixes
This guide stops at causes, but other guides in this set cover the fixes and tool choice. The control checklist for CISOs lists the controls, and the secure cloud workloads page shows the service view.
Signisys provides vulnerability assessment and penetration testing and security risk assessment for growing firms. Our VAPT and Cybersecurity Risk Assessment solution and Cybersecurity Services page set this out. The decisions on each finding stay with your own team.
Cloud Security Risks FAQ
What are the main cloud security risks for a mid-size firm?
What counts as a cloud security issue rather than a risk?
Is the cloud provider responsible for securing my accounts and data?
Is misconfiguration the biggest cloud security risk?
How can I tell whether my own accounts have these problems?
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.