# Request for Proposals: Drupal Platform for [Organization]

**Issued by:** [Organization legal name]
**Reference:** [RFP-2026-001]
**Issue date:** [date]
**Questions close:** [date, time, time zone]
**Responses due:** [date, time, time zone]
**Contract award:** [date]
**Intended start:** [date]

---

## How to use this template

Replace every `[bracketed placeholder]`. Delete any instruction in italics before issuing. Keep the numbering: vendors will reference clause numbers in their responses, and consistent numbering makes the evaluation considerably faster.

Three rules make this template work:

1. **Every requirement must be verifiable.** If you cannot say what evidence would prove compliance, the requirement is not ready.
2. **Publish the weights.** Vendors who know how they will be scored write better proposals and complain less afterwards.
3. **Never leave hosting to the contract stage.** Ownership of the infrastructure is a procurement decision, not an implementation detail.

---

## 1. Summary and background

[Organization] is [one sentence describing what the organization does and who it serves]. We are seeking a partner to [design and build / replatform / upgrade / support] our Drupal platform.

**Why now.** [State the trigger: current platform end-of-life, failed vendor relationship, new funding, accessibility obligation, merger, or strategic mandate. Be specific and dated.]

**Current state.** Our site currently runs on [platform and version], hosted by [host or "internally"], with approximately [number] pages across [number] content types, [number] editor accounts, and the following integrations: [list]. Traffic averages [number] sessions per month, with peaks of [number] during [event or season].

**What this RFP decides.** We will award a contract for [scope summary] to a single supplier, commencing [date], with an option to extend support for [number] additional years.

**Who decides.** Proposals will be evaluated by a panel chaired by [name, role], with representatives from [functions]. The panel's decision is subject to [board / executive / procurement] approval.

*Instructions: no more than one page. A vendor should be able to tell from this page whether they have delivered something comparable.*

---

## 2. Objectives and success measures

| # | Objective | Measure | Baseline | Target |
|---|-----------|---------|----------|--------|
| O1 | [e.g. Reduce editor time to publish] | [Time on task, 5 editors] | [45 min] | [15 min] |
| O2 | [e.g. Improve page experience] | [LCP at p75, mobile] | [4.1 s] | [under 2.5 s] |
| O3 | [e.g. Meet accessibility obligations] | [WCAG 2.2 AA conformance audit] | [Not assessed] | [Zero critical issues] |
| O4 | [e.g. Reduce hosting cost] | [Annual infrastructure spend] | [$X] | [$Y] |
| O5 | [e.g. Grow qualified enquiries] | [Form completions per month] | [N] | [N + 30%] |

**Out of scope as objectives.** This project does not aim to [e.g. rebrand the organization, replace the CRM, build a mobile app]. Proposals that expand into these areas will not score higher.

*Instructions: three to five objectives. If you cannot name a baseline, say "not currently measured" and require the vendor to establish one in month one.*

---

## 3. Scope of work

### 3.1 In scope

| # | Work package | Deliverable | Buyer owner |
|---|--------------|-------------|-------------|
| WP1 | Discovery and content strategy | Discovery report, content model, sitemap | [name] |
| WP2 | Design system | Component library, page templates, brand application | [name] |
| WP3 | Drupal build | Configured site in version control, deployable to all environments | [name] |
| WP4 | Content migration | Migrated content with reconciliation report | [name] |
| WP5 | Redirect mapping | 1:1 redirect map for top [1,000] URLs by traffic | [name] |
| WP6 | Integrations | [List each system and the integration deliverable] | [name] |
| WP7 | Accessibility | WCAG 2.2 AA conformance report and remediation | [name] |
| WP8 | Hosting and environments | Provisioned Dev/Test/Live with deployment pipeline | [name] |
| WP9 | Training and documentation | Editor training, runbook, handover session | [name] |
| WP10 | Launch and hypercare | Cutover execution, 30-day hypercare report | [name] |
| WP11 | Support and maintenance | SLA-backed support from [date] | [name] |

### 3.2 Out of scope

The following are excluded and must not be priced: [ongoing content entry beyond WP4 volume], [copywriting beyond [number] pages], [photography or video production], [third-party licence fees], [translation services], [systems not listed in section 6], [hardware].

### 3.3 Buyer responsibilities

[Organization] will provide: brand assets by [date]; a named product owner available [hours] per week; content and subject-matter experts for review cycles; access to systems listed in section 6 including test credentials by [date]; [number] rounds of consolidated feedback within [5] business days; and a security review slot in [month].

### 3.4 Assumptions

Prices must state the assumptions they depend on. Where an assumption proves false, the change must be priced against the rate card in section 12 before work begins.

