We value your privacy

We use cookies to analyse 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, UAE

The subscription somebody created for a proof of concept in 2022 is still running, still paying, and nobody is watching it.

A cloud posture audit starts with what exists, which is reliably more than the register says, then examines configuration, identity, data exposure and logging. Multicloud estates assembled through migration, acquisition and one team preference are where the gap between intent and reality is widest.

Book a cloud posture auditSee what we examine
Cloud security posture audit for UAE organisations
  • 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 the first one determines the value of the other five.

Inventory and control of enterprise assets is control 1 in the CIS Critical Security Controls at version 8.1, and in cloud it is both the first area and the least reliable. Every coverage figure downstream is a percentage of a total, and in most multicloud estates nobody can state that total with confidence.

What exists, across every subscription, account and project

Azure subscriptions, Amazon Web Services accounts and Google Cloud projects, including the ones created for a proof of concept, inherited through an acquisition, or opened on a corporate card by a team that needed something quickly. The audit begins here because every subsequent finding is qualified by whether the inventory is complete.

Configuration against a recognised baseline

Storage exposed publicly, databases reachable from the internet, encryption not enabled, network controls absent, logging disabled. Where Microsoft Defender for Cloud is in use, operating system baseline misconfiguration assessment against the Microsoft Cloud Security Benchmark is available in Plan 2, with the published caveat that it applies only to machines onboarded with Azure Arc.

Identity, including everything that is not a person

Subscription and account level roles, resource level assignments, cross-account trust relationships, service principals, managed identities, application registrations with high consent, and access keys. Account management and access control management are controls 5 and 6, and in cloud the non-human population is usually larger and less governed than the human one.

Attack paths rather than isolated findings

A public storage account is a finding. A public storage account holding credentials that grant access to a database containing customer data is a path. Microsoft Security Exposure Management, where in use, aggregates signals from Azure, Amazon Web Services and Google Cloud Platform alongside on-premises through the Defender for Cloud integration, and it is available in public cloud only.

Data exposure and where the sensitive material actually sits

Data protection is control 3, and in cloud the recurring problem is that nobody has classified anything, so every storage account is treated with equal seriousness and therefore none of them are. Establishing which stores hold material that matters converts an undifferentiated findings list into a prioritised one.

Logging, retention and whether anybody would notice

Audit log management is control 8. In cloud the questions are whether activity logs are enabled across every subscription and account, whether they are retained long enough to investigate an incident discovered weeks later, whether they are protected from deletion by the identity that generated them, and whether anything alerts on the events that matter.

The number that is always wrong

Ask how many cloud subscriptions and accounts you have. Then verify it.

Inventory is control 1 for a reason, and in cloud it is harder than on-premises because creating a new environment takes a credit card and five minutes.

  • Every coverage statement is a fraction. Ninety percent of resources compliant, encryption enabled on all storage, logging on across the estate. Each of those is a percentage of a denominator, and the denominator is the inventory.
  • Cloud makes the denominator unreliable in a way that on-premises does not. Nobody procures a server without somebody noticing. A subscription, an account or a project can be created by an individual, funded outside IT, and never appear in any register.
  • The usual sources are proof of concept work that became production, acquisitions whose cloud footprint was never enumerated, a team that opened an account to move faster during a project, and vendor or partner accounts created to host something on your behalf.
  • Establishing the true inventory is the first phase of the audit and it consistently changes the scope. It is also the finding that most improves the organisation position permanently, because an environment nobody knows about cannot be monitored, patched, governed or shut down.
Ask us to establish the real inventory
How we approach it

Four things that make a cloud audit produce change rather than a score.

Posture tooling produces findings competently and in volume. The work that turns findings into improvement is inventory, ownership, prioritisation by what the data actually is, and a guardrail so the same finding does not return.

We establish the real inventory before assessing anything

Through billing routes, management group and organisation structure, identity provider records and network evidence rather than through the register alone. In multicloud estates the register is reliably incomplete, and assessing a partial estate produces coverage figures that are technically accurate and practically misleading.

We treat non-human identity as the main event

Service principals, managed identities, application registrations with high consent, access keys and cross-account roles. In cloud these outnumber human identities and are less governed, and they are the population that quietly retains privilege long after the workload that needed it was decommissioned.

We report paths, because isolated findings do not get funded

A list of two thousand misconfigurations produces triage fatigue and no decisions. A small number of paths, each showing how individually minor findings chain into a route to something that matters, produces remediation. That is also the form in which a finding can be explained to somebody outside the security team.

We assign an owner to every environment before we leave

An unowned subscription, account or project cannot be remediated, monitored or decommissioned, and it is the environment most likely to hold the worst findings. Assigning ownership is unglamorous, occasionally political, and the single change most likely to make the second audit shorter than the first.

Where this matters most

Six UAE situations where a posture audit finds something material.

Cloud estates rarely arrive by design. They accumulate through migration, acquisition, project urgency and individual preference, and each of those routes leaves a different kind of gap.

A group with cloud from three different sources

