We value your privacy

We use cookies to analyze site traffic and improve your experience. You can accept all cookies or reject non-essential ones. See our Privacy Policy for details.

GR IT SERVICES
  • Contact
Get a quote
  2. Audit and compliance
  3. Cloud security posture audit
Cloud security posture audit for US businesses

That subscription somebody spun up for a trial three years ago is still running, still being billed, and nobody has looked at it since.

This kind of audit begins with establishing what actually exists, which is dependably more than whatever the register claims, and then works through configuration, identity, what data is exposed and what gets logged. The widest gap between intent and reality sits in estates assembled piecemeal through a migration, an acquisition, and one team happening to prefer a different provider.

Book a cloud posture auditSee what we examine
Cloud security posture audit for US organizations
  • Inventory firstCIS Control 1, and the usual first finding
  • Azure, AWS, GCPAssessed together rather than separately
  • Identity pathsWho can reach what, including non-humans
  • DriftThe gap between the baseline and today
What we examine

Six areas, and how well you do the first one decides what the other five are worth.

Knowing and controlling what you own is the very first of the CIS Critical Security Controls at version 8.1, and in the cloud it is simultaneously the first thing to establish and the least reliable. Every coverage figure that follows is a percentage of some total, and in most multicloud estates nobody can state that total with any confidence at all.

What exists, across every subscription, account, and project

Subscriptions on Azure, accounts on AWS and projects on Google Cloud, and that includes the ones created for a trial, the ones inherited when you bought a company, and the ones opened on somebody corporate card because a team needed to move quickly one Thursday. The audit starts here because every finding after it carries an implicit caveat about whether the inventory was complete.

Configuration against a recognized baseline

Storage open to the public, databases the internet can reach, encryption never switched on, network controls missing entirely, logging disabled. Where Defender for Cloud is in place, assessing operating system baselines against the cloud security benchmark comes with the second plan, carrying the published caveat that it only covers machines onboarded through Azure Arc.

Identity, including everything that is not a person

Roles at subscription and account level, assignments down at individual resources, trust relationships reaching across accounts, service principals, managed identities, application registrations holding broad consent, and the access keys. Managing accounts and managing access are the fifth and sixth controls, and in the cloud the population that is not human is usually both larger and considerably less governed than the population that is.

Attack paths rather than isolated findings

A publicly readable storage account is a finding. A publicly readable storage account holding a credential that opens a database full of customer records is a path, and those are different things entirely. Where Exposure Management is in use, it pulls signals from Azure, AWS and Google Cloud together with your own hardware through the Defender for Cloud integration, and it is available in the public cloud only.

Data exposure and where the sensitive material actually sits

Protecting data is the third control, and the recurring problem in the cloud is that nothing has ever been classified, so every storage account is treated with identical seriousness, which in practice means none of them is. Working out which stores actually hold material that matters, whether protected health information, consumer personal data or customer financial records, is what turns an undifferentiated list of findings into an ordered one.

Logging, retention, and whether anybody would notice

Managing audit logs is the eighth control. In the cloud the questions are these. Are activity logs on across every single subscription and account. Are they kept long enough to investigate something discovered six weeks after it happened. Can the identity that generated them also delete them. And does anything at all raise an alert on the handful of events that genuinely matter.

The number that is always wrong

Ask how many cloud subscriptions and accounts your company has. Then go and check whether that is true.

Inventory is the first control for a reason, and in the cloud it is far harder than it ever was on your own hardware, because standing up a new environment requires a credit card and about five minutes.

  • Every statement about coverage is a fraction in disguise. Ninety percent of resources compliant. Encryption on across all storage. Logging enabled estate-wide. Each of those is a percentage of something, and that something is the inventory.
  • The cloud makes that denominator unreliable in a way your own data center never did. Nobody buys a physical server without at least one person noticing. A subscription, an account or a project can be created by one individual, paid for from a budget nowhere near IT, and never appear in any register anybody maintains.
  • The usual origins are a trial that quietly became production, an acquisition whose cloud footprint nobody ever counted, a team that opened an account to move faster during a project and never closed it, and accounts a vendor or partner created to host something for you.
  • Establishing the real inventory is the opening phase of the audit and it reliably changes the scope of everything after it. It is also the single finding that improves a company position most permanently, because an environment nobody knows exists cannot be monitored, cannot be patched, cannot be governed and cannot be switched off.
