Requirements · Cloud security
Foundational requirements for securing a cloud account structure
Last updated 25 October 2026 · 3 sources listed · Reading time about 3 minutes
Short answer
A secure cloud foundation separates environments into distinct accounts, protects the top-level identity with strong authentication, centralises identity through a single directory, turns on audit logging in a protected location and sets organisation-wide guardrails. Doing these early is far easier than retrofitting them after teams have built on a flat, shared account.
Who this is for: A founder, architect or IT lead setting up cloud accounts for a growing organisation who wants a sound structure before workloads multiply.
What to evaluate
Account separation
Separate accounts for production, testing and security tooling contain mistakes and limit what a single compromised credential can reach.
How to check: Confirm production workloads sit apart from experiments and that security logs live in a dedicated account.
Protection of the owner identity
The root or owner login has unrestricted power and cannot be limited by normal policies.
How to check: Verify it uses strong phishing-resistant authentication, is rarely used, and its recovery details are held by more than one trusted person.
Central identity and federation
Individual cloud users with separate passwords are hard to remove when people leave.
How to check: Check that staff sign in through the corporate identity provider and that leavers lose access automatically.
Audit logging and retention
Investigations and compliance depend on a complete, tamper-resistant record.
How to check: Verify all regions log control-plane activity to a separate account with restricted deletion rights.
Guardrails and policy baselines
Organisation-level rules prevent dangerous actions even by administrators of individual accounts.
How to check: Review rules that block disabling logging, leaving approved regions or making storage public.
Cost and ownership tagging
Untagged resources have no owner to contact when something looks wrong.
How to check: Require owner and purpose tags and review untagged resources regularly.
Comparison
| Structure | Good when | Watch out for |
|---|---|---|
| Single shared account | A very early prototype with no sensitive data | Mistakes and permissions spill across everything; hard to untangle later |
| Account per environment | A small team with distinct development and production needs | Needs consistent baselines copied to each account |
| Account per workload and environment | Multiple teams or products with differing risk | Management overhead without automation |
| Dedicated security and logging accounts | Any team that must preserve evidence and monitor centrally | Access to these accounts must be tightly limited and reviewed |
Decision worksheet
Rate up to three options against this guide’s own criteria. It runs in your browser and saves only on this device. It is a thinking aid, not a recommendation.
1. Have you checked each criterion?
0 of 6 criteria checked.
2. Compare options (0 = fails or unknown, 3 = meets it well)
| Criterion | |||
|---|---|---|---|
| Account separation | |||
| Protection of the owner identity | |||
| Central identity and federation | |||
| Audit logging and retention | |||
| Guardrails and policy baselines | |||
| Cost and ownership tagging | |||
| Total (max 18) | 0 | 0 | 0 |
Questions to ask before you commit
- Who holds the owner credentials and what is the recovery process if that person is unavailable?
- How are new accounts created, and do they inherit baseline controls automatically?
- Which regions and services are we permitted to use, and how is that enforced?
- How do administrators gain temporary elevated access, and is it recorded?
- Who reviews audit logs and how often?
- How are break-glass accounts protected and tested?
- What is our procedure when a team requests an exception to a guardrail?
Typical trade-offs
Many small accounts versus a few large ones
- Upside
- Smaller accounts limit blast radius and simplify permissions.
- Downside
- More accounts need automation for baselines, networking and cost reporting.
Central platform team control versus delegated team autonomy
- Upside
- Central control keeps standards consistent.
- Downside
- Becomes a delivery bottleneck unless it provides self-service paths.
Restrictive region and service lists versus open choice
- Upside
- Restrictions reduce attack surface and simplify monitoring.
- Downside
- Teams may need exceptions for legitimate needs, so keep the approval route quick.
Common mistakes
- Using the owner login for daily work. Create named administrator roles via your identity provider and lock the owner credentials away.
- Creating cloud users with separate passwords for each person. Federate with your directory so offboarding is a single action.
- Leaving audit logs in the same account as workloads. Send them to a protected account with deletion limited to a very small group.
- Postponing guardrails until later. Retrofitting rules onto working systems triggers disruption and delay.
- Not testing emergency access. A break-glass account that nobody has tried may fail when needed most.
Related questions
Why not just use one cloud account for everything while we are small?
It is cheaper to start but expensive to unpick. Permissions, networking and billing get entangled, so separating production later often needs careful migration. A small, simple multi-account structure costs little effort if started early: one for production, one for non-production and one for logs and security. Even tiny teams benefit because an experiment gone wrong cannot reach customer data, and an auditor or insurer can see a clear boundary.
How should we protect the owner or root login?
Use a unique long credential stored in a secure vault, enable the strongest authentication option available, preferably a hardware-backed method, and avoid day-to-day use. Register contact details on a shared role mailbox rather than one person's inbox, and document how recovery works with at least two trusted holders. Monitor and alert on any login to it. The aim is that it exists for rare tasks and any use is noteworthy.
What are guardrails in practice?
They are organisation-level rules that apply regardless of what account administrators try to do. Examples include preventing audit logs from being switched off, blocking deployment outside approved regions, denying public access to storage and requiring encryption. They complement, rather than replace, per-account permissions. Introduce them in monitoring-only mode where possible, learn what legitimate activity they would block, then enforce with a documented exception route.
How often should cloud access be reviewed?
Review privileged access at regular intervals, commonly quarterly for administrators and less often for routine roles, and on every significant organisational change. Use access analysis features to see which permissions have not been used and remove them. Pair this with automatic removal when staff leave or change teams. Record the review outcome so you can show an auditor or insurer that access is checked and acted on rather than accumulating indefinitely.
Sources and further reading
These pages were reachable when we last checked. They informed definitions and rules referred to above; they do not endorse this guide. Where rules differ by country, check the authority for your location.
- Cloud security guidance — National Cyber Security Centre (UK), retrieved 27 October 2026
- Cloud Security Technical Reference Architecture — Cybersecurity and Infrastructure Security Agency, retrieved 27 October 2026
- NIST Cybersecurity Framework — National Institute of Standards and Technology, retrieved 27 October 2026
Related guides
How to choose · Cloud security
How to choose cloud security posture and workload protection tooling
Choose cloud posture tooling by how well it prioritises findings, how it reaches your accounts without excessive permissions, and how it hands work to engineers. Check multi-cloud coverage, identity analysis, infrastructure-as-code scanning and exception handling. A tool that lists thousands of unranked issues creates fatigue; context about reachability and privilege is what makes findings actionable.
Comparison · Cloud security
Cloud provider native security vs third-party tools and the shared responsibility split
Cloud providers secure the underlying infrastructure, while customers remain responsible for identities, configuration, data and applications. Native services are deeply integrated and often sufficient for a single cloud. Independent tools add consistency across providers and separation from the platform you are monitoring. The decision hinges on estate size, number of clouds and the skills you have to run each layer.
Problems & fixes · Cloud security
Common cloud misconfigurations and how to fix them
Most cloud exposure comes from a short list of recurring mistakes: publicly reachable storage, overly broad permissions, long-lived access keys, disabled logging, open administrative ports and unprotected secrets in code. Fix them by inventorying accounts, restricting identities, enabling audit logs, then using templates and guardrails so the same errors cannot return.
Requirements · Artificial intelligence
Requirements before giving an AI agent access to company systems
Before granting access, you need a defined task and owner, dedicated low-privilege credentials, a data classification of everything reachable, approval rules, logging with retention, a tested stop procedure, and agreement on who answers for outcomes. Without these, the agent inherits the access of whoever set it up, and nobody can reconstruct what it did.
Cost factors · Endpoint protection
What drives the cost of endpoint protection
Endpoint protection cost depends on device count, which capability tier you license, data retention, any managed monitoring, and the staff time required to run it. Quotes that look similar can hide different definitions of a device, different support levels and add-on modules. Compare total operating effort, not only the licence line.
Requirements · Artificial intelligence
Security and governance requirements for workflow automation
Treat the platform as a privileged system. Require single sign-on and role separation, scoped service connections instead of personal logins, secret storage you can audit, restrictions on which data may flow through it, run-log retention limits, change review for important flows, and an inventory with named owners. Without these, automations become unmanaged paths around your normal controls.
How to choose · Identity and access
How to choose a single sign-on and identity provider
Choose an identity provider by checking which of your applications support standard federation, how provisioning and deprovisioning work, what authentication methods and policies are available, and how the provider behaves when it fails. The directory you already run, the number of unsupported legacy apps, and your admin capacity shape the best fit more than feature lists do.