Azure from the main programme, Amazon Web Services from an acquisition, and Google Cloud because one team preferred it. Each was configured to a different standard by different people, and nobody has ever assessed them together. Assessing them as one estate is where the inconsistencies and the forgotten environments surface.

A regulated firm asked where its regulated data sits in cloud

Data protection is control 3 and the practical difficulty is that classification is usually absent, so every store is treated identically. Establishing which stores hold regulated material, and then assessing those first, converts a generic findings list into an answer to the question the regulator actually asked.

An organisation that has just discovered an unknown subscription

Usually through a billing anomaly or an external notification. The immediate question is what else is like that, and answering it requires working from billing routes and organisation structure rather than from the register that already failed to contain this one. It is the most common trigger for this engagement.

A business that has had a public storage exposure

Whether their own or a widely reported one elsewhere. The audit answers both the immediate question and the more useful one, which is whether the exposure was a mistake or a symptom, meaning whether guardrails exist that would have prevented it and whether anything would have detected it.

An operator running production workloads in cloud

Where cloud hosts operational systems rather than only corporate ones, availability and integrity findings matter as much as confidentiality ones. Logging retention in particular becomes a different question, because an incident affecting production may be investigated months later and the evidence must still exist.

An organisation preparing for a certification or a customer audit

Regulatory compliance assessment against recognised standards is available within cloud posture tooling, with different standards available for different environments. A documented audit with findings mapped to the framework you are measured against is a considerably stronger position than a tool score with no interpretation behind it.

Three positions

How UAE organisations understand their cloud security posture.

The middle column is common and better than nothing. A posture tool is deployed, it produces a score, and nobody has established whether it covers every environment the organisation actually runs.
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 prioritised 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 prioritised 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.

This is how findings are grouped so the output is prioritised rather than a flat list. Mapping to the CIS Controls at version 8.1 lets the results feed a wider control programme rather than sitting alone.
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.

Typically three to six weeks depending on the number of environments. Assessment is fast where access exists. Establishing the true inventory and assigning ownership is where the time goes.
  1. 1

    Establish the true inventory

    Through billing routes, management group and organisation structure, identity provider records and network evidence, rather than from the asset register. In multicloud estates this consistently finds environments the register does not contain, and the result frequently changes the scope of the rest of the engagement.

  2. 2

    Assess configuration across every environment

    Public exposure, encryption, network controls, workload protection state and baseline conformance. Where Defender for Cloud is available, regulatory compliance assessment and, in Plan 2, operating system baseline assessment against the Microsoft Cloud Security Benchmark, noting the published requirement that machines are onboarded with Azure Arc for that feature.

  3. 3

    Map identity, including everything that is not a person

    Roles at subscription, account and resource level, cross-account and cross-tenant trust, service principals, managed identities, application registrations and their consent, and access keys with their age. This is the section that most often contains the highest-severity finding and the one least likely to have been reviewed.

  4. 4

    Assemble paths and prioritise by what the data is

    Individually minor findings chained into routes that reach something that matters, prioritised by where sensitive or regulated data actually sits rather than by severity label alone. That reordering is what makes the remediation plan fundable and explicable outside the security function.

  5. 5

    Assign ownership and design the guardrails

    An owner for every subscription, account and project. Then policy guardrails that prevent the recurring findings at creation rather than detecting them afterwards, and a continuous posture monitoring arrangement so the next assessment is a delta rather than a repeat of this one.

Straight answers

What organisations ask about cloud posture audits.

Because everything else is a percentage of it. Inventory and control of enterprise assets is control 1 in the CIS Critical Security Controls at version 8.1, and cloud makes the denominator unusually unreliable because creating a new environment takes minutes and a payment method. An assessment of a partial estate produces coverage figures that are accurate and misleading.

Billing routes are the most reliable, because somebody pays for everything. Then management group, organisation and folder structure, identity provider records showing which accounts have cloud roles, and network evidence including external discovery for anything internet-facing. The combination consistently finds more than the register contains.

Yes, and assessing them together rather than separately is the point. Microsoft Security Exposure Management, where in use, aggregates signals from Azure, Amazon Web Services and Google Cloud Platform alongside on-premises through the Defender for Cloud integration. Where such tooling is not in place we assess each natively and consolidate the findings.

Over-privileged non-human identity. Service principals, managed identities and roles created for a workload with more permission than the workload needed, retained long after the workload was decommissioned. They outnumber human identities in most cloud estates, they are almost never reviewed, and they do not appear in a directory administrator list.

Because a list of two thousand findings produces triage fatigue and no decisions. A public storage account is a finding. A public storage account holding credentials that reach a database of customer data is a path, and it is the form in which a security issue can be explained to somebody who has to fund the fix.

No, and ideally it leads to one. A tool provides continuous detection and is genuinely valuable. What it does not do is establish whether it is watching every environment, assign ownership, prioritise by what the data actually is, or design the guardrails that prevent recurrence. The audit does those, and the tool then maintains the position.

Where Microsoft Defender for Cloud is in use, operating system baseline misconfiguration assessment against the Microsoft Cloud Security Benchmark is a Plan 2 capability, with the published condition that it applies only to machines onboarded with Azure Arc. That Arc dependency is worth establishing early, because it determines whether the capability covers your estate or part of it.