Ask us to establish the real inventory
How we approach it

Four things that make an audit like this produce change rather than a number.

Posture tooling generates findings competently and in enormous volume. What converts findings into improvement is quite different: knowing what you own, giving each environment an owner, prioritizing by what the data actually is, and putting a guardrail in place so the same finding does not come back next quarter.

We establish the real inventory before assessing anything

Through the billing, through the management group and organization structure, through what the identity provider knows, and through network evidence, rather than trusting the register on its own. In a multicloud estate that register is dependably incomplete, and assessing part of an estate produces coverage figures that are technically correct and practically misleading.

We treat non-human identity as the main event

Service principals, managed identities, application registrations holding broad consent, access keys, and roles reaching across accounts. In the cloud these outnumber the people and are governed far less carefully, and they are the population that quietly keeps its privileges long after whatever needed them was decommissioned.

Findings get reported as paths, because isolated ones never get funded

Two thousand misconfigurations in a spreadsheet produces exhaustion and no decisions whatsoever. A handful of paths, each showing how several individually trivial findings chain together into a route to something that genuinely matters, produces action. It is also the only form in which any of this can be explained to somebody who does not work in security.

Every environment gets a named owner before we finish

A subscription, account or project with nobody responsible for it cannot be fixed, cannot be watched and cannot be shut down, and it is reliably the environment holding the worst findings. Assigning ownership is dull work, occasionally political, and the single change most likely to make the second audit considerably shorter than the first.

Where this matters most

Six US situations where a posture audit finds something material.

Almost no cloud estate arrives by design. They accumulate through migrations, acquisitions, projects that were urgent at the time, and individual preference, and each of those four routes leaves behind a different kind of gap.

A group with cloud from three different sources

Azure from the main program, AWS inherited with an acquisition, and Google Cloud because one team preferred working there. Each configured to a different standard by different people at different times, and nobody has ever looked at all three together. Assessing them as a single estate is exactly where the inconsistencies and the forgotten environments come to light.

A regulated firm asked to say where its regulated data actually lives

Organizations covered by HIPAA, firms under GLBA and the FTC Safeguards Rule, and defense contractors facing CMMC all receive the same question dressed in different language: where is the regulated data and who can reach it. Classification is nearly always absent, so every store gets treated the same. Establishing which stores actually hold regulated material and assessing those first is what converts a generic findings list into an answer to the question the assessor genuinely asked.

An organization that has just discovered an unknown subscription

Usually somebody spots an odd line on the bill, or an outsider gets in touch. The pressing question then is what else looks like that, and answering it means working from the billing and the organization structure rather than from the register that already failed to contain the first one. This is the most common reason companies call us about it.

A business that has had a public storage exposure

Either their own, or one they read about happening to somebody else. The audit answers the immediate question and then the considerably more useful one, which is whether that exposure was an isolated mistake or a symptom. Meaning: did a guardrail exist that should have prevented it, and would anything have noticed if it had not.

An operator running production workloads in cloud

Where the cloud is running operational systems rather than only the corporate ones, findings about availability and integrity carry as much weight as findings about confidentiality. Log retention in particular becomes an entirely different question, because an incident touching production may not be investigated for months, and the evidence has to still be there when somebody looks.

An organization preparing for SOC 2 or a customer audit

Assessing against recognized standards is built into the posture tooling, though which standards are available varies by environment. A documented audit with every finding mapped onto whichever framework you are actually measured against, whether SOC 2, the NIST Cybersecurity Framework or HIPAA, puts you in a considerably stronger position than a tool score with nobody interpreting it.

Three positions

How US organizations understand their cloud security posture.

