# Hosting, Security and Migration Annex

**Companion to:** Request for Proposals: Drupal Platform for [Organization]
**Issued by:** [Organization]  
**Responses due:** [date]

---

## How to use this annex

Attach this annex to the main RFP and require vendors to respond clause by clause, stating **Complies / Partially complies / Does not comply** and naming the evidence they have attached. A clause answered without evidence scores zero.

Replace every `[bracketed placeholder]` with your own figures. Where you genuinely do not know a value, keep the placeholder and require the vendor to propose one — an honest gap is easier to evaluate than a guessed number.

---

## 01. Ownership and hosting model

The five clauses that decide whether you can leave. Write them before you write anything about servers.

### R7.1 — Cloud account ownership

All production infrastructure for the platform must be provisioned inside a cloud account owned and contracted by [Organization] (AWS, Azure, Google Cloud or DigitalOcean). The supplier may be granted delegated administrative access, but [Organization] must retain owner-level access, the billing relationship, and the ability to continue operating the environment without the supplier.

**Evidence to request:** Ask each vendor to name the account owner and show, in a demonstration, where the root credentials and billing console sit.

### R7.2 — No proprietary runtime dependency

The application must run on a standard, documented runtime stack (for example PHP-FPM behind Nginx or Apache, MySQL or MariaDB, Redis or Memcached) that can be reproduced outside the supplier's tooling. Custom runtime agents are permitted only where the supplier documents a supported removal procedure.

**Evidence to request:** Ask for the runtime manifest and a written removal procedure. If removal requires the supplier, the dependency is real.

### R7.3 — Environment provisioning independence

The supplier must document how a new environment (development, staging or production) is created, and must demonstrate that [Organization] staff can create one after a half-day handover session.

**Evidence to request:** Make the handover session a contractual milestone, not a training slide in the final week.

### R7.4 — Billing transparency

Infrastructure costs must be billed to [Organization] directly by the cloud provider. The supplier must separately identify management, support and professional-services fees. Pass-through infrastructure charges, if any, must be shown at cost with the underlying invoice available for audit.

**Evidence to request:** Ask for a specimen invoice. If infrastructure and management are bundled into one per-site figure, you cannot audit either.

### R7.5 — Exit assistance

On termination or expiry, the supplier must provide, within [30] days and at no additional charge, a complete export of application code, configuration, content, media and database dumps in standard formats, infrastructure-as-code or documented runbooks describing the live environment, and [20] hours of transition assistance to the successor provider.

**Evidence to request:** Confirm the export formats in writing, and whether any egress or extraction fee applies. 'No export fee' is a specific claim worth testing.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R7.1 | ☐ | ☐ | ☐ | |
| R7.2 | ☐ | ☐ | ☐ | |
| R7.3 | ☐ | ☐ | ☐ | |
| R7.4 | ☐ | ☐ | ☐ | |
| R7.5 | ☐ | ☐ | ☐ | |

## 02. Environments, deployment and change control

How code reaches production, and how quickly you can undo a mistake.

### R7.6 — Environment parity

The supplier must provide at least three persistent environments (development, staging, production) that share the same runtime configuration, with a documented list of permitted differences. Additional ephemeral environments per feature branch must be available on request.

**Evidence to request:** Ask for the list of permitted differences. An empty list is a red flag; an honest list is a good sign.

### R7.7 — Automated deployment and rollback

Deployments must run from version control through an automated pipeline that includes a Composer build, configuration import, database update and cache rebuild. Any deployment must be reversible to the previous release within [15] minutes without data loss.

**Evidence to request:** Ask for a live rollback in the demonstration. Rollback claims are the most commonly overstated in Drupal proposals.

### R7.8 — Configuration management

All site configuration must be exported to code and deployed through the pipeline using a documented strategy (for example configuration split) covering environment-specific settings. Direct configuration changes in production are not permitted.

**Evidence to request:** Ask what happens when an editor changes a view in production. The answer should be 'it is blocked' or 'it is overwritten at next deploy'.

### R7.9 — Production data refresh

The supplier must support refreshing a non-production environment from production data, with an automated anonymization step for personal data, completed within [4] hours of request.

**Evidence to request:** Ask which fields are anonymized. 'All of them' is rarely true; ask for the mapping.

### R7.10 — Change control

Production changes outside the pipeline must follow a documented change process with a named approver at [Organization], a maintenance window, a tested rollback path and a post-change record.

**Evidence to request:** Ask how many emergency production changes occurred in the last 12 months and why.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R7.6 | ☐ | ☐ | ☐ | |
| R7.7 | ☐ | ☐ | ☐ | |
| R7.8 | ☐ | ☐ | ☐ | |
| R7.9 | ☐ | ☐ | ☐ | |
| R7.10 | ☐ | ☐ | ☐ | |

