Outcome-Based Tender Specifications: Describe the Need, Not the Brand

What “outcome-based” actually means

Procurement practice usually distinguishes three broad types of specification. A functional, outcome-based specification defines the function, duty or role of the goods or services and the result they must achieve, without prescribing how the supplier gets there. A performance specification defines what a product must be capable of doing in measurable terms, again leaving design open. A technical, descriptive or design specification fixes physical characteristics such as size, capacity, materials or construction.

For security products and services the distinction is practical, not academic. “A next-generation firewall from vendor X” prescribes a solution; “a control that blocks traffic matching a defined threat policy, logs the decision and alerts the duty team within a set time” describes a function and a measurable outcome. Guidance from jurisdictions such as Western Australia and Colorado State advises buyers to use functional and performance-based specifications wherever possible, because they leave the supplier to choose how to deliver the customer's requirement.

• Functional — what must be achieved and how it is verified
• Performance — measurable capabilities the product must have
• Technical/design — physical characteristics, drawings, materials
• Combination — function plus specific integration or design constraints

Brand references are the exception, not the rule

EU public procurement rules (Directive 2014/24/EU, Article 42) allow technical specifications to be set in terms of performance and functional requirements, or by reference to recognised technical standards. Naming a specific make, model or trademark restricts competition and is permitted only when the subject matter cannot otherwise be described sufficiently clearly and understandably — and even then the reference must be accompanied by “or equivalent.” The UK Procurement Act 2023 mirrors this position, requiring functional or performance wording wherever possible and prohibiting discriminatory specifications, including indirect ones that only one supplier's product can meet.

A spec that effectively leaves a single supplier as the only possible bidder can be challenged in review proceedings, and a missing “or equivalent” makes a reference competition-restricting. Brand naming is therefore something to avoid as a default: it narrows the field and exposes the buyer to challenge risk, whereas an outcome description widens competition and invites alternatives that still meet the measured need.

• Functional/performance wording is the preferred legal baseline
• Brand or standard references must carry “or equivalent”
• Specifications must not favour or exclude a supplier, directly or indirectly
• Discriminatory, over-narrow specs can be challenged

The recipe: function + condition + measurable indicator

To turn a need into a verifiable requirement, break it into functions and state for each one what must happen, under what conditions and to what measured standard. Instead of naming an endpoint product, write: “the solution must detect suspicious activity on managed endpoints, isolate the affected device from the network and create an unalterable event log for forensic review.”

Then attach measurable bounds with minimum or maximum values, or a fixed value where only one outcome is acceptable: “detection and isolation must complete within five minutes of first suspicious activity,” “the event log must be exportable in format X for integration with the existing SIEM.” Choose terminology and performance levels from recognised standards and technical regulations where they exist, and justify any departure from them.

Draft in plain, active language and avoid vague words such as “flexible,” “suitable” and “user-friendly,” as well as absolute promises such as “100% reliable” or “fully compatible,” which cannot be tested. Numbering each requirement makes it easy to reference during evaluation and contract management.

• Each function = action verb + condition + measurable result
• Bound values with “no less than,” “no more than” or a justified fixed value
• Use recognised terminology and standards where they exist
• Remove vague and absolute terms that cannot be tested or verified

Trade-offs: where outcome-based wording falls short

Outcome-based, non-prescriptive specifications encourage innovation and tend to deliver better value where different technical routes can reach the goal. They also shift accountability for performance to the supplier, which is fair only when the buyer can evaluate offers and verify results. For a straightforward commodity, a short functional description with a few indicators is enough; for a complex system, more detail is needed to keep tenders comparable.

Outcome wording is weakest when the solution must fit an existing integrated estate. Here the correct response is a hybrid: add compatibility and interoperability requirements as testable conditions, not as a way to smuggle in a brand. Over-specification reduces competition and raises cost; under-specification creates risk of receiving solutions that miss the real need. Decide the level of prescriptiveness deliberately, in line with the complexity, risk and value of the contract.

• Accountability for the outcome shifts to the supplier
• Hybrid specs suit integration with an existing environment
• Over-specification narrows competition; under-specification adds risk
• Set the level of detail by complexity, risk and contract value

Verification, acceptance and ongoing service levels

A specification becomes the backbone of the contract and of acceptance. Before tendering, decide what evidence proves each requirement: test results, event logs, audit reports, sample inspections — and who certifies that acceptance criteria are met. For services and support, define service-level targets such as response and resolution times, reporting cadence and escalation paths, plus the data that will be collected and how results are fed back to the supplier.

Targets must be realistic and achievable, ideally grounded through preliminary market engagement before final tendering. Good acceptance and service metrics are specific, measurable, achievable, relevant and timed, and the contract should state what happens if they are missed. Because these indicators are monitored over the life of the contract, they should be defined as precisely at the outset as the functional requirements themselves.

• Define acceptance evidence, testing and who certifies success
• Set service-level targets: response, resolution, reporting, escalation
• Specify data, cadence and feedback so KPIs are actually used
• Validate targets with the market before publishing the final tender

Applying the approach to cybersecurity buying

For security technology, describe the protective effect and how it is measured rather than the vendor. Instead of an endpoint product name, state outcomes: detection of malicious activity on endpoints and in the network, isolation of compromised devices, alerting of the duty team within a defined time, and an unalterable event record.

Do not make a specific vendor certificate a hard participation requirement, which acts as a hidden barrier. Prefer recognised standards and control frameworks with an equivalence clause, or functional and quality characteristics that several suppliers can meet. For managed detection and response or monitoring services, define results through response-time commitments, clear lines of responsibility, escalation and reporting — and let the supplier propose the underlying architecture as long as it measurably delivers the stated effect.

• Security tooling through outcomes: detection, containment, alerting, logging
• Standards as references with equivalence, not as barriers
• Services through response times, responsibilities and reporting
• Evaluate on evidence against indicators, not on vendor reputation