The middle column is common, and it is genuinely better than nothing. A posture tool is running, it produces a score every week, and nobody has ever established whether it covers every environment the company actually operates.
Complete inventory established
Audited across the full estateYes
Posture tool on known subscriptionsAssumed
No posture visibilityNo
Multicloud assessed together
Audited across the full estateYes
Posture tool on known subscriptionsSeparately at best
No posture visibilityNo
Public exposure identified
Audited across the full estateYes
Posture tool on known subscriptionsWithin scope
No posture visibilityNo
Non-human identities reviewed
Audited across the full estateYes
Posture tool on known subscriptionsRarely
No posture visibilityNo
Cross-account trust examined
Audited across the full estateYes
Posture tool on known subscriptionsNo
No posture visibilityNo
Attack paths rather than isolated findings
Audited across the full estateYes
Posture tool on known subscriptionsSometimes
No posture visibilityNo
Logging and retention verified
Audited across the full estateYes
Posture tool on known subscriptionsPartly
No posture visibilityNo
Findings prioritized by data sensitivity
Audited across the full estateYes
Posture tool on known subscriptionsBy severity only
No posture visibilityNo
Owner per environment
Audited across the full estateYes
Posture tool on known subscriptionsNo
No posture visibilityNo
Continuous monitoring afterwards
Audited across the full estateDesigned in
Posture tool on known subscriptionsPartial
No posture visibilityNone
Feature
Audited across the full estate
Posture tool on known subscriptions
No posture visibility
Complete inventory established
YesAssumedNo
Multicloud assessed together
YesSeparately at bestNo
Public exposure identified
YesWithin scopeNo
Non-human identities reviewed
YesRarelyNo
Cross-account trust examined
YesNoNo
Attack paths rather than isolated findings
YesSometimesNo
Logging and retention verified
YesPartlyNo
Findings prioritized by data sensitivity
YesBy severity onlyNo
Owner per environment
YesNoNo
Continuous monitoring afterwards
Designed inPartialNone
The finding categories

Ten categories, and why each one matters.

Grouping findings this way is what makes the output ordered rather than one long undifferentiated list. Mapping onto the CIS Controls at version 8.1 also lets the results feed into a wider control program instead of sitting in a folder by themselves.

Category

Unknown subscriptions, accounts and projects

Why it matters
Everything downstream is a percentage of the inventory
Maps to
Control 1

Category

Publicly exposed storage and databases

Why it matters
The most common route to a cloud data incident
Maps to
Control 3 and Control 4

Category

Missing or misconfigured encryption

Why it matters
Frequently assumed to be on, frequently is not
Maps to
Control 3

Category

Over-privileged identities, human and machine

Why it matters
Service principals and roles that exceed their workload
Maps to
Controls 5 and 6

Category

Standing privilege and long-lived keys

Why it matters
A persistent target rather than a time-bound one
Maps to
Controls 5 and 6

Category

Cross-account and cross-tenant trust

Why it matters
Privilege granted to another environment you may not govern
Maps to
Control 6

Category

Baseline drift

Why it matters
A configuration set once that has moved since
Maps to
Control 4

Category

Logging gaps and short retention

Why it matters
Incidents are discovered weeks after they start
Maps to
Control 8

Category

Unmanaged workloads

Why it matters
Machines outside patching, protection and inventory
Maps to
Controls 1, 2 and 7

Category

Attack paths spanning findings

Why it matters
Individually minor issues that chain into a real route
Maps to
Cross-cutting
CategoryWhy it mattersMaps to
Unknown subscriptions, accounts and projectsEverything downstream is a percentage of the inventoryControl 1
Publicly exposed storage and databasesThe most common route to a cloud data incidentControl 3 and Control 4
Missing or misconfigured encryptionFrequently assumed to be on, frequently is notControl 3
Over-privileged identities, human and machineService principals and roles that exceed their workloadControls 5 and 6
Standing privilege and long-lived keysA persistent target rather than a time-bound oneControls 5 and 6
Cross-account and cross-tenant trustPrivilege granted to another environment you may not governControl 6
Baseline driftA configuration set once that has moved sinceControl 4
Logging gaps and short retentionIncidents are discovered weeks after they startControl 8
Unmanaged workloadsMachines outside patching, protection and inventoryControls 1, 2 and 7
Attack paths spanning findingsIndividually minor issues that chain into a real routeCross-cutting
How an engagement runs

Five steps, and the first one changes the scope.

