Write requirements as testable statements, group them into must, should, and could, and tie each to a standard or a real workflow you have today. A one or two page document that a vendor can answer with evidence beats a hundred line spreadsheet that invites yes to everything.
Start from outcomes
Before listing features, write four outcomes in plain words. For example: we can list every component in every release within an hour; critical findings reach a named owner within a day; blocked builds are rare and understood; we can show an auditor dated evidence. Every requirement should trace to one of these. If it does not, cut it.
Make each requirement testable
A requirement you cannot test is a wish. Compare.
| Weak | Testable |
|---|---|
| Supports SBOMs | Exports CycloneDX and SPDX for our three sample releases, and the files validate |
| Good reachability | Shows, for ten sample findings, whether the vulnerable function is called, with the call path |
| Integrates with CI | Posts a result on a pull request in our CI system within a time we set |
| Has an audit trail | Exports a dated log of policy changes and exceptions |
Reference standards by name and version. CycloneDX 1.7 is the current version on the CycloneDX site and is published as ECMA-424. SPDX is recognized as ISO/IEC 5962:2021. NTIA lists minimum data fields for an SBOM, so require them.
A requirements skeleton
Must
- Inventory for our listed ecosystems and container images
- Standard format SBOM export and import
- Policy rules applied in pull requests
- Named owner assignment and ticket creation
- Role based access and exportable audit logs
- Data handling terms stated in writing, including where data is stored and how it is deleted
Should
- Reachability analysis for our main languages
- Use of exploitation data, such as the CISA catalog, in ranking
- Time limited exceptions with approvals
- Fix proposals through pull requests that humans review
Could
- Support for supplier SBOM intake
- Evidence export mapped to the frameworks we report against
Add constraints, not just features
State your limits: deployment model, regions for data, size of your estate, number of engineers who will use it, and the team that will run it. A tool that fits only if you hire two people is a hidden cost.
Add evidence rules
Ask each vendor to answer with a demo on your sample repositories, a link to documentation, or a written statement. Mark unsupported claims as unverified. Require vendors to label capabilities as generally available, early access, or roadmap, and score only the first.
Review with the people who will live with it
Developers check the pull request experience, platform engineers check operations, and security checks policy. Give each group a veto on their section, and keep the total to what a team can test in a few weeks.
A worked example
Take a hypothetical company starting a platform evaluation. The security lead drafts the outcomes first: list every component in every release within an hour, route critical findings to a named owner within a day, keep blocks rare and understood, and produce dated evidence on request.
From these she derives requirements. For the first outcome: exports CycloneDX and SPDX for three sample releases, and the files validate. For the second: creates a ticket with a named owner from the code owners file, tested on five repositories. For the third: runs rules in advise mode first, with a report of what would have been blocked. For the fourth: exports a dated log of policy changes, scans, and exceptions.
She marks each as must, should, or could. Of twenty six items, eleven are must. She sends the document to four vendors with three sample repositories and a two week window. Each vendor responds by running the samples and sending evidence. Two vendors leave several must items unanswered, which reduces their score immediately.
The final scoring uses only tested items. Claims without evidence earn no points.
Evidence scoring
| Evidence type | Score treatment |
|---|---|
| Demonstrated on our samples | Full credit |
| Shown in documentation | Partial credit |
| Stated in writing only | Minimal credit |
| Roadmap or early access | No credit |
This keeps scoring fair and discourages overstatement.
Mapping requirements to frameworks you report against
If you answer to a framework or customer standard, map each requirement to the control it supports. A single requirement, such as an exportable audit log, may serve several controls. The mapping helps you explain the purchase and later helps you find evidence. Keep the mapping in the same table as the requirements so it stays up to date.
| Requirement | Supports |
|---|---|
| SBOM export in standard formats | Customer SBOM requests |
| Dated policy and exception log | Audit evidence |
| Role based access | Access control reviews |
Non functional requirements often missed
- Availability expectations and what happens during an outage
- Data location, retention, and deletion
- Support hours and response expectations
- Upgrade and change notification process
- Exit plan: export formats and timing
- Accessibility of the interface for your team
Governance of the evaluation
Name an evaluation lead, a decision date, and a rule for ties. Record why you chose what you chose, including the risks you accepted. A one page decision record helps the next person who reviews the contract and the next time you reevaluate.
Try it yourself
Click through it at your own pace, or open it full screen. Open the demo to see how one piece of evidence can map to several controls. Use that view when you tie requirements to frameworks.
You can test your requirements against Safeguard with the free scan at gold.safeguard.sh/scan. Its GA areas include SBOM and dependency scanning, reachability analysis, policies and gates, asset discovery, and compliance and evidence automation.
Quick check
How long should a requirements document be?
One to two pages of must, should, and could items is usually enough to run a fair evaluation.
Should I send it to every vendor?
Send it to a short list, and ask for evidence on your own samples rather than a questionnaire of yes and no answers.
Should price be a requirement?
Handle cost in a separate commercial step, and keep the requirements document focused on capability and evidence.
Sources
Last reviewed: 19 October 2026.
