Skip to content

Azure Cloud Security

A secure Azure foundation, documented for your auditors.

New projects start on an Azure foundation whose security rules are already in place and provable. We build the landing zone with Azure Policy, Defender for Cloud, network segmentation, PIM and Sentinel, and hand it over documented as code.

Book an introductory call How it works

Example of a handed-over landing zone: management groups, network and private endpoints exist as code, Azure Policy is enforced, admin roles are available via PIM only on request, logs are connected to Sentinel, Defender for Cloud is active.

For
Companies with 50 or more employees running workloads in Azure
Scope
Landing zone, Azure Policy, RBAC with PIM, Defender for Cloud, Sentinel
Duration
Assessment in 2 to 4 weeks
Result
Rating against the Microsoft Cloud Security Benchmark, landing zone as code
Price
from €6,900 excl. VAT, fixed price for the assessment

Sound familiar?

When does Azure need a new foundation?

Azure has grown organically

Production, development and management are not cleanly separated.

An audit is coming up

NIS2, DORA or ISO 27001 require solid evidence.

New workloads or a migration

The security foundation should be right from the start.

Landing zone as code

How is a secure Azure environment built?

Layer by layer, each one as code in your repository. Azure Policy wraps around everything as a guardrail. Terraform or Bicep, the structure stays the same.

Choose code format

Azure Policy applies to everything inside

  1. 1 Management groups

    Platform and workloads separated, production and development in their own subscriptions.

    management-groups.tfmanagement-groups.bicep

  2. 2 Identity and access

    Azure RBAC with least privilege, admin roles only on request via PIM.

    identity.tfidentity.bicep

  3. 3 Network

    Hub with Azure Firewall, NSGs, PaaS services only via private endpoints.

    network.tfnetwork.bicep

  4. 4 Azure Policy

    Guardrails per management group, insecure deployments are rejected.

    policy.tfpolicy.bicep

  5. 5 Logging and monitoring

    Log Analytics, Microsoft Sentinel and Defender for Cloud.

    logging.tflogging.bicep

  6. Foundation for your workloads

    New projects start with rules already in force.

The landing zone built in five layers, each as a code file in Terraform or Bicep: management groups with separate subscriptions, identity and access with RBAC and PIM, network with Azure Firewall, NSGs and private endpoints, Azure Policy as the guardrail for every layer, logging and monitoring with Log Analytics, Microsoft Sentinel and Defender for Cloud. Your workloads start on top of it.

What we secure in Azure

Landing zone

Structure following the Cloud Adoption Framework, via Terraform or Bicep.

Azure Policy

Guardrails per management group, rolled out as code; Azure Blueprints retires on January 31, 2027.

Defender for Cloud

Protection plans enabled, recommendations prioritised by risk.

Network segmentation

Azure Firewall, NSGs and private endpoints.

RBAC and PIM

Least privilege, admin roles only on request.

Logs and Sentinel

Centralised in Log Analytics and Sentinel.

Azure Policy

What happens to an insecure deployment?

Azure Policy checks every deployment before a resource is created. Anything that breaks the rules is rejected, whether it comes from the portal or a pipeline.

  • Rules per management group, maintained as code
  • Defender for Cloud reports existing cases
Your team and pipelines
  • Storage with private endpoint Compliant, gets deployed
  • Storage, publicly reachable Rejected before it exists Azure Policy
  • VM in a disallowed region Rejected, region not approved Azure Policy
Three deployments head towards Azure Policy. Storage with a private endpoint is deployed. Publicly reachable storage and a VM in a disallowed region are rejected by Azure Policy.

How does the project run?

  1. 2 to 4 weeks

    Assessment

    Evaluation against the Microsoft Cloud Security Benchmark.

  2. 6 to 12 weeks

    Lay the foundation

    Landing zone, policy, RBAC with PIM, logging.

  3. 2 to 4 months

    Harden and segment

    Private endpoints, baselines, Defender for Cloud.

  4. 2 to 4 weeks, then ongoing

    Monitor and hand over

    Connect Sentinel, hand over to your team.

Where should you start in Azure?

We work out which step has the greatest effect.

Book an introductory call

What changes in your Azure environment?

Grown organically

  • Standing rights at subscription level
  • Storage reachable from the internet
  • Deployments possible without any check
  • Logs missing when an incident happens

With a landing zone

  • Least privilege, admin roles only on request
  • PaaS services only via private endpoints
  • Azure Policy rejects insecure resources
  • Logs centralised in Microsoft Sentinel

Frequently asked questions

What is an Azure landing zone and why do we need one?

The pre-configured foundation of management groups, subscriptions, network, permissions, logging and policies. Without it, security is decided afresh in every project, and correcting running workloads later takes considerable effort.

We have already enabled Defender for Cloud. Is that enough?

Defender for Cloud finds misconfigurations and calculates your secure score. Without segmentation, a permission model and enforced policies, the findings remain a list nobody works through.

How do I prevent publicly reachable storage and databases in Azure?

Azure Policy rejects resources with public network access before they are created. Private endpoints connect them through private addresses, and Defender for Cloud reports existing cases.

How are Azure logs analysed in Microsoft Sentinel?

Logs and Defender alerts flow through data connectors into a Log Analytics workspace, where analytics rules create incidents. Retention is decided beforehand, because both the value of the data and the cost depend on it.

How secure is your Azure environment?

Book an introductory call