Three to six weeks as a rule, depending how many environments there are, all delivered remotely. The assessment itself is quick once access exists. Establishing the real inventory and getting owners assigned is where the calendar actually goes.
  1. 1

    Establish the true inventory

    Through the billing, the management group and organization structure, what the identity provider knows, and network evidence, rather than from the asset register. Across multicloud estates this reliably surfaces environments the register never contained, and the result quite often changes the scope of everything that follows.

  2. 2

    Assess configuration across every environment

    What is exposed publicly, what is encrypted, which network controls exist, what workload protection is running, and how far things sit from the baseline. Where Defender for Cloud is present, that includes the compliance assessment and, on the second plan, operating system baseline assessment against the cloud security benchmark, bearing in mind the published requirement that machines be onboarded through Azure Arc for that particular feature.

  3. 3

    Map identity, including everything that is not a person

    Roles at subscription, account and individual resource level, trust reaching across accounts and tenants, service principals, managed identities, application registrations along with whatever consent they hold, and access keys with their ages attached. This section contains the highest severity finding more often than any other, and it is simultaneously the one least likely to have ever been reviewed.

  4. 4

    Assemble paths and prioritize by what the data is

    Trivial findings chained together into routes that reach something worth protecting, ordered by where the sensitive or regulated data genuinely sits rather than by whatever severity label a tool attached. That reordering is precisely what makes the remediation plan fundable and explicable to people outside security.

  5. 5

    Assign ownership and design the guardrails

    An owner against every subscription, account and project. Then policy guardrails that stop the recurring findings at the moment something is created rather than catching them a fortnight later, and continuous monitoring so the next assessment measures what changed instead of repeating this one from scratch.

Straight answers

What organizations ask about cloud posture audits.

Because every other number is a percentage of it. Knowing and controlling what you own is the first of the CIS Critical Security Controls at version 8.1, and the cloud makes that denominator unusually unreliable, since standing up a new environment needs a few minutes and a way to pay. Assess part of an estate and you produce coverage figures that are entirely accurate and thoroughly misleading.

The billing is the most reliable route, because somebody somewhere is paying for all of it. Then the management group, organization and folder structure, the identity provider records showing who holds cloud roles, and network evidence including external discovery for anything facing the internet. Taken together, those consistently turn up more than the register ever held.

All three, and assessing them together rather than one at a time is the entire point. Where Exposure Management is in use it pulls signals from Azure, AWS and Google Cloud together with your own hardware through the Defender for Cloud integration. Where that tooling is not in place, each platform gets assessed natively and the findings are consolidated afterward.

An identity that is not a person holding far more privilege than it needs. Service principals, managed identities and roles created for some workload with broader permission than that workload ever required, still sitting there long after the workload was switched off. They outnumber the people in most cloud estates, almost nobody reviews them, and none of them shows up on a list of directory administrators.

Because two thousand findings in a list produces exhaustion and no decisions at all. A publicly readable storage account is a finding. A publicly readable storage account holding a credential that opens a database of customer records is a path. The second is the only form in which any of this can be explained to the person who has to pay for the fix.

No, and ideally it ends with you buying one. A tool watches continuously and is genuinely worth having. What no tool does is establish whether it is watching every environment you own, assign an owner to anything, prioritize by what the data actually is, or design the guardrails that stop findings recurring. The audit does those four, and the tool then holds the position afterward.

Where Defender for Cloud is in place, assessing operating system baselines against the cloud security benchmark sits on the second plan, carrying the published condition that it only reaches machines onboarded through Azure Arc. That dependency is worth pinning down at the start, because it decides whether the capability covers your whole estate or a fraction of it.

Yes, and the posture tooling carries compliance assessment built in, with which standards are available varying by environment. Findings also get mapped onto the CIS Critical Security Controls at version 8.1 as standard, so that cloud results feed the same control program as everything else you run, and from there into whatever you are actually measured against, whether SOC 2, the NIST framework, HIPAA or CMMC.

Read-only at the highest point available in each: the management group on Azure, the organization on AWS, and the organization or folder on Google Cloud. That is enough to assess without holding any rights to change anything. Where an environment cannot be reached that way we work with whoever does hold access, and an environment nobody at all can grant access to is itself one of the more interesting findings.

Then some of the tooling simply does not apply and the method changes accordingly. Exposure Management, for instance, is available in the public cloud only and not in national or sovereign ones. Establishing which of your environments sit where is part of scoping, because it determines what can be assessed with which tool.

Guardrails that act when something is created rather than detection three weeks later. Policy that refuses public storage, insists on encryption, requires an owner tag before anything is provisioned, and blocks the specific configurations behind your recurring findings. Detection tells you the same thing every quarter forever. Prevention removes the whole category, and that is the difference between a report that shrinks and one that never moves.

