Business and workflow
Required states, roles, handoffs, exceptions, configuration boundaries, audit history, reporting, and administrative control.
Free CSV template
36 evidence-first requirements
Public-sector software RFP requirements checklist.
Define what vendors must actually prove before proposal language, feature lists, and polished demonstrations start shaping the decision. The checklist covers nine procurement areas and pairs every starter requirement with an evidence request and a suggested decision owner.
No email gate. Adapt the language with your procurement, legal, security, accessibility, records, and program owners before use.
- Separate gates from scoresNot every requirement should be traded against price or features.
- Request proofAttach an evidence expectation to consequential claims.
- Name an ownerAssign the stakeholder qualified to judge each response.
- Preserve traceabilityConnect solicitation language to testing and acceptance.
Before the solicitation
Turn the operating problem into testable requirements.
The CSV is deliberately a starter, not boilerplate. Remove what does not apply, add jurisdiction- and workflow-specific obligations, and decide how each requirement will be evaluated before proposals arrive.
- 01
Map the real workflow.
Document users, roles, states, exceptions, information types, integrations, reporting needs, current pain points, and the outcome the procurement is supposed to change.
- 02
Classify each requirement.
Mark true pass-fail obligations separately from scored preferences and information requests. A mandatory requirement should be mandatory because the organization can defend why it cannot be traded away.
- 03
Define acceptable evidence.
Specify when a written response is enough and when the team needs a demonstration, architecture artifact, accessibility report, security evidence, migration plan, reference, test result, or contract commitment.
- 04
Assign decision owners.
Route requirements to the people qualified to evaluate them: program, security, privacy, records, accessibility, architecture, implementation, operations, procurement, finance, or legal.
- 05
Freeze the model before scoring.
Resolve ambiguity before vendor review. Then use the same requirements, evidence requests, scenarios, and scoring model across competing options.
36 starter requirements
Nine areas that should be explicit before vendor comparison.
Each category contains four starter requirements in the downloadable CSV. The examples below show what the category is intended to force into the open.
Security and access
Identity, MFA/SSO, authorization, encryption, secure development, vulnerability handling, logging, and incident readiness.
Privacy and records
Data minimization, purpose boundaries, retention, disposition, legal holds where applicable, record access, and deletion evidence.
Data and migration
Inventory, mapping, relationships, metadata, counts, reconciliation, exceptions, rollback, validation, ownership, and portability.
Integration
API behavior, authentication, versioning, rate limits, retries, duplicate handling, monitoring, standards claims, and source-of-truth ownership.
Accessibility and public experience
Applicable accessibility requirements, conformance evidence, assistive-technology testing, authoring outputs, and public-service acceptance criteria.
Implementation and acceptance
Dependencies, staffing, environments, configuration control, testing, defect treatment, training, knowledge transfer, and acceptance authority.
Reliability and support
Service measurement, maintenance, backup and restore, recovery objectives, support response, escalation, operational telemetry, and change notification.
Commercial and exit
Total cost, renewal mechanics, third-party dependencies, data location, subcontractors, termination assistance, export, deletion, and transition obligations.
Evidence ladder
Make important claims progressively harder to fake.
A procurement team does not need the same evidence for every item. It does need a deliberate rule for when assurance should move beyond a questionnaire answer.
- 1
- Written response. Useful for initial screening and explaining the vendor's proposed approach.
- 2
- Specific artifact. Architecture, policy, report, sample export, API documentation, accessibility conformance report, plan, or other reviewable evidence.
- 3
- Demonstration or test. A representative workflow, exception, integration, accessibility scenario, recovery exercise, migration sample, or administrative task.
- 4
- Independent or customer evidence. Appropriate assessment results, references, third-party testing, or comparable production experience.
- 5
- Enforceable commitment. Material promises carried into statements of work, acceptance criteria, service levels, data rights, or contract terms through qualified review.
Accessibility procurement
Treat accessibility as a requirement and acceptance concern—not a late questionnaire.
For U.S. federal ICT procurement, Section 508 guidance says applicable accessibility requirements should be identified up front, requested from vendors, evaluated, and validated after award. State, local, education, healthcare, and other organizations may have different or additional obligations.
- Determine what applies. Use the federal Accessibility Requirements Tool when it fits the procurement context, or the responsible organization's applicable accessibility process.
- Request vendor evidence. Federal guidance recommends requesting accessibility information from vendors and contractors rather than relying on a generic accessibility statement.
- Define acceptance. Include the accessibility scenarios, outputs, assistive technologies, defects, remediation expectations, and responsible approver that will determine acceptance.
- Keep it product-specific. Authoring tools, public portals, document outputs, administrative interfaces, and customized ICT can create different accessibility questions.
Reference anchors: Section508.gov procurement guidance, NIST Cybersecurity Framework, NIST Secure Software Development Framework, and CISA Secure by Design. These are reference points, not universal procurement mandates.
Complete the decision chain
Requirements first. Evidence second. Selection third.
Use the RFP checklist to define what matters, the evaluation scorecard to compare vendor evidence, and the evaluation brief to capture the operating context behind the procurement. If the problem aligns with Zeph Tech or ZephCMS, a fit review comes after the decision is clear enough to discuss productively.