*Instructions: the out-of-scope list is the most commercially valuable page in this document. Write it defensively.*

---

## 4. Functional and content requirements

### 4.1 Content model

The platform must support the following content types. Vendors should propose the field structure, but must meet these editorial outcomes.

| Content type | Purpose | Key fields | Relationships |
|--------------|---------|------------|---------------|
| [Landing page] | [Campaign entry point] | [Hero, intro, component blocks, CTA] | [References programme, person] |
| [Article] | [News and updates] | [Title, summary, body, image, date] | [References topic, author] |
| [Programme] | [Service description] | [Title, overview, eligibility, contact] | [Referenced by landing page] |
| [Person] | [Staff profile] | [Name, role, biography, image] | [Referenced by article] |
| [Event] | [Dated activity] | [Title, dates, location, registration] | [References programme] |

### 4.2 Editorial workflow

- R4.1 The platform must support at least three workflow states (draft, in review, published) with at least four roles and configurable transitions between them.
- R4.2 Editors must be able to preview unpublished content exactly as it will appear to an anonymous visitor before publication.
- R4.3 Scheduled publication and scheduled unpublishing must be available without custom code.
- R4.4 Revision history must retain at least [10] revisions per node with the ability to revert.
- R4.5 Content must be translatable at the field level where [languages] are required.

### 4.3 Search and listing

- R4.6 Site search must index all published content types and return results within [500 ms] at the 95th percentile.
- R4.7 Search results must support faceting by [content type, topic, date].
- R4.8 Listing pages must support manual ordering and automatic ordering by date, with editors able to pin items.

### 4.4 Volume and performance expectations

The platform must handle [number] nodes, [number] media items totalling [size], [number] editor accounts and [number] concurrent anonymous users at peak without degradation beyond the performance budgets in section 7.

*Instructions: describe outcomes and volumes, not module names. Naming modules narrows the solution space and vendors will price the modules rather than the outcome.*

---

## 5. Design, accessibility and user experience

- R5.1 All public-facing pages must conform to WCAG 2.2 Level AA. Conformance must be verified by a combination of automated testing and manual testing with assistive technology, and evidenced by a published conformance report per page template.
- R5.2 The design system must be delivered as reusable components with documented usage, states and accessibility notes.
- R5.3 The interface must support [browsers and devices], with graceful degradation for [older browsers].
- R5.4 Usability testing with at least [8] representative users must be conducted at [prototype and pre-launch] stages, with findings and resolutions reported.
- R5.5 The design must accommodate content in [languages], including [right-to-left] where required.
- R5.6 Print stylesheets must be provided for [list of page templates].

*Instructions: accessibility as a numbered clause with a verification method, not a statement of intent. If it is in your funding agreement, quote the obligation verbatim.*

---

## 6. Integrations, data and identity

| System | Direction | Protocol | Owner | Authentication | Acceptance test |
|--------|-----------|----------|-------|----------------|-----------------|
| [CRM] | Outbound | [REST] | [IT] | [OAuth 2.0] | [Form submission appears as a lead within 60 s] |
| [Identity provider] | Inbound | [SAML 2.0] | [IT] | [SAML] | [Staff can sign in with corporate credentials] |
| [Payment provider] | Bidirectional | [REST] | [Finance] | [API key] | [Test transaction completes and reconciles] |
| [Analytics] | Outbound | [Script/GTM] | [Marketing] | [n/a] | [Events visible in dashboard within 24 h] |

- R6.1 Each integration must fail gracefully: if a third-party system is unavailable, the site must remain functional and queue or surface the failure to editors.
- R6.2 Integration credentials must be stored in a secrets manager or environment configuration, never in the codebase.
- R6.3 The supplier must document each integration's contract, including rate limits and retry behaviour.

*Instructions: an integration with no named owner and no acceptance test will be the first thing to slip.*

---

## 7. Hosting, infrastructure and operations

*This section is the commercial heart of the document. Do not defer it. A fuller clause library is available in the companion hosting annex.*

### 7.1 Ownership and model

