A digital asset vendor can answer a long security questionnaire and still leave the buyer unable to decide whether its payment, trading or reporting workflow will work. The missing detail is often scope. An assurance document may cover another entity, a different product or a configuration the institution will not use. Procurement needs evidence connected to the actual service being purchased.
The useful RFP therefore starts with operating requirements and asks suppliers to demonstrate how they meet them. It records what the buyer checked, what remains uncertain and which conditions must be met before use. This article proposes an evidence-led procurement process for digital asset services. The examples are evaluation methods, not claims about individual vendors.
Describe the workflow before the questionnaire
Write the proposed service as a sequence of business actions. A payment service may accept instructions, validate destinations, collect approvals, submit transactions and supply status evidence. A data service may ingest observations, normalize them and provide historical exports. The buyer should identify which actions it expects the vendor to perform and which remain inside the institution.
For each action, state an acceptable outcome and a failure condition. For example, a rejected instruction should return a reason the operating team can act on. A provider timeout should not leave staff unable to identify the original submission. A historical export should retain the identifiers needed to join it to the institution's records.
NIST's supply chain risk management guidance, updated in November 2024, addresses visibility into how acquired technology is developed, integrated and deployed. The procurement implication is to review the delivered service and its dependencies, rather than treating the supplier's corporate description as the product evidence.
Make the intended configuration explicit in the RFP. Identify networks, assets, jurisdictions of operation, user roles, anticipated volumes and relevant integrations without placing confidential live instructions in a sales questionnaire. A vendor cannot give a meaningful answer about capacity or control coverage when it has to guess the workload.
Define the evidence for each claim
Pair each important question with the artifact needed to answer it. If a supplier says it supports separation of duties, request a role configuration and a demonstration of the prohibited action. If it says exports are complete, request a sample, a schema and the method used to check completeness. If it says it can handle a service disruption, request the relevant test scope and results.
Keep a register with the requirement, the vendor's claim, the supplied evidence, the reviewer, the review date and the remaining gap. The register should distinguish a documented capability from a tested outcome. Both can be valuable, but an untested capability should not inherit the confidence assigned to a successful demonstration.
Use evidence freshness appropriate to the control. A configuration export taken during evaluation can show the proposed settings. An older test may still provide useful methodology, while failing to demonstrate the current architecture. Ask what changed after the test and whether those changes affect the requirement under review.
Our discussion of smart contract audits covers a related scope problem: a report speaks to the code and assumptions it examined. In procurement, identify the product version, relevant components, exclusions and customer responsibilities before treating an audit or assurance report as evidence for a particular operating claim.
Check entity, service and configuration scope
Map the contracting entity to the entities delivering the service. Record which one provides support, holds data, operates critical components and supplies any account relationship. A group-level presentation may describe several businesses, while the contract buys a narrow service from one entity. The evidence should follow that arrangement.
Review the scope and period of assurance material. Identify which system it covers, what was excluded and what controls depend on the customer. For restricted reports, arrange controlled access for the institution's reviewers. A logo in a sales deck does not give them the information needed to assess coverage or exceptions.
Ask the vendor to show the settings that apply to the proposed customer environment. A service may support multiple authorization models, data regions or execution routes. The buyer needs evidence for the selected model, including who can alter it and how changes are recorded. A feature being available is different from it being enabled with the required restrictions.
Run demonstrations against realistic exceptions
A planned demonstration should test a small number of material scenarios, using synthetic data and safe environments. Ask the vendor to show an ordinary instruction and an exception: a changed destination, a duplicated request, a restricted action or an unavailable dependency. Observe the evidence produced for the institution, not only the vendor's internal screen.
Evaluate what an operator can learn without vendor intervention. Can staff identify the affected request? Can they determine whether a retry is safe? Can they retrieve the version of the policy that approved the action? If support must answer every question, record that dependency and its implications for the institution's operating hours.
Test integration boundaries. A vendor's service might work as demonstrated while the institution's identity provider, approval workflow or reconciliation process prevents completion. Include the proposed interfaces in acceptance testing and define which team resolves a boundary failure. The RFP should make that ownership visible before the contract is final.
Request dependency evidence at the right depth
Suppliers should identify dependencies relevant to the bought service and explain their operational role. For a network access provider, those may include hosting, upstream endpoints and software services. For a payment platform, they may also include account, conversion and compliance services. The buyer needs enough detail to assess interruption and concentration risks.
NIST's CSF supply chain quick-start guide recommends supplier criticality assessments based on business importance, sensitive data and access. That provides a useful way to scale the request. A vendor with power over transaction execution warrants different evidence from a supplier delivering a noncritical reference feed.
Ask how relevant dependency changes are communicated and reviewed. A new subprovider or new execution route can alter the buyer's assumptions even if the user interface is unchanged. Record which changes require notice and which trigger additional testing. Tie those requirements to the service's criticality, rather than sending every supplier the same exhaustive list.
Our article on RPC and node infrastructure dependencies explains why nominally separate routes can share underlying failure points. An RFP should ask a vendor to identify the basis of any independence claim. Two endpoints with different labels are not sufficient evidence that they will behave independently during disruption.
Inspect the evidence the institution will retain
Ask for a customer-facing evidence sample before signing. The institution may need approval logs, policy changes, request status histories or data corrections. Check whether the sample contains actor identifiers, timestamps, object references and schema information. A polished activity feed can be readable while lacking the fields needed for an investigation or migration.
AWS's CloudTrail documentation gives a concrete example of signed digests used for log integrity checks. An RFP need not demand that exact implementation. It should ask how the supplier supports the evidence claim it makes and whether the customer can perform the relevant verification.
Review access after contract termination and during a service suspension. The evidence requirement continues when the vendor portal becomes unavailable. Confirm export formats, delivery procedures and any dependence on an active paid account. Run a sample reconstruction with the exported artifacts so reviewers can establish whether the information is usable outside the supplier's interface.
Score gaps against business decisions
Keep evidence quality separate from feature preference. A vendor may offer an attractive interface while leaving an essential control unproven. Record a result for each requirement: met with evidence, conditional on a defined action, not met or not yet established. An average score should not hide an unresolved condition that prevents the service from being used.
Assign an owner and deadline to every condition. A promise to add a feature later is different from an existing tested control. The institution can choose a staged implementation where appropriate, but the approved scope should reflect the capability available at that stage. Do not treat a roadmap as completed delivery.
Include the operating team in the decision. Procurement, security and legal reviews provide necessary perspectives, while the staff who will handle rejected instructions and missing exports can identify practical gaps. Their review should produce evidence and acceptance criteria, rather than a general endorsement after a sales demonstration.
Make acceptance a separate gate
Carry the evidence register into implementation. Recheck the final customer configuration and the agreed exception scenarios before production use. Confirm that support, escalation and export procedures exist for the bought service. Record which pre-contract assumptions changed during setup and who accepted the resulting conditions.
Schedule later reviews around material service changes and the expiry of evidence, not only the contract renewal date. Procurement should leave the institution with a maintained record of why the service was accepted and what must remain true for that decision to hold. That is more useful than a completed questionnaire whose answers no one can connect to the live workflow.