Skip to content

Templates

DOCX · Markdown · XLSX

The Drupal RFP template, in five files

A fifteen-section request for proposals, a hosting and security annex with 39 clauses, and a scoring workbook with live formulas. Editable, unbranded, and free of the vendor names that make a template unusable in a competitive process.

Sections
15
Hosting clauses
39
Scorecard criteria
8
Placeholders
Your call

Download the files

No email required for direct links

Drupal RFP template

DOCX

The full fifteen-section request for proposals, formatted for Word. Replace the bracketed placeholders, delete the italic instructions, and it is ready to issue.

  • Fifteen numbered sections with starter clause language
  • Content model and editorial workflow tables
  • Cost table vendors must complete for three-year TCO
  • Weighted evaluation criteria and pass/fail gates

Drupal RFP template

Markdown

The same template as plain Markdown, for teams that draft in a repository, Notion, or an AI assistant rather than in Word.

  • Identical content to the DOCX version
  • Diff-friendly, so a legal or procurement reviewer can track changes
  • Pastes cleanly into the AI prompt chains on this site

Hosting, security and migration annex

DOCX

Thirty-nine copy-ready clauses covering ownership, environments, performance, recovery, security, observability, migration and exit, each with the evidence to demand.

  • Ownership and exit clauses that prevent accidental lock-in
  • Backup, recovery and patching requirements with evidence standards
  • Migration phase plan from inventory to hypercare
  • Vendor response table (complies / partial / does not)

Hosting, security and migration annex

Markdown

The annex as Markdown, for editing alongside the main template or feeding into an AI review of vendor responses.

  • All thirty-nine clauses in plain text
  • Clause IDs (R7.1, R8.3, R15.2) that vendors can cite back
  • Migration phase requirements as separate sections

Vendor scoring workbook

XLSX

A spreadsheet with live formulas: eight weighted criteria, three vendor columns, calculated totals and verdict bands, plus gate checks and the demonstration script.

  • Weighted scorecard with automatic points and totals
  • Pass/fail gate sheet with dropdown evidence tracking
  • Live demonstration script scored inside technical approach
  • Red-flag checklist for clarification questions

The Markdown versions are generated from the same clause library the hosting page renders, so the documents and the site cannot drift apart. Every file is plain text or standard Office format: no macros, no trackers, no vendor branding to remove.

Section by section

What each of the fifteen sections is for

Open a section to see what belongs in it, what a good version looks like, and the failure mode to avoid. The template follows this order exactly.

01Summary and backgroundGive a vendor enough context to decide whether they can win, and enough history to understand why this project exists now.

What belongs in it

  • Who the organization is, in two sentences a stranger could repeat
  • Why now: the trigger (end-of-life platform, failed vendor, new mandate, funding deadline)
  • What exists today: platform, version, number of sites, pages, editors, integrations
  • The decision this RFP produces and who makes it
02Objectives and success measuresConvert ambition into measures, so the evaluation can reward outcomes instead of adjectives.

What belongs in it

  • Three to five objectives, each with a measurable indicator
  • Baseline values where they exist (current LCP, bounce rate, editor hours per page)
  • What success looks like 90 days and 12 months after launch
  • What is explicitly not a goal, to prevent scope drift
03Scope of workDefine the boundary of the contract in both directions, with deliverables a project manager can put on a plan.

What belongs in it

  • In-scope work packages, each with a named deliverable
  • Out-of-scope items stated explicitly
  • Buyer responsibilities: content, approvals, environments, access, subject-matter experts
  • Assumptions the price depends on
04Functional and content requirementsDescribe the content model and the editorial behaviour the platform must support, in language a Drupal architect can map to entities, fields and workflows.

What belongs in it

  • Content types, their fields and relationships
  • Editorial roles, workflow states and approval rules
  • Taxonomy, search and listing behaviour
  • Content volume: nodes, media, languages, migration source
  • Multisite or domain requirements if any
05Design, accessibility and user experienceFix the standard of quality and the compliance obligation before anyone argues about taste.