## 03. Runtime, caching and performance

Drupal is a database-heavy application: performance is a configuration decision, not a hosting slogan.

### R7.11 — Supported runtime versions

The platform must run a currently supported PHP major version (8.3 or later at the time of writing) with OPcache enabled, and must support Drupal 11 for the full contract term. The supplier must state its deprecation policy for PHP minor versions.

**Evidence to request:** Ask which PHP version is running in production today, and when it last changed.

### R7.12 — Object caching

A persistent object cache (Redis or Memcached) must be available to the application and enabled in all environments, with cache hit rate reported monthly.

**Evidence to request:** Ask for the current cache hit rate of a comparable site. Numbers below 85 per cent on a content site suggest misconfiguration.

### R7.13 — Edge caching and invalidation

The platform must provide page-level caching at the edge (CDN or reverse proxy) with cache-tag based invalidation on content change, so that published edits appear within [60] seconds without a full cache purge.

**Evidence to request:** Ask them to publish a change in the demonstration and time how long it takes to appear to an anonymous visitor.

### R7.14 — Performance budgets

The supplier must meet the following production budgets at the 75th percentile for the agreed reference pages: Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, Cumulative Layout Shift under 0.1, and server time to first byte under 800 milliseconds, measured with a named, agreed tool.

**Evidence to request:** Name the tool in the RFP. Hourly field-data and lab-data measurements disagree, and vendors will pick the flattering one.

### R7.15 — Scaling behaviour

The platform must scale horizontally without manual intervention to handle [3x] baseline traffic, and the supplier must provide evidence of a load test at that level on a comparable site.

**Evidence to request:** Ask when the last load test was run and what failed. A vendor who has never tested will improvise the answer.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R7.11 | ☐ | ☐ | ☐ | |
| R7.12 | ☐ | ☐ | ☐ | |
| R7.13 | ☐ | ☐ | ☐ | |
| R7.14 | ☐ | ☐ | ☐ | |
| R7.15 | ☐ | ☐ | ☐ | |

## 04. Backups and disaster recovery

Uptime promises are cheap. Restore evidence is not.

### R7.16 — Backup schedule and retention

The supplier must take automated backups of the database and uploaded files at least every [24] hours, retain daily backups for [35] days and monthly backups for [12] months, store them encrypted in a separate availability zone or region from production, and make them available to [Organization] on request.

**Evidence to request:** Ask for a copy of a backup index. If backups are described as 'managed by the provider' with no buyer access, you cannot test them.

### R7.17 — Recovery objectives

The platform must meet a recovery point objective of [15] minutes and a recovery time objective of [4] hours for production. The supplier must record and report actual recovery times for any real incident.

**Evidence to request:** Ask for the last three incident post-mortems with actual recovery times.

### R7.18 — Restore testing

The supplier must perform and document a full restore into a clean environment at least quarterly, and provide the most recent report, including the data point restored and the elapsed time, on request.

**Evidence to request:** This one clause removes most of the value of a vague DR promise, because it requires a document that either exists or does not.

### R7.19 — High availability

Production must run across at least two availability zones with automated failover, and the supplier must state the measured availability for the last [12] months against the contracted target of [99.9] per cent monthly.

**Evidence to request:** Ask for the availability report, not the architecture diagram. Diagrams show intention; reports show performance.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R7.16 | ☐ | ☐ | ☐ | |
| R7.17 | ☐ | ☐ | ☐ | |
| R7.18 | ☐ | ☐ | ☐ | |
| R7.19 | ☐ | ☐ | ☐ | |

## 05. Security, privacy and compliance

Every requirement here should produce a document, a log or a date. Adjectives do not count.

### R8.1 — Patch management

Critical Drupal core security advisories must be applied to production within [24] hours of release and non-critical advisories within [7] days. The supplier must notify [Organization] of each applied advisory and report the current patch status of core and contributed modules monthly.

**Evidence to request:** Ask what happened at the last critical Drupal advisory: when it was applied, by whom, and what the notification looked like.

### R8.2 — Edge protection

Production must sit behind a web application firewall and DDoS mitigation service with OWASP core-rule coverage, rate limiting on authentication endpoints, bot mitigation, and administrative access restricted to named networks or a zero-trust proxy.

**Evidence to request:** Ask for a screenshot of the WAF console and the current rule set version. Ask whether /user/login is rate limited.

### R8.3 — Transport and data protection

All traffic must use TLS 1.2 or later with HSTS enabled. Data at rest, including backups and media, must be encrypted. [Organization] must be able to specify the geographic region in which data is stored, and the supplier must not replicate data outside that region without written approval.

