Build a MoSCoW-structured RFP that produces comparable evidence across cybersecurity, AI and enterprise IT procurement.
The working definition
An enterprise technology RFP is a decision instrument. Its job is to convert an agreed business outcome into prioritised procurement requirements, consistent provider evidence, a transparent vendor evaluation method and an auditable selection record.
PDF for circulation and citation. DOCX for direct adaptation into an active procurement. Both are ungated.
Failure modes
The failure usually occurs before the document reaches the market. Vague intent, false priorities and inconsistent evidence requests turn evaluation into interpretation.
Terms such as “enterprise-grade”, “seamless” and “best practice” create no testable threshold.
When every preference is mandatory, the RFP cannot separate viability from differentiation.
Each response follows its own structure, making comparison slow and highly subjective.
Compliance boxes reward confidence unless the RFP specifies documents, tests, demonstrations or commitments.
Headline price hides implementation, consumption, support, data and exit costs.
Unstated exclusions and assumptions allow attractive proposals to describe materially different offers.
Priority before scoring
MoSCoW classifies each requirement by its treatment in this procurement. It prevents preference inflation, preserves real differentiation and makes exceptions visible.
For the full requirements method, use CYBORIUM’s MoSCoW Requirements framework.
Essential for viability or acceptable risk.
Pass / failImportant, but a credible workaround or staged delivery may be acceptable.
Weighted scoreAdditional value when supported by evidence, cost and complexity.
DifferentiatorExplicitly excluded from this procurement or phase.
Not scored
Evidence before claims: priority determines evaluation treatment; evidence determines confidence.
The template
Use the following sequence as the issue document and response schedule. Each section controls a different source of procurement risk.
Governance, authority, dates, contact channel, approvals and probity controls.
The problem, measurable outcome, constraints, boundaries, dependencies and non-goals.
Atomic requirements with priority, owner, evidence request and evaluation treatment.
One answer format for compliance, proof, dependency, timing, cost and exception.
Approved weights, behavioural anchors, pass/fail rules and moderation record.
Whole-of-life pricing plus corporate, security, privacy, resilience, delivery and AI questions.
Clarifications, scripted tests, moderation, risk treatment, approvals and the final defensible rationale.
Complete these before detailed requirements. They establish who controls the process and what a valid response must solve.
| Outcome field | Organisation entry |
|---|---|
| Problem to solve | State the current condition and why it matters now. |
| Target outcome | State the measurable change the procurement must enable. |
| Measures of success | List baselines, targets and target dates. |
| Risk if unresolved | State operational, cyber, financial, legal or strategic exposure. |
| Non-goals | Make exclusions explicit before providers price assumptions. |
Give each requirement one owner, one priority and one evidence request. Split compound requirements.
| ID | Requirement | Tier | Evidence required | Treatment |
|---|---|---|---|---|
| SEC-01 | Support phishing-resistant MFA for privileged access. | Must | Configuration evidence and implementation approach | Pass / fail |
| AI-04 | Provide traceable source references for generated answers. | Should | Client-scripted demonstration | Weighted score |
| IT-08 | Automate low-risk fulfilment workflows without custom code. | Could | Live demonstration and references | Differentiator |
| SCP-01 | Autonomous production changes are excluded from this phase. | Won’t | Provider acknowledgement | Not scored |
Marketing collateral may support a response, but it must never replace the controlled schedule.
| Response field | Provider instruction |
|---|---|
| Compliance | Comply / partially comply / does not comply / not applicable. |
| Response | Explain how the offered scope meets the requirement. |
| Evidence | Name the document, demonstration, test, commitment or reference. |
| Dependency | State client actions, third parties, licences, data and assumptions. |
| Timing | State availability at contract start, implementation or roadmap. |
| Commercial impact | Identify included cost, optional cost or pricing dependency. |
| Exception | Describe any qualification, workaround or limitation. |
Evidence rule: score what is evidenced in the offered scope, not a capability available only in another edition, future roadmap or unpriced service tier.
Approve weights and disqualification rules before responses are opened. Keep the scale behavioural.
| Score | Descriptor | Behavioural anchor |
|---|---|---|
| 0 | No response | No usable answer or evidence. |
| 1 | Materially deficient | Fails most of the criterion or introduces unacceptable risk. |
| 2 | Partially meets | Some capability; meaningful gaps or weak evidence remain. |
| 3 | Meets | Satisfies the criterion with adequate evidence and manageable risk. |
| 4 | Exceeds | Relevant additional value with strong evidence. |
| 5 | Exceptional | Materially strengthens the outcome with highly credible evidence. |
Weighted result = (moderated score ÷ 5) × criterion weight
A headline price is not a comparable commercial offer. Require the same cost horizon, units and assumptions.
| Cost category | Year 1 | Year 2 | Year 3 | Assumption / unit |
|---|---|---|---|---|
| Subscription or licence | ||||
| Implementation and migration | ||||
| Integration and configuration | ||||
| Data ingestion, storage or egress | ||||
| Managed service and support | ||||
| Training and change | ||||
| Third-party products | ||||
| Exit, extraction and transition |
Select questions proportionate to the risk. Require an answer, evidence reference, exception and owner for any remediation commitment.
| Domain | Questions that change the decision |
|---|---|
| Corporate and financial | Contracting entity, ownership, financial capacity, litigation, insurance and change of control. |
| Supply chain | Subcontractors, service locations, concentration risk, assurance and notification. |
| Security and privacy | Data locations, access, encryption, logging, secure development, incident response and deletion. |
| Resilience | Recovery objectives, test evidence, service continuity dependencies and exit support. |
| Delivery | Named roles, critical path, client dependencies, acceptance gates and comparable references. |
| AI-specific | Models, training use, provenance, evaluation, human control, monitoring, change and reconstructability. |
Australian context: adapt the question bank to the Privacy Act, the Australian Privacy Principles, sector obligations and your organisation’s risk appetite. APRA-regulated entities should align relevant operational and provider-risk controls to CPS 230 and information-security controls to CPS 234.
Make the procurement process visible before issue and preserve the rationale after selection.
| Stage | Output or gate |
|---|---|
| Requirements approval | Approved scope, MoSCoW register and criteria |
| RFP issue | Controlled release and acknowledgement |
| Clarification window | Shared clarification log |
| Conformance review | Must gaps and exclusions identified |
| Evaluation and demonstrations | Scores, rationales and scripted evidence |
| Moderation | Moderated result and risk log |
| Commercial and contract | Comparable offer and agreed departures |
| Approval and notification | Signed decision record and communications |
Applied examples
The same framework produces different evidence requests because the material failure modes change by category.
Must: 24×7 triage and escalation within the contracted service boundary.
Evidence: redacted incident timeline, SLA wording and staffing model.
Must: client content, prompts and outputs are not used to train a shared model without written approval.
Evidence: contract clause, architecture and configuration evidence.
Must: migrate agreed records with reconciled counts and an auditable exception report.
Evidence: migration method, sample reconciliation and acceptance plan.
CYBORIUM can define the requirement, map the market, run the vendor evaluation, test evidence, benchmark commercials and support negotiation through to a clear, defensible decision.
CYBORIUM does not sell, deliver, operate or invoice technology.
Practical questions
Continue the framework
This resource is free to use and adapt internally. If you republish or quote it, cite CYBORIUM and link to this page. Public-sector entities should adapt the structure to applicable procurement rules, probity requirements, approvals and recordkeeping obligations.
Detailed guidance from the CYBORIUM research library.
The Australian regulatory and framework sources our methodology maps to.