- R7.1 Production infrastructure must be provisioned in a cloud account contracted and owned by [Organization] / [or: in the supplier's platform under the terms in R7.4]. The supplier must state the ownership model explicitly and describe what happens to the platform if the supplier relationship ends.
- R7.2 [Organization] must retain owner-level access to the cloud account, the billing relationship, and the ability to revoke supplier access at any time.
- R7.3 Infrastructure charges must be identified separately from management and support fees. Where infrastructure is resold, the markup must be disclosed.

### 7.2 Environments and deployment

- R7.4 The supplier must provide development, staging and production environments with documented parity and on-demand feature-branch environments.
- R7.5 Deployment must run from version control through an automated pipeline including Composer build, configuration import, database updates and cache rebuild, and be reversible within [15] minutes.
- R7.6 Configuration must be managed in code; direct production configuration changes are not permitted.

### 7.3 Runtime and performance

- R7.7 The platform must run a currently supported PHP version (8.3+) with OPcache, and support Drupal 11 for the contract term.
- R7.8 A persistent object cache (Redis or Memcached) must be enabled in all environments, with monthly hit-rate reporting.
- R7.9 Page caching at the edge must be enabled with tag-based invalidation on content change.
- R7.10 Production budgets at p75: LCP under 2.5 s, INP under 200 ms, CLS under 0.1, TTFB under 800 ms, measured with [named tool].

### 7.4 Backup and recovery

- R7.11 Automated encrypted backups at least every [24] hours, retained [35] days daily and [12] months monthly, stored in a separate availability zone.
- R7.12 Recovery point objective of [15] minutes and recovery time objective of [4] hours, with actual recovery times reported after any incident.
- R7.13 A documented full restore test at least quarterly, with the most recent report available on request.

---

## 8. Security, privacy and compliance

- R8.1 Critical Drupal core security advisories must be applied to production within [24] hours of release; other advisories within [7] days. Monthly patch status reporting is required.
- R8.2 Production must sit behind a WAF with OWASP core rules, DDoS mitigation, rate limiting on authentication endpoints, and administrative access restricted to named networks or a zero-trust proxy.
- R8.3 TLS 1.2 or later with HSTS; encryption at rest for data, media and backups; data stored in [region] with no replication outside it without written approval.
- R8.4 Named individual accounts with MFA and least privilege for all supplier access; shared credentials prohibited; privileged action audit logs retained [12] months.
- R8.5 Evidence available within five business days: SOC 2 Type II or ISO 27001 with scope statement, most recent external penetration test summary, completed security questionnaire.
- R8.6 Security incidents affecting [Organization] data must be notified within [24] hours, with a written timeline within [72] hours and a joint review within [10] business days.
- R8.7 Compliance obligations applicable to this project: [list from: WCAG 2.2 AA, GDPR/DPA, HIPAA, PCI DSS, FedRAMP, state security rider, records retention].

*Instructions: replace adjectives with documents. "Must be secure" is unscoreable; "must provide a SOC 2 Type II report covering the hosting layer" is a five-minute check.*

---

## 9. Migration, launch and cutover

- R9.1 The supplier must produce a content inventory (types, counts, media volume, users) and a URL inventory before migration begins.
- R9.2 A 1:1 redirect map must cover the top [1,000] URLs by traffic and all URLs receiving inbound links from the top [50] referrers. No production URL may return a 404 after cutover.
- R9.3 At least [2] full migration rehearsals must be completed in staging, each with a written delta report and a timing estimate for the production run.
- R9.4 The supplier must deliver a cutover plan with a timed sequence, named owners, content freeze window, DNS TTL strategy, go/no-go checklist and a pre-agreed rollback trigger requiring no further approval to execute.
- R9.5 A [30]-day hypercare period must be included, with daily monitoring of errors, 404s, redirect coverage and Core Web Vitals, weekly written reports, and a [4]-hour response target for regression defects.
- R9.6 Post-launch verification must include a crawl comparison against the pre-launch baseline and a Core Web Vitals report at day 7 and day 30.

---

## 10. Support, maintenance and service levels

| Severity | Definition | Response | Resolution |
|----------|------------|----------|------------|
| 1 | Production unavailable or data loss | [30 min, 24/7] | [4 hours] |
| 2 | Major function impaired, no workaround | [2 business hours] | [1 business day] |
| 3 | Minor function impaired, workaround exists | [1 business day] | [5 business days] |
| 4 | Question or cosmetic issue | [3 business days] | [next release] |

- R10.1 Support must be available by [channels] during [hours], with named escalation contacts.
- R10.2 Included maintenance hours: [number] per month, with unused hours [carrying over / not carrying over].
- R10.3 A monthly service report must cover availability, incidents, patching, backup verification and support volumes.
- R10.4 Change requests must be priced against the rate card in section 12 and approved in writing before work starts.

---

## 11. Vendor qualifications and references

- R11.1 The supplier must have delivered at least [3] production Drupal 10 or 11 platforms of comparable scale in the last [3] years.
- R11.2 The supplier must name the architect, lead developer, project manager and accessibility specialist assigned to this engagement, with allocation percentages and confirmation they remain for the contract term.
- R11.3 Three references must be provided for comparable projects, including contact name, role, email and a one-line description of the work. References will be contacted.
- R11.4 The supplier must confirm professional liability and cyber insurance at [amounts], legal standing, and no conflict of interest or debarment.
- R11.5 [Optional] Drupal Certified Partner status, or documented contribution to Drupal core or contributed projects, may be stated and will be scored under section 13.

---

## 12. Pricing and three-year total cost of ownership

Complete the table in this format. Proposals that do not complete it will not be scored on price.

| Cost area | Year 1 | Year 2 | Year 3 | Total |
|-----------|--------|--------|--------|-------|
| Discovery and strategy | | | | |
| Design | | | | |
| Build and configuration | | | | |
| Content migration | | | | |
| Integrations | | | | |
| Accessibility testing and remediation | | | | |
| Hosting and infrastructure (pass-through) | | | | |
| Hosting management fee | | | | |
| Support and maintenance | | | | |
| Training and documentation | | | | |
| Contingency (stated %) | | | | |
| **Total** | | | | |

**Rate card.** Provide hourly rates for: architect, senior developer, developer, project manager, designer, accessibility specialist, content strategist, and support engineer.

**Payment terms.** [Proposed milestone schedule]. **Validity.** Prices valid for [90] days.

**Options.** Price separately: [additional site], [multilingual expansion], [commerce], [additional support tier].

---

## 13. Evaluation criteria and process

| Criterion | Weight | What earns a high score |
|-----------|--------|-------------------------|
| Technical approach and architecture | 18% | Content model, configuration strategy and deployment approach specific to this scope |
| Hosting, infrastructure and operations | 15% | Every hosting clause answered with evidence attached |
| Three-year total cost of ownership | 15% | Complete cost table, transparent infrastructure charges, credible rate card |
| Comparable experience and references | 13% | Three genuinely comparable builds with contactable references |
| Team, roles and named expertise | 12% | Named individuals with allocation percentages |
| Security, privacy and compliance | 10% | Reports and certificates with scope statements |
| Delivery plan, migration and support model | 9% | Two rehearsals, cutover plan, severity-based SLAs |
| Accessibility and quality assurance | 8% | Named standard, test method and prior conformance report |

**Scoring definition.** 5 = fully evidenced with a named approach, people and proof; 4 = evidenced with minor gaps; 3 = plausible but unsupported; 2 = partially addressed; 1 = asserted only; 0 = not addressed.

**Pass/fail gates.** Proposals are not scored unless they evidence: legal standing and insurance; three comparable Drupal builds; a named architect; security assurance available for review; ability to meet the required hosting model; accessibility testing capability.

**Demonstration.** Shortlisted suppliers will demonstrate live, in their own environment: publishing a page through an approval workflow, deploying and rolling back a configuration change, and proving the requirement the panel finds hardest to believe. The demonstration is scored within "Technical approach".

**Process.** Independent written scoring, panel moderation of criteria differing by more than two points, references contacted before award, and written notification to all bidders with their own scores.

---

## 14. Submission instructions and timeline

| Date | Milestone |
|------|-----------|
| [date] | RFP issued |
| [date] | Questions close |
| [date] | All questions and answers published to all bidders |
| [date, time, time zone] | Responses due via [channel] |
| [date] | Shortlist notified; demonstrations scheduled |
| [date] | Demonstrations |
| [date] | References contacted |
| [date] | Award notification |
| [date] | Contract start |

**Format.** One PDF, maximum [30] pages excluding the cost table and CVs, named `[Organization]-RFP-[Supplier]-response.pdf`. A separate editable cost table in [XLSX] is required.

**Late submissions** will not be accepted. **Clarifications** must be submitted in writing to [email]; no verbal clarifications will be given.

---

## 15. Terms, assumptions and appendices

- R15.1 Contract type: [fixed price per work package / time and materials with cap]. Payment on milestone acceptance, [30]-day terms.
- R15.2 Intellectual property in custom code and configuration vests in [Organization]. Contributions to Drupal core or contributed projects are licensed under their existing licences.
- R15.3 The supplier must sign the [Organization] data processing agreement and confidentiality agreement.
- R15.4 On termination, complete exports of code, configuration, content, media and databases must be delivered in standard formats within [30] days at no charge, with [20] hours of transition assistance.
- R15.5 [Organization] reserves the right to reject any or all proposals, to negotiate with the highest-scoring bidder, and to cancel the procurement without liability.
- R15.6 No fee, penalty or notice period beyond [90] days applies to data export or termination of hosting.

**Appendices to attach:** A. Content inventory; B. URL inventory and traffic data; C. Brand guidelines; D. Current architecture diagram; E. Security questionnaire; F. Data processing agreement; G. Accessibility obligations from [funding agreement / policy].

---

*Template maintained by the Drupal RFP Kit (devpanel.com). Adapted freely for your procurement; not legal advice.*