**Evidence to request:** Ask which region hosts production and which regions hold backups. These are frequently different and undisclosed.

### R8.4 — Access control and audit

Supplier access to production must use named individual accounts with multi-factor authentication and least-privilege roles. Shared credentials are prohibited. Privileged actions must be logged with a retained audit trail of at least [12] months, available to [Organization] on request.

**Evidence to request:** Ask how many shared accounts exist and who holds them. The honest answer is usually 'a few, for emergencies'.

### R8.5 — Assurance evidence

The supplier must provide, within five business days of request, its current SOC 2 Type II report or ISO 27001 certificate with statement of applicability, the scope of coverage including whether hosting infrastructure is in scope, a summary of the most recent external penetration test with remediation status, and a completed security questionnaire.

**Evidence to request:** Read the scope paragraph of the SOC 2 report. Many cover the application but not the underlying infrastructure you are relying on.

### R8.6 — Incident notification

The supplier must notify [Organization] of any confirmed or suspected security incident affecting its data within [24] hours of detection, provide a written timeline within [72] hours, and participate in a joint post-incident review within [10] business days.

**Evidence to request:** Ask for the incident response plan and the name of the role that makes the notification call.

### R8.7 — Vulnerability management

The supplier must run authenticated vulnerability scanning against production at least monthly, maintain a remediation target of [14] days for high-severity findings and [30] days for medium, and provide scan summaries on request.

**Evidence to request:** Ask for the last three scan summaries, including open findings and their age.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R8.1 | ☐ | ☐ | ☐ | |
| R8.2 | ☐ | ☐ | ☐ | |
| R8.3 | ☐ | ☐ | ☐ | |
| R8.4 | ☐ | ☐ | ☐ | |
| R8.5 | ☐ | ☐ | ☐ | |
| R8.6 | ☐ | ☐ | ☐ | |
| R8.7 | ☐ | ☐ | ☐ | |

## 06. Observability, support and service levels

The clauses that determine whether you find out about an outage before your users do.

### R10.1 — Monitoring and alerting

The platform must provide application performance monitoring with transaction traces, error tracking with stack traces, uptime checks at [60]-second intervals from at least two regions, and alerting to [Organization]'s named contacts. [Organization] must have read access to the monitoring dashboards.

**Evidence to request:** Ask to see a live dashboard for a comparable site during the demonstration.

### R10.2 — Logging and retention

Application, web server and access logs must be aggregated in a searchable system with at least [90] days of retention and be exportable to [Organization] on request.

**Evidence to request:** Ask whether the buyer can run their own query, or whether every log request becomes a support ticket.

### R10.3 — Severity definitions and targets

The supplier must respond to Severity 1 incidents (production unavailable or data loss) within [30] minutes, 24 hours a day, and to Severity 2 incidents (major function impaired) within [2] business hours, with resolution targets of [4] hours and [1] business day respectively.

**Evidence to request:** Ask when the on-call rotation last ran a live test, and who is on call tonight.

### R10.4 — Status communication

The supplier must operate a public or buyer-accessible status page updated within [30] minutes of a declared incident, and provide a monthly service report covering availability, incidents, patching, backup verification and support volumes.

**Evidence to request:** Ask for last month's service report. Its existence tells you more than any promise in the proposal.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R10.1 | ☐ | ☐ | ☐ | |
| R10.2 | ☐ | ☐ | ☐ | |
| R10.3 | ☐ | ☐ | ☐ | |
| R10.4 | ☐ | ☐ | ☐ | |

## 07. Migration, cutover and launch

Most launch failures are migration failures. Buy the plan explicitly, not as an assumption.

### R9.1 — Content and URL inventory

The supplier must produce a content inventory listing every content type, entity count, media asset and user role to be migrated, and a URL inventory of all existing addresses, before migration work begins.

**Evidence to request:** Ask how they would handle a URL that no longer has a corresponding node. The answer reveals whether they have done this before.

### R9.2 — Redirect mapping

A one-to-one redirect map must be delivered and tested for the top [1,000] existing URLs by traffic, plus all URLs with inbound links from [Organization]'s top [50] referrers, with a 301 to the closest equivalent page. No production URL may return a 404 after cutover.

**Evidence to request:** Ask for the redirect QA method. Crawl-and-compare is the only defensible answer.

### R9.3 — Dry runs

At least [2] full migration rehearsals must be completed into a staging environment, each including content, media, configuration and redirects, with a written delta report and a time estimate for the production run.

**Evidence to request:** Dry runs are the single best predictor of cutover risk. Vendors who propose one rehearsal are proposing to discover problems on launch night.

