From a repeated engagement to a product
CloudNorma was not born from a market hunch. It was born from fatigue: redoing the same manual work, client after client, to produce evidence a machine could generate.
The manual work
An Azure governance engagement always follows the same arc. You assess compliance requirements, analyse business needs, then put centralised policies in place: Azure Policy to enforce rules, Blueprints for reusable templates, management groups to organise the subscription hierarchy, Resource Graph to explore the estate.
The expensive part is not the setup. It is the demonstration. When the auditor asks for proof that activity logging is enabled across every subscription, or that network security group rules do not expose the management port to the internet, someone opens the portal and starts clicking.
The same finding, at client after client. The gaps repeat from one organisation to the next: publicly accessible storage, missing multi-factor authentication on privileged accounts, insufficient log retention, open management ports. The same fifteen rules come back.
What could be automated
If the gaps repeat, the control that detects them repeats too. And if the control is deterministic, the evidence it produces can be as well. That is the reasoning that led to CloudNorma.
The MVP was deliberately narrow: one cloud, one framework, around fifteen critical rules. Enough to cover the majority of real findings, little enough to be shippable.
A few of the rules selected
| Area | Control |
|---|---|
| Logging | Activity log enabled on every subscription, retained at least one year |
| Network | RDP and SSH access restricted, no rule open to the whole internet |
| Storage | Storage accounts without public network access, disk encryption |
| Identity | Multi-factor authentication required on privileged accounts |
| Operations | Mandatory tagging, automatic updates, backups of critical machines |
The technical chain
Each regulatory requirement is converted into an executable control, deployed as infrastructure as code, then continuously verified. A detected gap does not stay a finding: it carries its fix.
From written requirement to automated control
Translate
The framework requirement becomes an executable policy definition, keeping its source identifier.
Deploy
The policy is applied as infrastructure as code, reproducibly and under version control.
Verify
The estate is analysed continuously. Any drift is caught without waiting for the next audit.
Remediate
The gap arrives with its fix attached: a Terraform block, an Azure policy, or step-by-step instructions.
Let's talk about your cloud trajectory
Compliance audit, target architecture, governance automation, or simply picking the right solution — write to us and we'll reply within 48 hours.