Yes, and cloud posture tooling includes regulatory compliance assessment with different standards available for different environments. We also map findings to the CIS Critical Security Controls at version 8.1 by default, so that cloud results feed the same control programme as the rest of the estate rather than sitting in a separate report.

Read-only at the highest level available, meaning management group in Azure, organisation in Amazon Web Services and organisation or folder in Google Cloud. That allows assessment without change rights. Where an environment cannot be accessed that way, we work with whoever holds access, and an environment nobody can grant access to is itself a finding.

Three to six weeks for most organisations. Assessment moves quickly once access is in place. The variable is establishing the true inventory and attributing ownership to each environment, both of which require people rather than queries and both of which are where the durable value is.

Then some tooling does not apply and the assessment method changes. Microsoft Security Exposure Management, for example, states that it is available in public cloud only and not in national or sovereign clouds. Establishing which environments sit where is part of the scoping, because it determines what can be assessed with which tools.

Guardrails at creation rather than detection afterwards. Policy that prevents public storage, requires encryption, requires tagging with an owner, and blocks the configurations that produce the recurring findings. Detection tells you the same thing every quarter. Prevention removes the category, and it is the difference between a shrinking report and a stable one.

Somebody in the business area that uses it, not the cloud platform team. An unowned environment cannot be remediated, monitored or decommissioned, and it is reliably where the worst findings sit. Assigning ownership is occasionally political and it is the change most likely to make the next audit shorter than this one.

The full audit annually, with continuous posture monitoring between. The estate changes daily, so a point-in-time assessment describes a point in time. What the annual audit adds over the tool is the inventory verification, the ownership review, the path analysis and the guardrail assessment, none of which a tool performs on its own.

Where it exists, yes, and it is the more durable place to fix a finding. A misconfiguration corrected in a running resource returns at the next deployment if the template that created it is unchanged. Assessing the templates and pipelines alongside the live estate means findings can be closed at source, and it also reveals where the running estate has drifted from what the code says it should be.

Not as the objective, and it frequently emerges anyway. Environments nobody owns, resources running with no workload, and subscriptions from projects that ended are security findings and cost findings simultaneously. We report them as security findings because that is the engagement, and we note the commercial dimension because it is usually the argument that gets the environment decommissioned rather than merely documented.

We scope by the number of environments and clouds in scope, which is why establishing the true inventory sometimes changes the number after we start. We are explicit about that at the outset rather than treating a scope change as a surprise, because the environments nobody knew about are precisely the ones most worth assessing.

A penetration test asks whether somebody outside can get in. A posture audit asks whether the configuration would let them once they did, and whether anybody would notice. They answer different questions and the posture work is usually the cheaper one to act on, because the findings are configuration rather than code.

Then consistency is the finding. Each provider has its own defaults, its own identity model and its own logging behaviour, and organisations reliably apply a standard properly in the provider they know best. Auditing them to the same standard is what reveals which one is carrying the risk.
Before the audit

Fifteen questions that shape the engagement.

The first group is scope and access, the second is what the audit should prioritise, and the third is what happens to the findings, which determines whether posture 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 we get read-only access at the top level?
    Management group, organisation, or folder.
  • Is any environment in a sovereign 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?
    Findings can be mapped to it.

Afterwards

  • Who owns each subscription or account?
    Unowned environments never get fixed.
  • Is remediation centralised 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.

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

Security Exposure Management

Attack paths and choke points across cloud and on-premises together.

Learn more
Next step

Ask finance how many cloud vendors appear on the card statements.

It is the fastest way to test whether your cloud inventory is complete, and it routinely finds an environment nobody in IT knew existed. That environment is almost always the one with the worst findings.

Book a cloud posture auditCall +971 56 613 2743

Related Services

Explore more solutions that work great with this service

Defender for Cloud

Azure posture, and the free tier almost nobody has enabled

Learn more

Azure Security Audit

Subscription audit, starting with the free tier you already own

Learn more

Security Exposure Management

Choke points where many attack paths converge

Learn more

Defender for Servers

Plan 1 versus Plan 2, and the Azure Arc dependency

Learn more

Azure Key Vault

Secrets, keys and certificates out of config files

Learn more

CIS Controls Assessment

Eighteen controls, assessed and re-assessed

Learn more

IT Audit Services Dubai

Assessment, technical test or certification, scoped properly

Learn more

Defender EASM

Discovers internet-facing assets you never registered

Learn more
GR IT SERVICES

Leading IT services provider in Dubai,
delivering enterprise-grade solutions
for businesses across the UAE.

Microsoft CSP PartnerCISGuard

Get the Helpdesk app

Raise and track IT tickets from your phone.

Download on the App StoreGet it on Google Play
Learn more about the app

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 Dubai
  • IT AMC Dubai
  • 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

  • Iris Bay Tower, Office 903,
    Business Bay, Dubai, UAE
  • +971 56 613 2743
  • hello@gritservices.ae
  • gritservices.ae

© 2026 GR IT Services. All rights reserved.

Privacy PolicyTerms of UseCookie Policy