Most organisations that buy a managed Azure service assume they are handing the whole thing over to someone else to run. That assumption is where the problems start. The reality of azure managed services is more layered: there are three distinct responsibility zones in any Azure engagement, and understanding which zone belongs to Microsoft, which belongs to your managed service provider, and which stays with you is the single most important thing a CIO can clarify before signing a contract.
What is managed Azure? Azure managed services refers to a model in which a third-party provider takes operational responsibility for your Azure environment, typically covering infrastructure management, security monitoring, patching, cost governance, and support. But managed does not mean all-inclusive. The specific scope of any managed service is defined by the contract, and the gaps between what is assumed and what is actually covered are where security incidents, compliance failures, and budget overruns tend to appear.
This guide sets out the three layers of the managed Azure responsibility model in plain language, giving UK mid-market CIOs a clear framework for evaluating their current or prospective managed service arrangements.
The Three Responsibility Zones in Any Managed Azure Engagement
Before reviewing what a managed service provider covers, it is useful to understand what Microsoft is responsible for regardless of any managed arrangement.
Microsoft’s responsibility in all Azure deployments is the physical infrastructure: the data centres, the network hardware, the hypervisors, and the availability of the platform services themselves. Everything above that layer, including the virtual machines, the data stored in them, the network configuration, the security policies, the identities, and the applications, is the customer’s responsibility unless explicitly transferred to a managed service provider by contract.
For managed azure engagements in the UK, this boundary matters greatly. Microsoft’s compliance certifications, including ISO 27001, Cyber Essentials Plus, and UK GDPR data residency commitments, cover the physical platform. They do not cover how your organisation configures and uses that platform. A data breach caused by a misconfigured storage account or an unpatched virtual machine is not a Microsoft failure. It is a configuration failure, sitting in the layer that either you or your provider owns.
The NCSC Cloud Security Guidance addresses this directly, providing UK organisations with a framework for assessing cloud provider responsibilities and the configuration decisions that remain with the customer.
Why the Gaps in Azure Managed Services Keep Catching CIOs Out
The managed service layer sits between Microsoft’s platform and the customer’s retained responsibilities. A provider takes on what is contractually agreed. Nothing more.
The gap between what CIOs assume is covered and what is actually contracted is consistently the source of the most significant operational and compliance issues in azure managed services uk engagements. Application-layer security, identity governance, compliance reporting for sector regulators, and end-user device management all sit in a zone that many standard managed service agreements do not reach.
Transputec’s approach to every managed Azure engagement starts with a written responsibility matrix that specifies, line by line, what the provider covers, what Microsoft covers, and what the customer retains. Our azure cloud services page outlines our standard managed service scope in detail.
Not Sure What Your Azure Contract Actually Covers?
Transputec can review your existing managed Azure arrangement or help you design a new one with clear responsibility boundaries, no assumptions, and no gaps. Our team works with UK mid-market CIOs to make sure nothing falls through the cracks.
Get a Strategic ConsultationWhat Microsoft Is Always Responsible For in Azure
Microsoft’s responsibilities in every Azure deployment are defined in the Microsoft Online Services Terms and published shared responsibility documentation. For UK organisations, these cover:
- Physical infrastructure security: Microsoft is responsible for the physical security of its data centres, including access controls, surveillance, and environmental protections at the UK South (London) and UK West (Cardiff) facilities
- Platform availability: Microsoft’s SLAs guarantee uptime for individual Azure services, typically at 99.9% to 99.99% depending on the service tier and configuration chosen. Platform unavailability is Microsoft’s responsibility and is compensated through service credits
- Hypervisor security: The virtualisation layer beneath virtual machines is Microsoft’s responsibility. Vulnerabilities in the hypervisor are patched by Microsoft without customer intervention
- Platform software updates for PaaS components: For platform-as-a-service components such as Azure SQL and App Service, Microsoft handles the underlying software maintenance. This does not extend to operating systems or applications running on IaaS virtual machines
It is important to note that Microsoft’s compliance certifications apply to this infrastructure layer only. When an organisation says their Azure deployment is ISO 27001 certified, they are referring to Microsoft’s certification of the platform, not to their own use of it. Your organisation’s compliance posture depends on how you configure and operate everything above the platform layer.
What Your Azure Managed Services Provider Is Responsible For
A managed service provider takes on responsibility for the operational layer above the platform. The exact scope varies by provider and contract, but the core elements of a well-structured azure managed services engagement cover the following areas.
Infrastructure management: Provisioning, scaling, and decommissioning compute, storage, and network resources. This includes managing virtual machine lifecycles, configuring auto-scaling policies, and maintaining the network topology connecting your Azure environment to on-premise systems and end users.
Security monitoring and incident response: Continuous monitoring of the Azure environment using Microsoft Sentinel and Defender for Cloud, with defined response procedures for alerts and incidents. This is one of the most critical elements of managed azure for mid-market organisations where in-house security operations capacity is typically limited.
Patch management: Keeping virtual machine operating systems and managed platform components up to date. This is a specific scope item that must be explicitly defined in any managed service agreement: which systems are patched, at what frequency, how patches are tested before deployment, and how emergency patches are handled. Vague answers indicate vague processes.
Cost governance: Monthly reporting on Azure consumption against agreed budgets, identification of idle or oversized resources, and management of reserved instance purchases. Without active cost governance, azure managed services uk engagements consistently drift over budget as environments grow and new resources are provisioned without corresponding decommissions.
Backup and disaster recovery: Configuration and regular testing of Azure Backup and Azure Site Recovery, with defined recovery time and recovery point objectives. Testing is the critical word here. A backup configuration that has never been exercised in a real recovery scenario is not a recovery plan.
What is typically not included in a standard managed service scope unless explicitly contracted: application security testing, data loss prevention policy configuration, end-user device management, Microsoft 365 administration, and compliance reporting for specific regulatory frameworks such as FCA operational resilience, NHS Digital DSP Toolkit requirements, or ICO data protection assessments. These are all available as additional scope, but they need to be specifically agreed and contracted.
What the Customer Retains in a Managed Azure Arrangement
Even with a fully managed Azure service in place, the customer retains a defined set of responsibilities. These are not gaps in the managed service; they are areas where business judgment, not technical management, is required.
Data governance: The customer is responsible for classifying their data, defining retention policies, and ensuring data handling practices meet their legal obligations. A managed service provider can help configure the technical controls, but the governance decisions belong to the business.
Identity and access decisions at the business level: While the managed service provider configures Microsoft Entra ID and the technical identity infrastructure, decisions about who has access to what, at what privilege level, are business decisions. Inappropriate access grants are one of the most common root causes of security incidents, and they are rarely a technical failure on the provider’s part.
Regulatory compliance accountability: For organisations in regulated sectors, compliance with the FCA, ICO, CQC, or other regulators is the organisation’s responsibility. A managed service provider can supply the technical controls and evidence required for compliance assessments, but accountability stays with the customer. Microsoft’s Azure UK compliance resources set out what Microsoft certifies at the platform level, which is a useful baseline for understanding where customer obligations begin.
Application security: The security of applications running on Azure, including web applications, APIs, and internal tools, sits above the infrastructure layer and is typically the customer’s responsibility unless specifically contracted. This is the area most frequently omitted from standard azure managed services agreements.
Strategic decisions: Decisions about cloud architecture, technology choices, and investment priorities are the customer’s to make. A strong managed service provider informs those decisions and brings relevant recommendations, but does not make them unilaterally.
How to Identify Gaps in Your Current Azure Managed Services Arrangement
If you have an existing managed Azure arrangement, or are evaluating a new provider, the following questions will surface coverage gaps quickly.
Is there a written responsibility matrix? Any credible managed service provider should produce a document specifying, line by line, what they cover, what Microsoft covers, and what the customer retains. If this document does not exist, the boundaries have not been agreed and gaps almost certainly exist.
What is the exact patch management scope? Ask specifically: which systems are patched, at what frequency, who approves the change window, and how are emergency patches handled outside business hours? Vague answers indicate vague processes.
What does security monitoring cover, and when? Ask whether monitoring covers the full Azure environment or specific services only. Ask what the escalation path is when an alert fires at 2am on a Saturday. Ask how many analysts are monitoring the environment and what the average response time is for critical alerts.
What happens at the application layer? Most infrastructure managed services do not cover application security. If your applications process personal data or financial information, the security of those applications needs to be addressed either through a separate agreement or through in-house capability. Leaving this unaddressed is a common compliance exposure for organisations in regulated sectors.
How is compliance evidence produced? For organisations subject to FCA, ICO, or NHS regulation, ask explicitly how your managed service provider supports compliance reporting. If they cannot describe a specific process, that area is not covered.
Transputec produces a written responsibility matrix for every managed azure engagement, and we will review existing arrangements to identify gaps before they become problems. Our managed IT services page explains how our Azure management integrates with broader IT support, and our cloud services page sets out our approach to scope definition and service delivery.
Conclusion
The shared responsibility model in azure managed services is not complicated once it is written down clearly. Microsoft covers the physical infrastructure and platform availability. Your managed service provider covers the operational layer above that, to the scope defined in your contract. You retain responsibility for governance, compliance accountability, and strategic decisions.
The problems arise when that model is not written down, and when CIOs assume that managed means everything. Understanding what you own in a managed azure engagement is not a technical question. It is a contract and governance question, and it deserves the same scrutiny as any other material business commitment.
Transputec works with UK mid-market organisations to design and deliver azure managed services with clear responsibility boundaries and no assumptions. If you want to review your current arrangement or understand what a new engagement should include, our team is ready to help you map it out.
FAQs
What does managed Azure actually include?
Managed azure, or azure managed services, covers the operational layer above Microsoft’s physical infrastructure: infrastructure provisioning and lifecycle management, security monitoring using Microsoft Sentinel and Defender for Cloud, patch management for virtual machines and platform components, cost governance and consumption reporting, and backup and disaster recovery configuration and testing. The exact scope depends on the contract. Application security, data governance, compliance reporting, and identity access decisions at the business level are typically retained by the customer unless specifically included. Transputec provides a written responsibility matrix on every engagement so scope is clear before work begins. Visit our azure cloud services page for details on our standard managed scope.
What am I still responsible for with azure managed services?
Even with a fully managed arrangement, customers retain responsibility for data governance, identity and access decisions at the business level, regulatory compliance accountability, application security, and strategic technology decisions. Azure managed services transfers operational management to your provider; it does not transfer business accountability. For organisations in regulated sectors, this distinction is particularly important: your provider can supply the technical controls and compliance evidence, but accountability to the FCA, ICO, or CQC remains with your organisation. Our managed IT services page explains how Transputec supports customers in meeting these obligations.
Who is responsible for Azure security under a managed service?
Security responsibility in azure managed services is split across three parties. Microsoft is responsible for physical infrastructure and hypervisor security. The managed service provider is responsible for security monitoring, incident response, and the configuration of security tooling such as Microsoft Sentinel and Defender for Cloud, within the contracted scope. The customer retains responsibility for identity and access decisions at the business level, application security, and compliance with sector-specific regulations. The NCSC Cloud Security Guidance provides a clear UK-specific framework for mapping these responsibilities in practice.
What is the difference between what Microsoft covers and what my MSP covers?
Microsoft covers everything below the virtual machine layer: data centres, hardware, hypervisors, and platform availability. Your managed azure service provider covers the operational layer above that, including infrastructure management, security monitoring, patching, and cost governance, to the scope defined in your contract. The customer is responsible for everything not explicitly transferred to either party. The most common gaps appear in application security, identity governance decisions, compliance reporting for regulated industries, and end-user device management. A written responsibility matrix, produced before the engagement begins, is the clearest way to ensure all three zones are accounted for.
How do I know if my azure managed services arrangement has coverage gaps?
The clearest indicator of gaps in azure managed services is the absence of a written responsibility matrix. If your provider cannot produce a document specifying what they cover, what Microsoft covers, and what you retain, the boundaries have not been agreed. Ask specifically about patch management scope, security monitoring coverage outside business hours, application-layer security, and how compliance evidence is produced for regulatory requirements. Transputec reviews existing managed Azure arrangements as part of our initial engagement process. Explore our cloud services page to understand how we approach managed service scope definition, or contact our team directly for a review of your current arrangement.
