Cloud security is its own purchase, and treating it as a sub-heading of cybersecurity is how organizations end up compliant on paper and exposed in practice. Cloud security consulting answers a narrower question than a general security review: your data and workloads now run on infrastructure you do not own, under a shared responsibility model most teams have never actually read, inside a regulatory perimeter that cares a great deal about where that infrastructure physically sits. TrustAngle advises on that question independently - we carry no cloud reseller margin, so the hosting model we recommend is the one your data classification allows, not the one that pays us best.
Most security programmes in the Kingdom were designed for an estate the organization owned end to end: its own data centre, its own network perimeter, its own hardware. That assumption still sits underneath a lot of security assessments. The moment a workload moves onto a public or hybrid cloud platform, three things change that a general review is not structured to catch - and each of them is a place where an otherwise well-run security function can still fail an audit.
Every cloud platform splits responsibility between the provider and the customer, and the split differs between infrastructure, platform and software services. The provider secures what it runs; configuration, identity, data protection and usually logging stay with you. Teams routinely assume the platform covers more than it does, and a regulator will hold the organization accountable for its own side of that line regardless of what the sales conversation implied. Reading the boundary properly, service by service, is the first thing an assessment does.
On premises, where data physically lives is a facilities decision. In cloud it is a regulatory one. Region selection, replication targets, backup destinations and which support engineers can reach a system from outside the Kingdom are all compliance-relevant now, and the real answers are often not the ones on the architecture diagram. Backups and disaster-recovery copies are the recurring surprise: the primary workload sits exactly where it should, and a replica of it does not.
Teams looking for NCA ECC cloud controls usually find more than one document and assume the newer one supersedes the rest. It does not work that way. The Essential Cybersecurity Controls set the baseline expectation for an organization's cybersecurity as a whole; the National Cybersecurity Authority's cloud cybersecurity controls sit on top of that baseline for cloud - and, the part that catches people out, they place obligations on the organization consuming the service, not only on the provider selling it. Having been assessed against one is not evidence for the other.
If your question is enterprise-wide rather than cloud-specific - governance, threat exposure, remediation planning across the whole estate - IT security consulting is the better place to start. The two engagements are frequently run together, and we will tell you which one your question actually belongs to before either is scoped.
A cloud security assessment is a structured read of your live cloud estate against the controls you are genuinely held to, ending in a prioritised plan rather than a findings dump. It is scoped against what is actually deployed today, including the workloads that never made it onto the architecture diagram.
We map what is running where, across every platform, subscription and account in use, and set that against the responsibility split for each service consumed. The output names, service by service, who holds each control - you, the provider, or nobody. The third case is the finding that matters most, and it is the one no single party is incentivised to look for.
Controls follow classification. A hosting model cannot be judged until the data inside it has been classified against the national data management standards, and that classification has to be applied to real datasets rather than declared in a policy nobody has mapped to a system. We work through the datasets that actually carry a constraint - personal data, financial records, anything the sector regulator names - and establish what each one permits.
Most cloud incidents are access incidents: an over-privileged role, a service account nobody owns, a key issued for a migration and never revoked, administrative access with no second factor. We review privileged access, federation with your existing identity provider, and who actually holds the encryption keys - including whether the provider is technically able to read data you believe is protected from them.
An auditor asks for evidence, not intent. We check that the logs a control depends on are being collected, retained for the period required of you, and retrievable by someone other than the engineer who built the system. We separately flag the controls you meet in practice but cannot currently prove, because that gap is cheap to close and expensive to discover during an audit.
Saudi cloud requirements come from more than one authority, and the overlap between them is where most of the confusion sits. The short version: the National Cybersecurity Authority sets the security controls, the national data governance and personal data protection regime governs how data is classified and what may leave the Kingdom, and a sector regulator - in banking, health or government - frequently adds conditions of its own on top. An engagement has to satisfy all of them at once, which is why sequencing the work matters more than throwing effort at it.
What clients call SDAIA cloud compliance is usually two separate obligations wearing one name. The first is data classification and management under the national data governance standards - knowing what you hold, at what sensitivity, and applying the handling rules that follow from that. The second is the personal data protection regime, which constrains transferring personal data outside the Kingdom and expects a lawful basis for processing it at all. They are assessed differently and remediated differently, and collapsing them into a single compliance workstream is a common reason programmes stall halfway.
Our cloud data residency advisory work starts from classification, not from a map of regions. Once each dataset's constraint is established, the options become a finite and arguable list: an in-Kingdom region of a global provider, a local provider, a sovereign or government cloud arrangement, on-premises for the residual set, or a hybrid split that keeps the constrained data at home and runs everything else wherever it is cheapest. Each carries a genuine trade-off in cost, available services, resilience and lock-in, and we put those trade-offs in writing instead of presenting one option as the only compliant one. A defensible decision is one you can explain to an auditor and to your own board, with the reasoning recorded at the time it was made rather than reconstructed afterwards.
Cloud regulation in the Kingdom has changed repeatedly over the last few years and will change again. We assess against the versions published at the time of the engagement, say so in the report, and flag the areas where guidance is known to be under revision - so a finding can be re-tested later against what actually changed, rather than the whole assessment quietly expiring on a date nobody wrote down.
A cloud migration is planned, in flight, or already finished without a security review at any point along the way. An auditor or regulator asked where a particular dataset is hosted and the answer took days to assemble. Your estate has spread across more than one cloud platform, or a business unit procured one directly and told nobody. A major cloud service is up for renewal or replacement and no one has tested whether the current configuration still meets the controls you are held to. Or your board has asked for assurance that moving to cloud did not quietly move risk off the register rather than reduce it.
If you have no production workload in cloud and no migration planned, this is not yet your problem, and an enterprise security assessment is the better use of the budget. If an independent cloud assessment was completed recently over the same scope and its findings are still open, what you need is remediation capacity rather than a second opinion. And if the question is a narrow technical one inside a single platform you already run well, your existing provider or implementation partner is usually the faster and cheaper answer. We will say so rather than open an engagement.
We start with the business outcome you need, not a product shortlist. That means sitting with the people who own the outcome, mapping current constraints, and agreeing what "solved" actually looks like before any vendor conversation starts.
We score realistic options against your own criteria - cost, fit, implementation risk, local support - without a reseller margin sitting behind the answer. Where a vendor in our partner network is not the best fit, we say so.
You receive a written recommendation with the trade-offs made explicit, not a single option presented as the only one. Sign-off is yours; the case for it is ours to make clearly.
Once a direction is chosen, we oversee delivery and integration with your existing systems, so the handover from decision to working system stays our responsibility, not yours to chase.
The relationship does not end at go-live. We stay engaged as an advisor for the decisions that follow - scaling, renewals, the next system that needs to talk to this one.
A written cloud security assessment covering architecture, identity, data protection and logging; a control-by-control view of where you stand against the cloud controls and data rules that apply to you, with the material gaps separated from the ones that are only missing documentation; a classification and residency position for each dataset that carries a constraint; a remediation plan prioritised by risk and effort rather than listed in the order the findings happened to be written; and, where the engagement continues past the assessment, oversight of that remediation against the plan.
An assessment of a single-platform estate typically runs three to six weeks. A multi-cloud or multi-entity estate takes longer and is scoped that way rather than compressed to fit. Remediation timelines depend entirely on what is found: a configuration and privileged-access clean-up moves quickly, whereas relocating a workload to satisfy a residency constraint is a migration project and gets planned as one. Both stages are scoped in writing before you commit to either.
The assessment is contracted on a fixed fee, scoped after a first discovery conversation, so the number is known before you commit and does not drift with the length of a meeting. Remediation oversight is contracted separately and is never a condition of the assessment: clients who take the findings and act on them with their own team, their existing partner or their cloud provider are a normal outcome, not a failed one. We take no commission from any cloud provider, reseller or security vendor named in a recommendation - which is the only reason the recommendation is worth reading.
Organizations in Saudi Arabia running regulated or business-critical workloads in cloud: banks and financial institutions, healthcare providers, government and government-linked entities, and enterprises whose cloud footprint grew faster than the governance around it. The people who call us are usually the ones accountable for the answer - a CISO or head of information security who needs an independent read before signing an attestation, a CIO midway through a migration, a CTO weighing one hosting model against another, or a risk and compliance lead who has been asked a residency question the current architecture cannot answer.
No, and the two are kept separate deliberately. IT security consulting looks at your organization's security posture as a whole against the Essential Cybersecurity Controls. Cloud security consulting looks specifically at what changes when workloads run on infrastructure you do not own: the shared responsibility split, the cloud-specific controls, data residency, and provider access. Plenty of clients need both, and the cloud assessment is usually the more urgent of the two once a migration is under way.
No. We are an independent advisory firm, not a reseller with an advisory department attached. We maintain a partner network so that a recommendation can actually be delivered, but we take no commission for naming a provider, and where the right answer sits outside that network we put that in writing.
Yes, and it is a common reason for the call. A multi-cloud estate is where the responsibility boundaries differ most between platforms, and where identity and logging are hardest to see as one picture. The assessment covers every platform in scope and reports against a single control set, rather than producing a separate report per provider that nobody can reconcile.
Not necessarily, and answering that properly is much of the engagement. The constraint attaches to the data, not to the organization, so it depends on what each dataset contains, which classification applies to it, and what your sector regulator requires. Some estates do need a full in-Kingdom footprint; more often a defined set of data has to stay and the rest does not. We establish which is which, and document the reasoning so the decision can be defended later.
It tells you where you currently stand against the controls that apply to you, which gaps are material, and what evidence you could produce today. We do not issue certifications and we are careful not to imply a guaranteed outcome: an assessment prepares you for an audit and removes the surprises from it, but the audit itself belongs to the auditor.
Yes, and a post-migration review is one of the more valuable bounded engagements we run, because it catches the configuration and access decisions that were made under delivery pressure and never revisited afterwards. Concluding that a migration was done soundly is a perfectly good result.