Evaluation checklist template for a public-sector CMS
This page is for the members of an evaluation panel and the procurement officer who prepares their work. It gives a
checklist you can copy into your own evaluation file, and for each line the place where the evidence for Exponential
can be found. The evidence sources are the standards pages in doc/eng-us/standards/ and the feature documentation of the
repository; nothing on this page replaces your own tests.
Template - adapt to your procurement rules; not legal advice.
Contents
- How to use the checklist
- Header of the evaluation file
- Functional checks
- Accessibility checks
- Security and privacy checks
- Languages and content checks
- Operations, support and exit checks
- Recording the result
How to use the checklist
- Copy the lines below into your evaluation file and delete those your tender did not ask for.
- Keep the wording of each line identical to the requirement in your tender, so a reviewer can trace it.
- For every line, record three things: the answer the bidder gave, the evidence you checked, and your finding (met, partly met, not met, not evidenced).
- Treat "Unverified" in a vendor's own documentation as "not evidenced" unless the bid adds evidence. The Exponential standards pages use exactly these status words: "Complies", "Partly complies", "Unverified" and "Does not comply" (Accessibility standards).
- Score afterwards, with the scoring sheet template (a separate page of this folder).
Header of the evaluation file
Tender: <reference and title>
Bid: <bidder name> / product: Exponential <version>
Evaluator: <name, role>
Date(s): <dates of review, demo and proof of concept>
Conflict of interest declared: <yes/no, date>
Sources checked: repository at tag/commit <...>; demo on <date>; proof of concept on <date>Functional checks
| # | Check | Where the evidence for Exponential is |
|---|---|---|
| F1 | Structured content types defined by administrators | Content model and editing |
| F2 | Drafts, versions, compare and restore | Versions of an object, Drafts and pending |
| F3 | Approval before publishing | Workflows |
| F4 | Roles and permissions per section and content type | Roles and policies, Sections |
| F5 | Several sites from one installation | Multisite setup |
| F6 | Forms that collect submissions | Collected information |
| F7 | Site search | Site search, Search with ezfind and Solr |
| F8 | RSS feeds and PDF export | RSS feeds, PDF exports |
| F9 | Content API for other systems | REST API v1 and v2 |
Accessibility checks
| # | Check | Evidence |
|---|---|---|
| A1 | Status against WCAG 2.2 AA stated per component | Accessibility standards: admin4/admin4l "Partly complies"; public designs not audited |
| A2 | EN 301 549 and Section 508 position | same page: both "Unverified"; no VPAT or Accessibility Conformance Report exists |
| A3 | Who makes the public site accessible | the bidder's own design and testing plan; see Testing accessibility |
| A4 | Accessibility statement for the site | the bidder must write it; no template ships (Accessibility standards) |
Security and privacy checks
| # | Check | Evidence |
|---|---|---|
| S1 | OWASP Top 10 mapping | Security standards: "Partly complies"; ASVS "Unverified" |
| S2 | Two-step sign-in | Two-step sign-in (extension, opt-in) |
| S3 | Audit trail of who did what | Audit trail, on by default |
| S4 | Vulnerability disclosure and supported versions | SECURITY.md in the repository root, summarized in Security standards |
| S5 | Hardening plan for production | Security hardening, chapter 13 |
| P1 | Consent records, erasure, log minimization | Privacy standards |
| P2 | Cookie consent | none shipped: the bidder must add one if the site uses analytics or embeds (Privacy standards) |
Languages and content checks
| # | Check | Evidence |
|---|---|---|
| L1 | Content in several languages with fallback | Content languages |
| L2 | Right-to-left languages | Right-to-left languages |
| L3 | Administration in the staff's language | Languages |
Operations, support and exit checks
| # | Check | Evidence |
|---|---|---|
| O1 | Supported PHP versions and databases | Requirements |
| O2 | Backups of database and files | Backups: what to back up |
| O3 | Upgrade path and check | Upgrading, Upgrade check |
| O4 | Release policy | Source control and releases |
| O5 | Support offer with named response times | the bid itself; compare with Support levels and response times |
| X1 | Complete data export at exit | Migrating away from Exponential |
| X2 | License with no fee and source available | Licensing questions |
Recording the result
Line | Bid answer (quote) | Evidence checked (link, test, demo minute) | Finding | Evaluator initials
F1 | ... | ... | met | ...Keep the evidence links in the file. A finding without a source is not defensible when a bidder asks for a debrief.
Related pages
- Evaluation: overview
- Procurement: overview
- Accessibility standards
- Security standards
- Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.
Become an Exponential Partner
Partners share their information, provide funding, contribute back and develop the products with us, and that is how Exponential grows. A partner website and dashboard are planned for mid-2027: please become a partner today to speed up our growth rate and land new features faster.