Three to six weeks for most companies. The full audit once a year, with continuous monitoring in between, because the estate changes daily and an assessment taken at a moment in time describes exactly that moment. Each engagement is scoped by how many environments and clouds are involved, which is precisely why establishing the real inventory occasionally changes that number after work has started. We say so at the outset rather than treating it as an awkward surprise later, because the environments nobody knew about are the ones most worth assessing.
Before the audit

Fifteen questions that shape the engagement.

The first block is scope and access. The second is what the audit ought to look at first. The third is what happens to the findings afterward, which is the part that decides whether anything actually improves.

Scope and access

  • Which clouds are in use?
    Including ones a single team uses.
  • How many subscriptions, accounts, and projects?
    Then verify the number.
  • Who pays for cloud, and through how many routes?
    Billing finds forgotten environments.
  • Can somebody give us read-only access at the top of the hierarchy?
    Management group, organization, or folder.
  • Is any environment in a sovereign or government cloud?
    Some tooling is public cloud only.

Priorities

  • Where does regulated data live?
    That is where findings matter most.
  • What is internet facing?
    And is that list current.
  • Which workloads are production?
    Tagging is usually incomplete.
  • Is there an existing baseline?
    Drift is measured against something.
  • Which framework are you measured against?
    SOC 2, NIST CSF, HIPAA, CMMC. Findings can be mapped to it.

Afterwards

  • Who owns each subscription or account?
    Unowned environments never get fixed.
  • Is remediation centralized or devolved?
    It changes how findings are packaged.
  • Is posture management tooling in place?
    Continuous beats point-in-time.
  • Who reviews new findings?
    Posture drifts continuously.
  • Is there a guardrail policy?
    Preventing beats detecting.
Related reading

The pages around this one.

Microsoft Defender for Cloud

The posture product that maintains the position between audits.

Learn more

Azure security audit

The Azure-specific engagement in more depth.

Learn more

Defender EASM

External discovery of the internet-facing assets nobody put on the list.

Learn more
Next step

Ask whoever handles the accounts how many cloud vendors show up on the card statements.

It is the quickest available test of whether your cloud inventory is complete, and it routinely surfaces an environment nobody in IT had heard of. That environment is, with dispiriting regularity, the one carrying the worst findings.

Book a cloud posture auditSee the audit practice

Related Services

Explore more solutions that work great with this service

Azure Security Audit

Independent audit of your Azure subscriptions and resources

Learn more

Microsoft 365 Security Audit

Independent Microsoft 365 tenant security audit for US organizations

Learn more

Microsoft Defender

Advanced endpoint and email threat protection

Learn more

Vulnerability Assessment

Vulnerability assessment for US businesses across external attack

Learn more

Zero Trust Architecture Assessment

Your architecture measured against NIST SP 800-207

Learn more
GR IT SERVICES

IT services for US businesses,
delivering enterprise-grade solutions
remotely, coast to coast.

Microsoft CSP PartnerApple Jamf PartnerCISGuard

Microsoft 365

  • Microsoft 365 Administration
  • M365 Reporting & Auditing
  • Microsoft 365 Licensing
  • Microsoft Copilot
  • Microsoft 365 Apps
  • Windows 365 Cloud PC
  • Microsoft SharePoint
  • Outlook & Exchange

Security

  • Microsoft Defender
  • Microsoft Purview
  • Microsoft Intune
  • Microsoft Entra
  • Compliance Manager
  • Cybersecurity Audits
  • Copilot for Security
  • Microsoft Sentinel
  • Microsoft Priva

Infrastructure

  • Google Workspace
  • Cloud Migration Services
  • Data Analytics & BI
  • Active Directory
  • Server Management
  • Apple Business
  • Apple Jamf Pro
  • IP Telephone
  • Data Backup
  • Website Development

IT Services

  • Managed IT Services
  • IT Support USA
  • IT AMC USA
  • New Office IT Setup
  • IT Relocation
  • Remote IT Support
  • On-Call IT Support
  • Startup IT Business Kit
  • Disaster Recovery & BC

Company

  • About Us
  • Careers
  • Contact
  • Blog

Contact

  • hello@gritservices.io
  • gritservices.io

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie PolicyCCPA/CPRA