Choosing an IT support provider is not the same as purchasing office supplies. The provider may hold administrator privileges, connect remotely to devices, manage cloud accounts, see network configurations and become involved in backups, security alerts and employee access. A weak provider can create risk even when the monthly service appears responsive.
Due diligence should therefore go beyond references, response-time promises and a list of technical certifications. Management needs evidence that the provider can protect access, maintain service, document the environment, manage its own people and hand control back cleanly if the relationship ends.
This framework is designed for UAE organisations that want to assess an outsourced IT or managed-services provider before appointment or contract renewal.
Begin with the access the provider will receive
The first question is not how many engineers the provider has. It is what those engineers will be able to access.
Create a list covering:
- Microsoft 365, Google Workspace or other cloud administration;
- firewalls, switches, wireless systems and VPNs;
- servers, storage and virtualization;
- endpoint-management and remote-support tools;
- backup platforms and recovery consoles;
- security products and alert portals;
- business applications and databases;
- internet-provider and telecom portals;
- hardware, warranty and licensing accounts;
- documentation containing credentials or architecture details.
The provider should explain how access is granted, restricted, monitored, reviewed and removed. Shared administrator passwords and permanent access for every technician are poor signs.
Verify remote-access controls
Remote monitoring and management tools are useful because they allow fast support. They are also powerful. If an attacker compromises the provider or a remote-support account, the customer environment may be exposed.
Ask the provider to demonstrate:
- multifactor authentication for staff and privileged access;
- named technician accounts rather than shared credentials;
- role-based permissions;
- approval or logging for sensitive actions;
- device and location restrictions where appropriate;
- session logging and audit history;
- rapid access removal when an employee leaves;
- separation between customer environments;
- emergency suspension of remote tools;
- review of inactive accounts.
CISA and international cyber authorities have warned that managed service providers are attractive targets because of their trusted access to customer environments. Their joint guidance for MSPs and customers recommends transparent discussion of responsibilities, stronger authentication and controlled access.
Assess the provider’s own security programme
A provider cannot credibly manage customer security while neglecting its own systems. Due diligence should cover the provider’s:
- identity and access controls;
- endpoint protection and patching;
- email security;
- backup and recovery;
- security monitoring;
- incident-response process;
- vulnerability management;
- staff awareness and training;
- data handling and retention;
- physical access to offices and equipment.
Do not ask only whether a policy exists. Request examples of how the policy is operated, such as access-review records, incident exercises or restore-test evidence.
Understand who will actually deliver the service
The sales team may be experienced while daily support is delivered by junior staff, contractors or an external service desk. The contract should identify the delivery model.
Ask:
- Which teams handle service desk, onsite work, cloud, networks, security and projects?
- Which locations and time zones are used?
- Are subcontractors involved?
- How are technicians vetted and trained?
- What happens when the primary engineer is absent?
- How are escalations assigned?
- Which skills are available internally and which depend on partners?
- How is customer knowledge transferred between engineers?
A customer should not depend on one person who holds all the passwords and environment knowledge.
Review staffing resilience and service capacity
A provider may support many customers with a small team. That model can work if automation, triage and escalation are strong. It can also fail during leave periods, major incidents or project peaks.
Request evidence of:
- service-desk coverage and backup staffing;
- onsite engineer availability;
- after-hours arrangements;
- specialist escalation;
- ticket volume and ageing;
- customer-to-engineer ratios where the provider is willing to share them;
- continuity if an office or tool becomes unavailable;
- handover between shifts or locations.
The objective is not to demand a large headcount. It is to confirm that the promised service can continue when normal conditions change.
Examine documentation ownership
The provider should create and maintain useful records, but the customer should retain ownership and access.
Documentation may include:
- asset and user registers;
- network diagrams;
- firewall and switch configurations;
- cloud tenant and licensing records;
- administrator and service accounts;
- backup schedules and recovery procedures;
- vendor contacts and contract details;
- standard operating procedures;
- major incident records;
- open risks and improvement plans.
Confirm where this information is stored, how it is protected, who can export it and what happens at contract end.
Test backup and recovery responsibilities
The provider may monitor backups without owning the backup platform. It may own the tool but depend on the customer for storage or application support. These boundaries must be clear.
Ask:
- Which systems and data are included?
- Who receives failed-job alerts?
- Who investigates and within what period?
- How often are restores tested?
- Are offline, immutable or separately protected copies used where appropriate?
- Who approves retention and recovery objectives?
- Who communicates during a recovery event?
- How is recovery evidence reported?
Backup success percentages are not enough. The provider should be able to show that selected data has been restored and validated.
Review incident-response coordination
A serious security or availability incident may involve the provider, customer leadership, cyber specialists, insurers, legal advisers, cloud vendors and telecom companies.
The due-diligence review should establish:
- how incidents are identified and classified;
- who has authority to isolate systems or accounts;
- how evidence is preserved;
- who communicates with management;
- when specialist incident response is invoked;
- how third parties are coordinated;
- how lessons and corrective actions are recorded.
NIST Cybersecurity Framework 2.0 organises risk-management outcomes across Govern, Identify, Protect, Detect, Respond and Recover. The NIST CSF 2.0 is a useful reference for ensuring the provider’s proposal covers governance and recovery rather than focusing only on protective tools.
Check data location, handling and confidentiality
The provider may collect logs, screenshots, ticket attachments, configuration exports and contact details. Ask:
- What customer information is stored?
- Where is it hosted?
- Which employees and subcontractors can access it?
- How long is it retained?
- How is it encrypted?
- How are confidential files transferred?
- What happens when the contract ends?
- How will a provider-side breach be reported?
These answers should align with the customer’s contractual, regulatory and internal requirements.
Examine subcontractors and fourth parties
A provider may rely on a remote service desk, security monitoring company, cloud platform, backup vendor or field-service partner. The customer should understand this supply chain.
Request:
- the categories of subcontractors used;
- services they perform;
- countries or regions involved;
- access they receive;
- security and confidentiality requirements imposed on them;
- how their performance is monitored;
- how changes are communicated to the customer.
CISA provides a vendor-assessment fact sheet for small and medium businesses that includes the vetting of managed service providers. Its vendor and supplier assessment guidance can help procurement teams structure this review.
Review commercial and operational stability
The customer does not need access to every financial detail, but it should consider whether the provider can sustain the promised service.
Relevant questions include:
- How long has the provider delivered comparable services?
- Does it carry appropriate business and professional insurance?
- Are critical tools properly licensed?
- Does the provider have a continuity plan?
- How concentrated is the business around a few employees or customers?
- How are acquisitions, ownership changes or major staffing changes handled?
- Are there unresolved legal or service disputes that should be considered?
References should be selected for similarity of environment and service, not only for brand recognition.
Evaluate the contract’s responsibility matrix
The contract should show who is responsible for key activities.
| Activity | Customer responsibility | Provider responsibility |
|---|---|---|
| User onboarding | Approved request, role and start date. | Account, license, device and access setup. |
| Backup | Approve scope, retention and recovery priority. | Operate, monitor, investigate failures and test restores as contracted. |
| Security alert | Provide business context and decisions. | Triage, contain within authority and escalate. |
| Vendor outage | Maintain valid contract and approvals. | Open, track and coordinate the support case. |
| Major change | Approve business impact and window. | Plan, test, implement and document. |
If both parties assume the other owns an activity, the gap will eventually appear during an incident.
Require a controlled transition-in plan
The first weeks of service should include:
- environment discovery;
- credential validation and secure transfer;
- asset and user baseline;
- open-ticket review;
- backup and security assessment;
- vendor and contract inventory;
- monitoring deployment;
- priority and escalation agreement;
- initial risks and quick improvements;
- user communication.
Transition should have acceptance criteria. Support should not be declared fully operational simply because the contract start date has arrived.
Plan the exit before signing
A strong provider should be comfortable with an orderly exit clause.
The contract should require:
- return of customer data and documentation;
- export of tickets, configurations and asset records;
- removal of provider accounts and tools;
- transfer of vendor portals and licenses;
- cooperation with the incoming provider;
- confirmation of data deletion where required;
- defined transition support and charges;
- continued service during the notice period.
The customer should retain ownership of domains, tenants, licenses, cloud subscriptions and primary administrator accounts.
The due-diligence evidence checklist
- Remote-access and privileged-account control evidence.
- Provider security-policy and operational examples.
- Delivery-team and subcontractor model.
- Staffing continuity and escalation coverage.
- Sample customer documentation and reporting.
- Backup, restore and recovery evidence.
- Incident-response and communication process.
- Data handling, hosting and retention details.
- Commercial and operational resilience information.
- Clear responsibility matrix.
- Transition-in plan.
- Exit and handover obligations.
Frequently asked questions
Should an IT provider share its internal security documents?
It may not share every confidential detail, but it should provide enough evidence to demonstrate that access, security, continuity and incident responsibilities are controlled.
Are certifications enough to complete due diligence?
No. Certifications can support confidence, but customers should still verify how controls operate in the specific service being purchased.
Should the customer own administrator accounts?
The customer should retain ownership of its tenants, domains and core accounts. Provider access should use named, controlled identities.
How often should due diligence be repeated?
Review it at contract renewal and after significant service, ownership, staffing, tool or security changes.
What is the most important exit requirement?
The customer must be able to recover its documentation, credentials, configurations, data and vendor relationships without depending indefinitely on the outgoing provider.
Due diligence is not intended to make outsourcing difficult. It ensures that the service relationship begins with clear evidence, controlled access and an exit path. Organisations seeking an accountable regional operating model can review managed IT services across UAE and India.
