Saltar al contenido principal
    Skip to main content

    Cloud security audit (AWS, Azure and Google Cloud): what to check

    What to check in AWS, Azure or Google Cloud: your share of the work, access and MFA, public storage, keys, audit logs and open ports. Free guides included.

    By Filip Balik, co-founder · Updated on 19 October 2026

    A cloud security audit checks your side of the deal, not the provider's. AWS, Microsoft and Google protect their data centres, servers and network; your data, your users and how you configure each service are up to you. In practice an audit looks at five areas: identities and MFA, storage open to the internet, keys and secrets, audit logs, and open ports. Each provider's CIS Benchmark is the public checklist to measure against.

    Which part of security is the provider's job and which is yours?

    All three big providers call it the shared responsibility model. AWS sums it up like this: AWS handles security of the cloud (the hardware, software, networking and facilities that run its services) and you handle security in the cloud, meaning whatever you build on top.

    How much falls to you depends on the type of service. With a virtual machine (EC2, in AWS) you manage the operating system, its updates and security patches, any software you install and the security group firewall. With more abstracted services, such as S3 storage or the DynamoDB database, AWS runs the infrastructure, operating system and platform, and you manage your data, the encryption options and the permissions.

    Microsoft sets it out in a matrix. At a glance:

    Area Infrastructure (IaaS) Platform (PaaS) Software (SaaS)
    Customer data You You You
    Configurations and settings You You You
    Identities and users You You You
    Client devices You You Shared
    Applications You Shared Shared
    Network controls You Shared Microsoft
    Operating system You Microsoft Microsoft
    Physical hosts, network and data centre Microsoft Microsoft Microsoft

    In Microsoft's examples, IaaS means Azure virtual machines; PaaS means App Service, Azure Functions or Azure SQL Database; and SaaS means Microsoft 365.

    The first three rows are what matter: your data, your configuration and your users are your responsibility under every model. Google says the same in other words: the provider always remains responsible for the underlying network and infrastructure, and the customer always remains responsible for its access policies and data. Google adds what it calls "shared fate": it commits to secure starting configurations, blueprints and guidance. That helps, but it doesn't change who answers for your configuration.

    So a cloud audit doesn't inspect Amazon's data centres. It checks what your company, your IT provider or a former employee has set up in your account.

    What does a cloud security audit check?

    Five areas, in order of priority, taken from the best practice the providers themselves publish:

    1. Identities and access. Who can sign in, with what permissions, and whether they use MFA.
    2. Storage. Whether any bucket or container can be read from the internet without credentials.
    3. Keys and secrets. Long-term access keys: how many there are, where they live and who holds them.
    4. Audit logs. Whether there is a record of who did what, and for how long it is kept.
    5. Network. Which ports are open to the whole internet, especially remote administration ports.

    The same check has a different name in each cloud:

    What to check AWS Microsoft Azure Google Cloud
    Identities IAM and IAM Identity Center; root user Microsoft Entra ID Cloud Identity or Google accounts; IAM
    MFA enforced by the provider On the root user Portal, CLI, PowerShell and management API Console, in phases by account type
    Public storage S3 Block Public Access Storage account anonymous access Cloud Storage public access prevention
    Free activity log CloudTrail event history, 90 days Activity log, 90 days Admin Activity logs, 400 days
    Automated review Security Hub CSPM Defender for Cloud (free foundational plan) Security Command Center
    CIS guide (October 2026) AWS Foundations 7.1.0 Azure Foundations 6.0.0 GCP Foundation 5.0.0

    Who can sign in, and with what permissions?

    This comes first because almost everything else depends on it: whoever signs in as an administrator can change any other setting, including the ones you check next.

    In AWS, every account starts with a root user that has complete access to everything. AWS strongly recommends not using it except for the few tasks that require it, creating an administrative user for everyday work, and never creating access keys for the root user, because it has full access to all services, billing included. All account types must configure MFA on the root user: if it isn't enabled, it has to be registered within 35 days of the first attempt to sign in to the console. For everyone else, the IAM best practices ask for temporary credentials (federation with an identity provider, or roles) rather than users with long-term keys, phishing-resistant MFA (passkeys and security keys) wherever possible, least-privilege permissions, and regular reviews of unused users, roles and permissions using IAM's last accessed information.

    In Azure, Microsoft has made MFA mandatory for anyone managing resources, in two phases. Since October 2024 it is required to sign in to the Azure portal and the Microsoft Entra and Intune admin centres. Since 1 October 2025 it is also required in the Azure CLI, Azure PowerShell, the mobile app, infrastructure-as-code tools and the management REST API, to create, update or delete resources (not to read them). Organisations with complex environments could postpone the second phase until 1 July 2026 at the latest, so that window has now closed. There is no opt-out, no exception for test environments, and emergency (break-glass) accounts are included. Workload identities (managed identities and service principals) are not affected; if a script signs in with a person's account, Microsoft recommends moving it to a workload identity.

    In Google Cloud, 2-step verification is being made mandatory in phases by account type:

    Account type Required from
    Reseller accounts 28 April 2025
    Personal Google Accounts used in Google Cloud 12 May 2025
    Enterprise Cloud Identity accounts without SSO, in organisations created before 3 August 2026 20 October 2026
    The same, in organisations created on or after 3 August 2026 30 days after the organisation is created
    Enterprise accounts using SSO or federation To be announced

    It applies to the Google Cloud console and the Firebase console, not to the applications you host. If your company signs in with Cloud Identity users and no single sign-on, the change reaches you now.

    What to look at, whichever cloud you use:

    • The full list of people and accounts with administrator rights. Do they all still work for you?
    • MFA on all of them, ideally with a security key or passkey.
    • Accounts belonging to former staff or to suppliers you no longer work with.
    • Scripts and automations that sign in as a person.
    • Broad "just in case" permissions that nobody has trimmed back.

    Is any storage open to the internet?

    A bucket or container that anyone can read is the quickest way for a backup or a folder of invoices to end up public. AWS and Microsoft now block public access by default on new resources, but that doesn't protect what was created earlier or what someone opened later. In Google Cloud, that block has to be switched on.

    • AWS S3. New buckets, access points and objects don't allow public access by default, but users can change policies to allow it. Block Public Access has four settings, and AWS recommends turning all four on for the whole account. Note one detail: these settings don't change existing policies, so if someone removes them, anything with a public policy becomes public again. IAM Access Analyzer for S3 flags buckets open to anyone on the internet or to other accounts.
    • Azure Storage. Anonymous access is prohibited by default. It is controlled by the "Allow Blob anonymous access" setting (the AllowBlobPublicAccess property) on each storage account. If the property comes back blank, Microsoft's bulk remediation script treats that account as one that isn't disallowing anonymous access. One exception: the $web container of a static website is always public.
    • Google Cloud Storage. Public access prevention is switched on per bucket or with the storage.publicAccessPrevention organisation policy. If it isn't set on the bucket or anywhere above it, it doesn't apply.

    In every case the question is whether that bucket should be public. A static website needs it; a payroll folder doesn't. No automated tool can decide that for you.

    Where are the keys and secrets?

    A long-term access key lets in whoever holds it, with no password needed. Google puts it bluntly: to an attacker, a service account key can be even more valuable than a leaked password.

    • AWS: temporary credentials wherever possible. Applications running on EC2 or Lambda receive an IAM role's temporary credentials and need no keys. Where a key is unavoidable (AWS mentions cases such as some WordPress plugins or third-party tools), update it when needed, for example when an employee leaves, and remove unused keys using the last used information.
    • Google Cloud: avoid service account keys and treat them as the exception; never commit them to a code repository (deleting them afterwards isn't enough, because they stay in the history); rotate them; and block their creation with an organisation policy. In organisations created on or after 3 May 2024 that block is enforced by default, along with other policies such as uniform bucket-level access.
    • Azure: a storage account's access keys give access to all of its data, and the Owner and Contributor roles include the permission to retrieve them. Check who holds those roles on accounts that store data.

    What to look for: keys that are months or years old, keys pasted into code repositories or emails, and keys belonging to people who have left.

    Is there a record of who did what?

    If someone deletes a database or opens a bucket, the activity log is the only thing that tells you who did it, when and from where. All three providers keep something free of charge, but not for long, or not everything:

    What it keeps with no setup For how long What it doesn't keep by default
    AWS CloudTrail Management events: creating, changing or deleting resources 90 days, no charge to view Data events, such as reading an S3 object (extra charges apply)
    Azure activity log Management operations 90 days, no charge Resource logs, such as reading a secret or querying a database
    Google Cloud audit logs Admin Activity and System Event logs, which can't be disabled 400 days, not configurable Data Access logs, except for BigQuery

    To keep more, you have to set it up: in AWS, a trail or a CloudTrail Lake event data store; in Azure, a diagnostic setting that sends the log to a Log Analytics workspace or a storage account; in Google Cloud, extend the retention of the project's _Default bucket (30 days by default, configurable up to 3,650) or route logs to another bucket. Microsoft gives a very practical reason: the activity log is the only place that records who created each resource, and it is deleted after 90 days.

    This matters under data protection law. If there is a breach involving personal data, the GDPR (RGPD in Spain) requires you to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it (Article 33.1). Without logs it is very hard to know which data was seen.

    Which ports are open to the whole internet?

    Remote administration ports, SSH (22) and Remote Desktop RDP (3389), open to any address (0.0.0.0/0) are an invitation. Microsoft explains that attackers actively hunt for machines with these ports open, and that a compromised machine becomes an entry point to attack the rest of the environment.

    • Google Cloud: the network called "default" comes with pre-populated firewall rules that allow SSH, RDP and ping from 0.0.0.0/0. They can be deleted or modified, and you should do so if you don't use them.
    • AWS: Security Hub CSPM has two controls for this: no security group should allow ingress from 0.0.0.0/0 or ::/0 to port 22 (EC2.13) or to port 3389 (EC2.14).
    • Azure: Defender for Cloud offers just-in-time virtual machine access, which locks those ports down and opens them only when an authorised person asks, from their address and for a limited time. It is part of Defender for Servers Plan 2.

    What to look for: every inbound rule open to 0.0.0.0/0 and, for each, whether it really needs to be open to the world. Your public website, yes; administrative access to a server, almost never.

    What are the CIS Benchmarks, and which free tools are there?

    The CIS Benchmarks are secure configuration guides from the Center for Internet Security, produced by consensus among cybersecurity experts. There is one per provider, free to download as a PDF for non-commercial use. As of October 2026, the published versions are 7.1.0 for Amazon Web Services Foundations, 6.0.0 for Microsoft Azure Foundations and 5.0.0 for Google Cloud Platform Foundation. They change often: the CIS April 2026 update listed version 7.0.0 for AWS as newly updated, and it is already on 7.1.0. If a report cites an old version, ask why.

    Each provider also has a tool that compares your configuration with best practice:

    • AWS Security Hub CSPM continuously checks your account against AWS's own Foundational Security Best Practices (FSBP) standard and against CIS, among others. The first time you enable it you get a 30-day free trial, although during the trial you pay for other services it uses, such as AWS Config, which most controls need. It only detects findings from the moment you enable it, and for full CIS compliance checks it must be enabled in every Region.
    • Microsoft Defender for Cloud has a free Foundational CSPM plan, with recommendations based on the Microsoft Cloud Security Benchmark and a secure score. It also covers AWS accounts and Google Cloud projects. The paid Defender CSPM plan adds attack path analysis and risk prioritisation.
    • Google Security Command Center has a Standard tier at no additional charge, but misconfiguration detection (Security Health Analytics) isn't supported on new Standard tier activations. Check before you count on it.

    None of these tools replaces the review: they don't know which bucket should be public, which supplier still works with you, or what personal data sits where.

    Is a cloud security audit mandatory?

    No general rule requires a private small business to carry out something called a "cloud audit". But if your cloud holds personal data about customers or staff, the GDPR does require three things an audit helps you prove:

    1. Security measures appropriate to the risk (Article 32.1), including "un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento" (a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures for ensuring the security of the processing; point d). It doesn't say how often or how.
    2. A provider with sufficient guarantees. A cloud provider that stores personal data on your behalf usually acts as a data processor (encargado del tratamiento), and Article 28.1 requires you to use "únicamente un encargado que ofrezca garantías suficientes" (only processors providing sufficient guarantees).
    3. Knowing where the data is. Moving personal data to a third country, outside the European Economic Area, is an international transfer, allowed only if the conditions in Chapter V of the GDPR are met (Article 44 onwards). In the audit, check which Region each resource and each backup sits in.

    If the audit includes a penetration test, read the provider's rules first. The AWS policy, for example, allows testing a list of services without prior approval (EC2, RDS, CloudFront, Lambda, Lightsail and others), but prohibits denial of service, port, protocol or request flooding, and S3 bucket or subdomain takeover.

    How is the audit done, step by step?

    1. Inventory. Every AWS account, Azure subscription and Google Cloud project, including test ones and those opened by someone who has since left. Anything not on the list doesn't get checked.
    2. Read-only access for the auditor. Reviewing doesn't require the power to change anything.
    3. Automated review with the provider's tool, measured against your cloud's CIS Benchmark.
    4. Manual review of what a tool can't know: what should be public, who should have access, and what personal data is where.
    5. A prioritised report. First whatever exposes data or hands over control of the account (administrators without MFA, public buckets, leaked keys); then the rest.
    6. Fix and re-check, to confirm that what was fixed stays fixed.

    At Quantum Nova we carry out these reviews ourselves, without subcontracting, at a fixed price agreed after a free 2 to 5 day assessment. See our cybersecurity audit service.

    Frequently asked questions

    Who is responsible if data is stolen from a misconfigured bucket?

    Under the shared responsibility model of AWS, Microsoft and Google, configuration, data and access are always the customer's responsibility; the provider answers for its infrastructure. If personal data was involved, you will also need to decide whether to notify the breach to the supervisory authority, within 72 hours where feasible (GDPR Article 33.1).

    What is a CIS Benchmark?

    A secure configuration guide published by the Center for Internet Security and produced by expert consensus. There are versions for AWS, Azure and Google Cloud, free as PDFs for non-commercial use. As of October 2026 they are on versions 7.1.0, 6.0.0 and 5.0.0 respectively.

    Is MFA mandatory in Azure and Google Cloud?

    In Azure, yes, for managing resources: since October 2024 in the portal and since 1 October 2025 in the CLI, PowerShell and the management API, with no opt-out. In Google Cloud it is being phased in: for enterprise Cloud Identity accounts without SSO in organisations created before 3 August 2026, from 20 October 2026.

    How long does AWS keep the activity log?

    CloudTrail event history keeps the last 90 days of management events free of charge. To keep them longer you need a trail or an event data store. Data events, such as reading S3 objects, aren't logged by default: you have to enable them separately, and extra charges apply.

    How often should the configuration be reviewed?

    The GDPR asks for "regular" testing without setting a frequency. The providers' tools check continuously; repeat the manual review whenever the people with access, your suppliers or the way your systems are built change.

    Sources

    We check every article against primary sources before publishing it. If you spot a mistake, write to info@quantumnovaagency.com and we will correct it.

    Terms in this article

    Book your free diagnosis.

    Emailinfo@quantumnovaagency.comWhatsApp+34 678 428 710
    LocationTorrevieja (Alicante) · all of Spain

    What happens next

    1. 1We reply within 24 hours.
    2. 2We have a call to look at your case.
    3. 3We send you a proposal with a fixed price.

    By submitting this form you agree to your data being handled under the Privacy Policy.