The Problem: Accidental Architecture
Most Azure environments are not designed. They grow through a series of temporary fixes that quietly become permanent: a subscription created for a single project, an Owner assignment granted “just for the migration,” and a VNet peering nobody remembers approving.
Each decision made sense at the time. Together, however, they create an environment that works, yet no one can fully explain it. Costs drift, permissions accumulate, policies exist on paper but are not enforced, and nobody tests the recovery plans everyone relies on.
The Architecture Integrity Review is a fixed-scope, read-only assessment of your Azure environment. I examine how it is configured, compare it with Microsoft’s Cloud Adoption Framework and Azure Landing Zone guidance, and tell you plainly what is at risk, why it matters, and what to fix first.
You get findings, not a sales pitch. If something is fine, I will say so. If something is more complex than it needs to be, I will say that as well.
Who This Is For
A good fit if:
- Your Azure environment has grown faster than its governance, and nobody can draw it from memory.
- You inherited a tenant from a previous team, partner, or acquisition.
- You are preparing for an audit, a certification (ISO 27001, NIS2), a migration wave, or significant growth.
- Leadership is asking questions about cost, security, or resilience that engineering cannot answer with evidence.
- You want an independent second opinion before investing in a redesign.
Not a good fit if:
- You run a single subscription for development or testing. In that case, Azure Advisor and Defender for Cloud will cover most of what you need, at no cost.
- You need a penetration test. This review assesses configuration and design, not exploitability.
- You want someone to make changes in production during the review. The engagement is strictly read-only. Remediation is a separate, optional engagement.
The Method: Evidence, Impact, Root Cause, Fix
Azure Advisor, Defender for Cloud, and Microsoft’s own assessment tools are good at listing misconfigurations. I use them too. What they cannot tell you is whether a finding matters to your business, why it exists, and what will prevent it from recurring next quarter.
That is why every finding in the report answers four questions:
- Evidence. What is configured, and where. You can verify every finding in your own tenant.
- Impact. What it puts at risk, in business terms rather than severity scores alone.
- Root cause. Whether the problem is technical (a design or configuration error), process (no standard, no review step), or ownership (nobody accountable for it).
- Fix. The recommended change and target state, with an effort estimate and references to Microsoft guidance.
In short, root cause is what separates a review from a scan. Fix a symptom without it, and the same finding returns in the next review.
Three principles shape how findings are written and prioritised:
- Radical transparency. Honest trade-offs, including where the fix costs more than the risk. No upselling inside the report.
- Operational elegance. The recommended fix is the simplest one your team can actually run. If it needs a dedicated platform team you do not have, it is not the right fix.
- Technical sovereignty. I write the roadmap so your engineers can execute it themselves. You should not need me to implement it.
What The Review Covers
I assess four pillars against Microsoft’s Cloud Adoption Framework and the Azure Landing Zone reference architecture.
| PILLAR | WHAT I EXAMINE |
|---|---|
| Governance & Identity | Management groups, Azure Policy, RBAC, privileged access, Entra ID and Microsoft 365 security |
| Network & Security | Topology, hybrid connectivity, DNS, public exposure, segmentation, Defender for Cloud |
| Cost & Sprawl | Over-provisioning, orphaned resources, budgets and cost allocation |
| Resilience & Recovery | Redundancy, single points of failure, backups, realistic recovery objectives |
The Identity and Microsoft 365 security scan is also available as a standalone assessment for organizations whose exposure is primarily in Entra ID and Microsoft 365 rather than in Azure resources.
What’s Included
Every AIR follows the same seven steps. Duration depends on scope (see Scope and pricing below).
- Briefing Call (45 minutes, online, free). We agree which subscriptions are in scope, what is business-critical, and what decision the review needs to support. You receive a fixed-fee quote afterwards.
- AIR Kick-Off (60 minutes, online). We sign the NDA, confirm read-only access and agree the readout date. Includes a context interview with the people who build or own the environment: documentation shows what was intended, people explain what actually happens.
- Environment Discovery. Read-only collection of configuration, policy compliance, cost and security data across all in-scope subscriptions and Entra ID, including an automated identity and Microsoft 365 security scan.
- Pillar Analysis. I assess every finding across the four pillars above, with evidence, impact, root cause and recommended fix.
- Findings Validation (60 minutes, online). Before finalising the report, I confirm serious findings with your team. No surprises in the readout.
- AIR Readout (90 minutes, online or on-site). Engineering and decision-makers together. We walk through the findings, the roadmap and the trade-offs, and you receive the full report.
- 30-Day Follow-Up. For 30 days after the readout, I answer questions about the findings or the roadmap by email.
Staged delivery (Standard and Extended)
If you prefer, I share findings pillar by pillar as the analysis progresses, so your team has time to absorb them before the readout. Interim findings are provisional, however. I finalise the root-cause analysis and prioritised roadmap at the readout, once I have assessed every pillar. Focused reviews arrive in one go.
Optional add-ons
- Well-Architected workload review: an in-depth review of a named business-critical workload against the Well-Architected Framework, from €400 per workload.
- Additional stakeholder interviews beyond the kick-off.
- Remediation support: see After the review.
Not included
- Changes to your environment. The AIR is strictly read-only.
- Penetration testing or vulnerability scanning of applications.
- Implementation of the roadmap, which is a separate, optional engagement.
- Step-by-step runbooks, scripts or implementation guides. Each recommendation defines what to change, the target state and why, with references to Microsoft guidance. Hands-on implementation support is available separately.
- An exhaustive inventory of every configuration. The review is risk-based: it goes deep where exposure is highest and samples lower-risk areas. A follow-up reassessment is the best way to catch what changes after remediation.
What You Receive
- Executive summary. Two pages for leadership: overall posture, top risks, and the decisions that need an owner.
- Findings register. Every finding with evidence, business impact, severity, estimated effort, root cause and recommended fix. You receive it as a document and as a spreadsheet your team can import into Azure DevOps, Jira or any backlog tool.
- Remediation roadmap in three horizons:
- Stabilise (0 to 30 days): critical exposure and quick wins.
- Strengthen (30 to 90 days): structural fixes to identity, network and policy.
- Standardise (90 days and beyond): the platform changes that stop the same problems from returning.
- Governance recommendations. A target RBAC model, recommended Azure Policy assignments with their effects, and the guardrails needed to prevent drift.
- Cost findings. Each cost issue with the resource, the recommended change, and the estimated monthly saving where it can be measured from your billing data.
- Readout deck. The slides from the final session, so the findings can be presented internally.
Example finding (illustrative)
| FIELD | EXAMPLE |
|---|---|
| Finding | 14 accounts hold permanent Owner at subscription scope; 9 have not signed in for over 90 days |
| Pillar | Governance & identity |
| Severity | High |
| Effort | Small (1 to 2 days) |
| Business impact | A single compromised account gives full control of production, including the ability to delete backups |
| Root cause | Ownership: no defined owner for access reviews; Owner became the default during migration |
| Recommendation | Remove inactive assignments, move remaining Owner roles to PIM with approval, schedule quarterly access reviews |
| Horizon | Stabilise |
Scope and Pricing
I quote every review as a fixed fee after the Briefing Call. These are the starting points.
| SCOPE | TYPICAL ENVIRONMENT | TYPICAL DURATION | INVESTEMENT |
|---|---|---|---|
| Focused | Up to 5 subscriptions, cloud-only | 3 to 4 weeks | From €5,700 |
| Standard | 6 to 25 subscriptions, hybrid connectivity. Staged delivery available | 7 to 8 weeks | From €10,500 |
| Extended | 25+ subscriptions, multiple tenants or regions, complex hybrid estates. Staged delivery available | Agreed at briefing | Quoted after briefing |
What moves the price: number of subscriptions and tenants, hybrid connectivity, overall resource count, and any optional Well-Architected workload reviews.
After The Review
I write the roadmap for your team to execute. Most clients choose one of three paths:
- Run it yourselves. The findings register goes straight into your backlog. Nothing else is required.
- Execute with guidance. I review your team’s designs and pull requests while they implement, without taking over the work.
- Hand over specific workstreams. I implement selected items, such as a landing zone redesign, a policy-as-code baseline or a network restructure, under a separate engagement.
For structural fixes, I use IronByte’s CROCS framework, so the change holds after the engagement ends and the team changes:
- Culture: engineering and leadership agree on why the standard exists.
- Responsibility: clear separation between who defines the standard and who builds against it.
- Ownership: your team can operate and extend the result without me.
- Consistency: one way to deploy, name, tag and connect resources.
- Security: controls enforced by the platform, not left to individual discretion.
Finally, a follow-up review after 6 to 12 months measures what changed against the original baseline.
What This Looks Like in Practice
A SaaS client was already deploying entirely through Bicep, yet every engineer had built their own modules. The code was automated, but not governed. Replacing individual patterns with one governed module standard on a new landing zone cut their end-to-end deployment cycle by roughly 70%. Read the case study
Access and Confidentiality
The review needs read access to your environment, nothing more.
Roles required (read-only, removed after delivery):
- Azure: Reader at the tenant root management group (or the in-scope management groups)
- Entra ID: Global Reader and Security Reader
- Cost: Cost Management Reader on the in-scope scopes
- Optional: Log Analytics Reader on central workspaces, to validate monitoring and diagnostics coverage
You can also time-bound all access through PIM. I never request write permissions.
Confidentiality and data handling: we sign an NDA before you grant any access. I process and store configuration exports in the EU only, use them solely for this engagement, and delete them within 30 days after delivery, unless you ask me to keep them for a follow-up review.
Clean AIR Starts With a Clear Picture
A 45-minute conversation about your environment and what you need to decide. You leave with a clear scope and a fixed-fee quote, whether or not you go ahead.
Both options go directly to me. No sales funnel, no account managers.