Azure governance and access control

The story

The organisation's Azure and Active Directory estate had grown organically, which meant inherited privilege, inconsistent tagging, and no policy boundary between environments. The work was framed as "IT operations management", but the part that mattered engineering-wise was the governance layer: making Azure enforce the controls instead of relying on people to remember them.

What I built

• Azure Policy as the boundary: baseline policy assignments that blocked non-compliant resources at creation time rather than catching them in an audit weeks later. Tagging, region restrictions, and resource-type allowlists became defaults, not requests.
• RBAC over shared keys: replaced standing admin access with role-based assignments scoped to resource groups, so engineers and vendors got least privilege tied to what they actually needed to touch.
• Active Directory hardening: cleaned up stale accounts, service-principal sprawl, and inherited group memberships that had outlived their purpose. Access reviews became a cadence, not a fire drill.
• Procurement and cost controls: budget alerts, subscription rationalisation, and a tagging strategy aligned to cost centres, so Azure spend was visible and attributable rather than a single surprise bill.

Outcome

• Non-compliant resources stopped getting created, because policy rejected them before they existed.
• Access became reviewable and time-bound instead of permanent and inherited.
• Azure spend moved from "unexplained at month-end" to forecastable and tagged to ownership.
• The governance model stayed in place after the role ended. The point of policy-driven controls is that they do not depend on the person who set them up.

What I owned

I designed and implemented the Azure governance, RBAC, and Active Directory hardening end-to-end, and aligned it with the organisation's GDPR and procurement obligations so compliance was a property of the platform rather than a checklist run alongside it.