Shared responsibility in IaaS: provider and customer controls

IaaS transfers some infrastructure work to a provider, but it does not transfer responsibility for applications, identities or the meaning of data. Most gaps arise from an undefined boundary: each side assumes that the other will configure a control, test a backup or investigate an alert.

Shared responsibility must be defined for the exact service. The label “IaaS” does not say who patches the guest operating system, installs security agents or restores a database.

A typical boundary

The provider normally operates:

• physical facilities;
• power and cooling;
• servers and storage;
• physical networks;
• the virtualisation platform;
• availability of contracted infrastructure components.

The customer normally controls:

• guest operating systems;
• OS patching and configuration;
• applications;
• identities and permissions;
• network policy in its tenant;
• data and retention;
• application-level backups;
• compliance of its own system.

Managed services occupy the middle. A provider may administer the OS, firewall or backup only where the service description explicitly says so.

Build a RACI matrix

For each process, identify who is Responsible, Accountable, Consulted and Informed. Cover VM creation, OS patching, access, backup, restore, monitoring, incidents, resource changes and deletion.

“Backup is enabled” is not a responsibility model. State what is copied, where it is retained, who monitors jobs, who initiates a restore and who verifies the result.

Treat the control plane as a critical perimeter

Compromise of the IaaS console can allow resource creation, network changes and deletion. Customers should:

• enable MFA;
• separate administrative and daily identities;
• grant minimum roles;
• use personal accounts;
• restrict access by trusted network where possible;
• audit changes;
• remove unused access;
• document emergency suspension.

Infrastructure API keys need rotation, restricted scope and protected storage. They must not appear in source code or shared documents.

Network responsibility

The provider operates its physical and virtual network, while the customer usually defines segmentation inside the tenant. The customer decides which services are public, which subnets communicate, where VPN terminates, who has administrative access and what traffic is logged.

An accidentally open port is not necessarily a platform failure. Network policy therefore needs review and automated checks.

Data and backup

Highly available storage is not the same as backup. Replication can spread deletion or corruption to every replica.

For each dataset, define its owner, classification, primary copy, RPO/RTO, backup schedule, isolated storage, deletion protection, retention and recovery procedure.

Test restoration rather than only the job status. Our backup and resilience guide describes practical patterns.

Join provider and customer observability

The provider sees the platform; the customer sees the OS and application. Effective investigation needs both views.

Agree on available platform metrics, guest telemetry, time synchronisation, resource identifiers, log retention, diagnostic-data exchange and incident notifications.

A provider SLA does not replace a business-service SLO. A VM can be available while its application returns errors. The connection between infrastructure and user indicators is covered in SLIs and SLOs.

Contract checklist

Document:

• exact service scope;
• administration boundary;
• availability indicators and exclusions;
• maintenance process;
• incident notification;
• backup and restore;
• data location and movement;
• contractor access;
• log availability;
• termination and data export;
• deletion timing and evidence;
• resource and price-change process.

A provider’s licences and certificates apply to a particular organisation, activity or environment. They do not make every customer system automatically compliant. The customer still determines applicable requirements and verifies implementation.

Validate before production

Create a resource from the approved template, test segmentation, revoke a test identity, install a critical update, restore into an isolated environment, simulate a component outage, verify alerts on both sides, request diagnostics and test deletion.

This pilot reveals the real responsibility boundary better than a generic feature list.

How we can help

Logic Telecom can help define the responsibility matrix, target IaaS environment, backup design and operating procedures. Start with one service and walk through its full lifecycle: creation, change, incident, restore and deletion.