CLOUD
Business

Writing a Hosting RFP for Saudi Organizations: Clauses You Should Not Skip

CLOUD|October 29, 2026|7 min read|62 views
Writing a Hosting RFP for Saudi Organizations: Clauses You Should Not Skip

A strong hosting RFP pins data residency inside the Kingdom, an SLA written into the contract with credits, backups with retention and restore targets, evidence-based NCA compliance, and an exit clause that guarantees data handover within 30 days.

A solid hosting RFP protects an organization from three expensive mistakes: data stored outside the Kingdom without your knowledge, an availability promise that no contract backs, and a painful exit when the engagement ends. That is why the RFP should include seven clauses you cannot afford to skip: data residency inside Saudi Arabia naming the city and data center, an SLA written into the contract with a specific uptime figure and clear compensation for breaches, backups with frequency, retention, storage location and restore time, compliance with National Cybersecurity Authority controls backed by evidence rather than a general pledge, access and privileges covering who can enter the server and when, support and escalation with written response times, and exit and data handover in standard formats over at least 30 days. Evaluation criteria come next, and the split we consider balanced is 60% technical and 40% financial, because the cheapest weak bid costs more at the first outage. This article gives you clause wording ready to adapt, a weighted scoring table, and ten questions that expose a weak provider before the award.

Why Hosting RFPs Usually Fail

Most RFPs we see are written like hardware purchases, listing CPU count, memory and disk, then price. Those specs matter, yet they cover no more than 30% of the real risk. Outages rarely happen because the processor is small. They happen because the backup was never tested, because the provider answers a ticket after 6 hours, or because data moved to a data center outside the Kingdom during maintenance nobody announced. A good RFP fits the specs on one page and spends the rest on operations and guarantees.

Core Clauses with Ready Wording

1. Data residency

Suggested text: "The contractor shall store and process all of the organization's data, including backups and logs, in data centers located in the Kingdom of Saudi Arabia, shall name the city and data center in its proposal, and shall not move the data outside the Kingdom in any form without prior written approval." Notice that the clause covers backups and logs, since some providers keep the server local while shipping backups abroad.

2. Service level agreement

Ask for a numeric uptime figure inside the contract, not on a marketing page. The gap between figures is large in hours:

UptimeAllowed downtime per year
99%About 87.6 hours
99.9%About 8.8 hours
99.95%About 4.4 hours
99.99%About 53 minutes

Tie the figure to explicit compensation, such as a percentage credit on the contract value for every 0.1% shortfall, and request a precise definition of measurement: where availability is measured from, and whether scheduled maintenance counts as downtime.

3. Backups and retention

Specify four numbers: backup frequency (at least daily for live systems), retention (30 days is a reasonable minimum for an ERP), location (a site separate from the primary server), and the target RTO and RPO. Also require a documented restore test at least once a quarter, with a written report delivered to the organization.

4. NCA compliance

Do not settle for "the contractor complies with regulations." Require a compliance matrix in the proposal that maps each Essential Cybersecurity Control (ECC) and Cloud Cybersecurity Control (CCC) to the provider's actual measure and its evidence, covering password policy, two-factor authentication on control panels, encryption in transit, log retention for a defined period, and vulnerability and patch management.

5. Access and privileges

Define who holds root or Administrator rights, how every login session is recorded, and who approves provider staff access to the server. For custom systems, full privileges usually stay with the organization's team or its developer while the provider only touches the infrastructure, and that needs to be written explicitly.

6. Support and escalation

Write response times by severity, such as 30 minutes for a full outage, 4 hours for a partial issue and one business day for routine requests, along with a direct phone line for critical cases and named roles in the escalation ladder.

7. Exit and data handover

Suggested text: "Upon expiry or termination, the contractor shall keep full access to the organization's data available for no fewer than 30 days, deliver it in open standard formats (database exports in SQL and files as-is), then permanently delete it and provide a written deletion certificate." This clause protects you from lock-in and keeps competition real at the next renewal.

Technical and Financial Scoring

Set the weights before opening any bids so price does not sway the technical score. Here is a practical split for a mid-size organization:

CriterionWeightHow to measure
Data residency and compliance15%Compliance matrix with evidence, named data center
SLA and credits15%Contractual figure and credit mechanism
Backup and restore10%RPO, RTO and test reports
Support and escalation10%Response times and channels
Experience and references10%Clients with similar systems, years in operation
Financial offer40%Full annual cost including VAT and add-ons

For the financial score, compare the full cost of a year rather than the server price alone. Include licenses (Windows, cPanel or Plesk), backups, DDoS protection and extra IP addresses. As an example, CLOUD's Enterprise plan (8 vCPU and 16GB RAM) costs 18,000 SAR a year, and adding Windows Server at 1,500 SAR, daily backups with 30-day retention at 2,000 SAR and DDoS protection at 1,200 SAR brings the total to 22,700 SAR including VAT. Ask every bidder for the same breakdown so you compare number against number. Add-on details are on the pricing page.

Ten Questions That Expose a Weak Provider

  1. Which city and data center will host our server, and where exactly are backups stored?
  2. Is the uptime figure in the contract, and what is the actual credit for a breach?
  3. When did you last run a restore test, and how long did it take?
  4. Who on your team can access our server, and how will we know they did?
  5. What is your real response time for a full outage reported at 3 a.m.?
  6. Do you run a public status page showing past incidents?
  7. How do we receive our data when the contract ends, and in what format?
  8. Can resources be upgraded without a reinstall or long downtime?
  9. What does the quoted price leave out?
  10. Do you support the organization's developers during migration and operation?

A vague answer to any of the first five deserves a clear deduction in the technical score. A provider that owns real infrastructure answers with numbers and city names, while a reseller tends to answer in generalities.

Technical Specs on a Single Page

After the operational clauses, write the specs as a clear minimum with room to grow, for example 8 vCPU, 16GB RAM, 250GB SSD, 1TB of yearly transfer and a named OS version, plus the option to add resources during the term at unit prices declared up front. Unit prices matter because they prevent surprises as you grow. At CLOUD, each extra vCPU is 500 SAR a year, each 2GB of RAM is 600 SAR and each 100GB of SSD is 500 SAR. You can build the spec yourself in the cloud server configurator and download an official quote to attach to the tender file.

Term and renewal

Renewal pricing is a clause people often forget. Ask the provider to lock unit prices for the full term and to cap any increase at renewal, for example no more than 10% unless notified in writing at least 90 days ahead. Ask too what happens when resources are upgraded mid-year, where the fair practice is paying the difference for the remaining period only. A one-year contract with an option to renew for two more years gives the organization budget stability without tying it to a provider it no longer wants, since the exit clause stays in force either way.

Practical Steps Before Publishing the RFP

  1. Form a small team from IT, finance and legal, and agree on weights before drafting any clause.
  2. Copy the seven clauses above and adjust the numbers to your systems, especially RPO and RTO.
  3. Attach a standard financial form that forces every bidder to break down the annual cost including VAT.
  4. Add the ten questions as a mandatory section of the technical proposal.
  5. Hold a single clarification session for all bidders and publish the answers to everyone.

An RFP written this way takes an extra week to prepare, and it saves months of disputes and outages over the life of the contract.

Share