What belongs in it

  • Accessibility conformance target (WCAG 2.2 AA) and how it will be verified
  • Design system expectations: tokens, components, documentation
  • Brand assets and who owns them
  • Browser and device support matrix
  • Usability testing expectations and participant recruitment
06Integrations, data and identityName every system the site must talk to, and who owns the integration risk.

What belongs in it

  • Each integration: system, direction, protocol, owner, authentication
  • Single sign-on requirement and identity provider
  • Data residency and synchronization expectations
  • API rate limits or third-party constraints
  • Fallback behaviour when an integration is unavailable
07Hosting, infrastructure and operationsDecide who owns the infrastructure, what it must do, and what happens at the end of the contract.

What belongs in it

  • Hosting model and ownership of the cloud account
  • Environments, deployment pipeline and environment cloning
  • Caching layers, performance budgets and monitoring
  • Backup, recovery point and recovery time objectives
  • Patching SLAs for Drupal core and contributed modules
  • Exit, portability and data-export terms
08Security, privacy and complianceTranslate obligations into documents and behaviours a vendor must demonstrate, not adjectives they must claim.

What belongs in it

  • Frameworks and attestations required, with scope of coverage
  • Vulnerability disclosure and incident notification windows
  • Encryption, key management and data residency
  • Access control, MFA and audit logging expectations
  • Penetration testing cadence and remediation commitments
09Migration, launch and cutoverMake the riskiest two weeks of the project a priced, planned, testable sequence.

What belongs in it

  • Content inventory and redirect mapping obligations
  • Dry-run expectations and acceptance test list
  • Freeze window, DNS strategy and rollback trigger
  • Smoke tests and go/no-go criteria
  • Post-launch hypercare period and what happens in it
10Support, maintenance and service levelsBuy the years after launch as deliberately as the launch itself.

What belongs in it

  • Support hours, channels and severity definitions
  • Response and resolution targets per severity
  • Included maintenance work versus chargeable change
  • Security patching cadence and who applies it
  • Reporting, review cadence and exit assistance
11Vendor qualifications and referencesSeparate vendors who can do this from vendors who would like to.

What belongs in it

  • Certifications or partnership status required, and whether they are gates
  • Named team members and their role on this project
  • Three comparable references with contact details
  • Insurance, legal standing and conflict-of-interest declarations
  • Contribution record or community evidence, if it matters to you
12Pricing and three-year total cost of ownershipMake proposals comparable, and reveal the cost that continues after the invoice for the build is paid.

What belongs in it

  • Fixed-format cost table across build, migration, hosting, support and contingency
  • Three-year total cost of ownership, not year one only
  • Rate card for change requests by role
  • Assumptions, exclusions and validity period
  • Options priced separately rather than folded into the base
13Evaluation criteria and processPublish how the decision will be made, so proposals are written to be scored rather than to impress.

What belongs in it

  • Weighted criteria totalling 100 per cent
  • Scoring definition for each point on the scale
  • Pass/fail gates that apply before scoring
  • Who evaluates, and how disagreements are resolved
  • Demonstration format and whether it is scored
14Submission instructions and timelineRemove ambiguity from the mechanics so late or malformed responses are the vendor's fault, not yours.

What belongs in it

  • Format, file naming, size limits and submission channel
  • Question deadline and how answers are published to all bidders
  • Response deadline with time zone
  • Presentation dates and expected attendees
  • Award date and intended contract start
15Terms, assumptions and appendicesPut the contractual frame and the supporting documents where vendors can find them.

What belongs in it

  • Contract type, payment terms and invoicing rules
  • IP ownership and licence expectations for contributed code
  • Confidentiality, data processing and insurance requirements
  • Right to reject, negotiate or cancel
  • Appendices: content inventory, brand guidelines, security questionnaire, current architecture

Keep it together

Want the files in one place?

Leave a work email and we will send the three primary documents as a single pack, plus the scoring workbook. No drip sequence, no sales call unless you ask for one.

TemplateHosting annexScoring workbook

Free · no account

Send me the template pack

Three documents and a workbook, delivered by email with direct download links.

We use this to send the toolkit and occasional Drupal procurement notes. Unsubscribe any time. No resale, ever.