### R9.4 — Cutover plan and rollback

The supplier must deliver a cutover plan with a timed sequence, named owners, a content freeze window, DNS TTL strategy, a go/no-go checklist, and a pre-agreed rollback trigger that requires no further approval to execute.

**Evidence to request:** Ask who has authority to call the rollback. If the answer is a committee, you do not have a rollback plan.

### R9.5 — Post-launch hypercare

A [30]-day hypercare period must be included at no additional cost, covering daily monitoring of error rates, 404s, redirect coverage and Core Web Vitals, with a weekly written report and a [4]-hour response target for regression defects.

**Evidence to request:** Ask what happens on day 31. The answer should not be 'support begins at our standard rate'.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R9.1 | ☐ | ☐ | ☐ | |
| R9.2 | ☐ | ☐ | ☐ | |
| R9.3 | ☐ | ☐ | ☐ | |
| R9.4 | ☐ | ☐ | ☐ | |
| R9.5 | ☐ | ☐ | ☐ | |

## 08. Exit, portability and data return

The clauses you will only need once, and will be very glad to have written.

### R15.1 — Data return

On request at any time during the contract, and within [5] business days of termination, the supplier must deliver a complete export of content (structured, not HTML-only), media in original formats, database dumps, configuration and code repositories, and analytics data in an open format.

**Evidence to request:** Ask for a sample export of a comparable site. Structured content export is the requirement most often quietly unmet.

### R15.2 — No exit penalties

No fee, penalty or notice period beyond [90] days may apply to the export of data or the termination of hosting services, and the supplier must not withhold data or access as leverage in a commercial dispute.

**Evidence to request:** Ask whether the clause is acceptable, in writing, before award. A refusal is useful information.

### R15.3 — Documented handover

The supplier must maintain, and deliver on request, architecture documentation, a runbook covering deployment, restore and incident response, credential inventory with ownership, and a list of all third-party services with their renewal dates.

**Evidence to request:** Ask to see the runbook for an existing client, redacted. Documentation that exists is obvious; documentation that does not is improvised.

### R15.4 — Continuity of service

If the supplier ceases trading or the contract is terminated for cause, [Organization] must be able to continue operating the platform without supplier intervention, using the documentation, infrastructure and credentials held under R7.1 and R15.3.

**Evidence to request:** This is the clause that makes 'no vendor lock-in' a contractual statement rather than a marketing one.

### Vendor response

| Clause | Complies | Partially | Does not | Evidence attached |
| --- | --- | --- | --- | --- |
| R15.1 | ☐ | ☐ | ☐ | |
| R15.2 | ☐ | ☐ | ☐ | |
| R15.3 | ☐ | ☐ | ☐ | |
| R15.4 | ☐ | ☐ | ☐ | |

---

## 09. Migration and cutover requirements

Require a written plan for each phase below. Migration is the most commonly under-quoted element of a Drupal project, and the phase most likely to decide whether launch night succeeds.

### T-12 weeks — Inventory and decide

Crawl the existing site. Count content by type, media volume, languages and users. Identify the top 1,000 URLs by traffic and the pages that carry revenue or legal obligation. Decide what will not be migrated, and say so in writing.

### T-10 weeks — Map the redirects

Build the URL-to-URL map before the build starts, not after. Every old address needs an owner and a destination. Anything unmapped is a promise to lose search traffic.

### T-6 weeks — Rehearse the migration

Run the first full migration into staging: content, media, configuration, redirects, search index. Time it. Write down everything that broke and what it cost to fix.

### T-3 weeks — Rehearse again, then certify

Second rehearsal against the same target, with the delta report. Sign off a smoke-test list: the twenty things that must work on launch night, in priority order.

### T-1 week — Freeze and prepare

Lower DNS TTL to 300 seconds five days out. Freeze content. Brief editors on the new workflow. Confirm who can call the go/no-go and who can call rollback, by name.

### Launch night — Execute the sequence

Final content pull, redirect deployment, cache warm, DNS switch, smoke tests in order, monitoring watch. If the smoke test fails twice on the same item, roll back — that decision was made weeks ago.

### T+30 days — Prove it worked

Monitor 404s, redirect coverage, Core Web Vitals and search console coverage daily for a month. Compare against the pre-launch baseline. Publish the result internally so the next project starts from evidence.

---

## 10. Scoring guidance for this annex

Score hosting and infrastructure as one criterion, not as a footnote to the build. A workable weighting is 15 per cent of the total, with anything answered 'does not comply' on sections 1, 5 or 8 requiring a written explanation before the proposal can be shortlisted.

Annex maintained by the Drupal RFP Kit (devpanel.com). Adapted freely; not legal advice.