A UAE wholesaler buys cloud infrastructure through a local partner. When orders stop reaching the warehouse, the partner confirms that the servers are running. The application vendor asks for a database trace, while the wholesaler’s finance team tries to establish which orders were accepted. The company thought it had bought managed cloud. It discovers that nobody on the support call has agreed to lead an incident that crosses the infrastructure, application and warehouse systems.
Compare providers by the work they will own. Ask them to take a real operating scenario from detection through recovery, identify the responsibilities left with the buyer and show where the agreement says so. A useful proposal tells you who acts on a normal shift, who can make decisions during an outage and how the company can move its service if the arrangement ends.
Separate the platform, partner and customer roles
Name the entities behind the offer. One company may run the cloud platform, another may resell it and a third may manage the customer's environment. An application supplier may still be responsible for code or upgrades. Determine who issues the invoice, who holds the platform account and which organization can make changes in it. Ask who can open a case with the platform provider and what happens when that provider needs approval from the customer.
AWS's shared responsibility model illustrates how duties vary by service. For example, customers using Amazon EC2 are responsible for guest operating system patching and configuration of applicable security groups. A managed service partner may take on some of that work under a separate agreement. Identify which tasks the partner accepts, and verify what remains with the customer at the platform and business levels. AWS shared responsibility model
The UAE Cyber Security Council's National Cloud Security Policy summary discusses responsibilities for cloud consumers and providers, including contractual agreements, resilience and portability. Use those topics to structure the buying discussion. Have the accountable team determine the requirements that apply to the entity, data and service, and match them to the proposed controls and terms. UAE National Cloud Security Policy
Put the operating scope into a responsibility table
Ask bidders to complete the same table against the same workload. For each task, identify who performs it, who approves it, how often it happens and where the buyer can verify it. Give each bidder a copy of the application and dependency inventory. If the supplier assumes it is managing two servers and the buyer expects support for the application, database and a warehouse connector, resolve the difference before comparing price.
| Operating task | Question to put to the supplier | Evidence to request |
|---|---|---|
| Monitoring | Who sees and investigates an alert outside normal hours? | Alert path and example incident record |
| Patching | Who tests, approves and reverses a patch? | Maintenance procedure and sample change log |
| Identity and access | Who grants privileged access and checks its expiry? | Role list, approval flow and audit example |
| Backup and restore | Who verifies a successful restore and validates the application? | Recent test evidence or a witnessed drill |
| Spend and capacity | Who investigates cost spikes or capacity warnings? | Usage report and escalation process |
| Exit | Who exports records and hands over operational access? | Test export and a priced transition schedule |
Distinguish monitoring from intervention. An alert can trigger a message to the buyer or a repair performed by the provider. e& UAE's announcement of a managed monitoring offering is an example of monitoring being sold as a defined service. Ask any bidder whether its proposed scope includes diagnosis, remediation and coordination with other vendors, and which actions require customer approval. Read the service schedule for the actual proposal. e& Monitoring-as-a-Service announcement
A du campaign reel shows a UAE network demonstration. In a managed cloud contract, specify who diagnoses the customer's connection, who manages the cloud endpoint and who coordinates when the evidence points to neither side conclusively.
Ask which components the provider can actually see. A dashboard may cover infrastructure that the partner manages while leaving the application or a third-party connection outside its view. Test a missing data feed or a delayed warehouse job and inspect the alert. If the provider cannot see the failure directly, agree what signal the customer supplies and how the provider uses it. Make the boundary visible to the people who work the queue so they know which evidence to gather before a problem changes hands.
Exercise the service desk before relying on it
Give the shortlisted bidder a realistic incident. The wholesaler might report that its website accepts an order, but the warehouse receives no dispatch instruction. Ask the provider to show where staff open a case, what evidence it collects and which team owns the investigation. Check whether the supplier can coordinate a database, application or connectivity issue under the proposed tier. Have the people who will use the service join the exercise.
Read timing commitments with the scenario in mind. A first response acknowledges an issue. A workaround allows some work to continue. Restoration returns the agreed service. Ask how each is measured, when the clock starts and whether the supplier pauses it while awaiting the buyer or another provider. Check the coverage hours, time zone and escalation contacts. If the warehouse operates on weekends, make sure the proposal addresses those shifts.
Suppose a hypothetical incident is reported at 08:00. The service desk acknowledges it at 08:20 and the order flow resumes at 10:10. That is a 20-minute response and 130 minutes to restore. If the hypothetical contract targets a response within 30 minutes and the business needs restoration within 120 minutes from reporting, the first target is met and the operating need is missed by ten minutes. Ask how the provider would close that gap and what it would commit to measure.
Request an example of a post-incident report. It should distinguish what happened, how the parties responded and what work remains. Ask how repeated incidents are reviewed and whether the customer can see the corrective actions. For a multi-provider service, agree who writes the timeline and confirms that each party's records describe the same event.
Verify access and recovery with the proposed team
Ask who can administer the tenant and whether the buyer retains enough access to verify changes and run an exit. Have the supplier show how a privileged session is approved, logged and ended. Test withdrawal of an account and confirm which logs the customer can retrieve. Check the treatment of customer data in tickets and exports, including which provider or subcontractor can see it and where support tools store it.
Run a limited restore exercise. Give the provider a representative application and ask it to recover the service to the agreed test location. Watch how it obtains approval, selects the copy and handles credentials. Have the business owner complete a transaction after restoration. If the proposal covers backup jobs but the buyer must rebuild the application, capture that boundary and cost the work the buyer retains.
Check how changes are handled. Ask for a sample maintenance notice and an example of a rollback from a failed update. Confirm who tests the application, who can defer maintenance and which emergency changes may occur on shorter notice. If the provider relies on a separate platform or contractor, ask how changes in those services are communicated. Include obligations for maintaining documentation as the environment evolves.
Compare like-for-like operating and transition costs
Ask each bidder to show the base fee, included hours or services, support tier, project work and charges triggered by extra use. Keep the infrastructure estimate separate from the management fee. Check whether the provider passes through cloud charges, applies a markup or includes specific resources in a bundle. Request a sample invoice and match it to the quote. Identify which items move with workload volume and which remain fixed during a quiet month.
Price a few scenarios using the same assumptions. Include a busy month, a month with a recovery exercise and a month when the company needs out-of-hours work. Ask which tasks are charged as projects. If the buyer needs regular help with maintenance and application updates, a smaller base fee can lead to a larger total when those tasks sit outside the package. Include the internal effort required to manage the provider and handle excluded work.
Consider how charges respond to changes in the estate. A contract may count monitored devices, supported applications, hours or a band of cloud spending. Ask the bidder to price the removal of a service as well as the addition of one. If charges change only at renewal, note that in the budget. If a supplier applies a minimum, show the cost even when the workload falls below the expected volume.
Check how the relationship ends before it begins. Establish who owns the account, configuration, runbooks and deployment scripts and what the customer can take to another operator. Ask for a sample export of asset and configuration records, a billing history and a way to identify outstanding incidents or changes. Have someone on the buyer's team open the export and verify that it is usable. Ask how the provider will remove its access and hand over credentials or configuration that the customer is entitled to retain.
Agree the notice period, transition assistance and fees. Check which data remains with the provider after termination and how deletion or retention is evidenced. Price any month when two providers need to operate alongside one another. A transfer that depends on the outgoing operator's tools needs a specific plan and a test before the company counts it as a straightforward exit.
Approve a service the buyer can supervise
For the hypothetical wholesaler, the decisive questions could be who owns the order incident, whether the proposed team can restore the service and what the buyer can take away if it changes providers. Ask the decision maker to review the demonstrated results alongside the final agreement. Check that exclusions and negotiated changes appear in the documents the operations team will use, including the scope, support schedule and exit provisions.
Document any work the supplier will perform during onboarding to bring the estate up to the agreed standard. Separate those one-time tasks from the steady-state service. Check that credentials, inventory and monitoring are in place before responsibility transfers, and record who owns incidents during the overlap.
Set the first review after the service has handled routine work and at least one controlled incident or recovery exercise. Compare reports with actual tickets and the invoice. Verify that contact details still work, that privileges have not expanded without approval and that outstanding risks have owners. A managed cloud service is easier to judge when the buyer can see who did the work, how the result was verified and what remains its own responsibility.


Comments (0)
No comments yet. Be the first!