Deepfake Detection Software RFP Requirements: What to Include

What should be in a deepfake detection RFP?

An RFP for deepfake detection has one job: make every bid answer the same questions with evidence you can check. That starts with a precise description of what you are protecting. Name the workflow (onboarding selfies, claim photos, contact centre calls, newsroom submissions), the media formats and size ranges, peak and average volume, the decision the result feeds, and any deployment constraint such as data that cannot leave the country.

Then ask for answers in a fixed format. A requirement-by-requirement response with a status of delivered, conditional, unsupported or roadmap stops vendors from answering a different question than the one asked. Attach the evidence you expect next to each requirement, so a missing document is visible as a gap rather than hidden in a sales narrative.

Keep the technical score separate from legal and commercial exceptions. A bid can be the strongest technically and still fail a mandatory data residency or contract term, and that failure should be recorded as such.

What to include in a deepfake detection RFP, section by section

The table lists the sections most buyers need, with the evidence that makes each answer testable. Drop rows that do not apply and add workflow-specific ones, but keep the evidence column. ISO/IEC 25059:2023 provides a quality model for AI systems that can help organise the performance and reliability rows, though it does not set thresholds for you.

How to ask for performance evidence that can be compared

Vendors report accuracy in incompatible ways, so specify the format. Ask for the confusion matrix at the threshold the vendor proposes for your workflow, plus MCC and true positive rate at a fixed false positive rate. NIST AI 100-4 (November 2024) notes that accuracy, AUROC and F1 often miss what matters, because false positives on real content can do serious damage.

Require each result to state the dataset name and version, the share of synthetic samples, the label method, any exclusions, and whether the model was tuned on that data. Ask vendors to separate internal tests, customer tests, public benchmarks and certifications. Where a public benchmark is cited, ask for the paper version and whether any vendor staff contributed to it.

Ask for error, abstention and unsupported-input rates too. A product that returns no answer on 8 percent of files will look accurate if those files are dropped from the count.

Which attack layer does the product protect?

Deepfake detection products work at different layers, and RFP answers often blur them. FIDO Biometrics Requirements v4.1 separates attacks presented to a capture device, such as a mask or a screen held to a camera, from data injected to bypass the camera entirely. Content-based detection examines the media itself for signs of generation or editing, whichever path it arrived by.

Ask each bidder to state which of these layers it covers, how a buyer can test each claim, and which results depend on external services such as provenance metadata. A product that covers one layer well is not a gap in itself; a bid that claims all three without evidence is.

Terms to write into the RFP so they reach the contract

Some requirements only have force if they appear early. Put these in the RFP, mark them mandatory where they are, and score bids that refuse them accordingly.

• The right to run your own test on held-out media before award and after material model changes.
• Advance notice and regression evidence for model, API or threshold changes, with a way to identify the version behind any past result.
• Limits on use of your media, including whether it may be used to train models, and verified deletion on request and at exit.
• Export of configurations, audit records and case data in usable formats when the contract ends.
• A correction process for inaccurate questionnaire answers discovered after award.

How to score deepfake detection RFP responses

Score in two passes. The first pass is pass or fail on mandatory items: deployment constraints, data-use limits, required certifications and the right to test. A bid that fails any of them leaves the process, however strong its detection claims, and the reason goes in the record.

The second pass weights the remaining requirements by consequence. Detection evidence and attack coverage usually carry the most weight for fraud workflows, while operations and support matter more for high-volume platforms. Give zero credit for unanswered questions and score roadmap items in a separate column. Share any clarification with every bidder when it changes how a requirement should be read, and send the top two to four bids into a controlled test on your own media before award.

How Neural Defend answers a deepfake detection RFP

We answer in the format above, with evidence attached. NeuroVerify checks a face image, video or audio in one API call and returns six signals with a unified risk score and signal-level evidence. It does not analyse ID documents, and we say so in the capability statement. Eligible image requests complete in under 200 ms at p95 under defined test conditions, with the methodology available on request.

For detection performance, we cite the public VendorBench-100 benchmark (v2, July 2026), where Neural Defend ranked first of 36 systems with an MCC of 0.876 against 0.646 for the next-best vendor. One VendorBench author also co-authored our ARCAS 1B paper, and the benchmark covers still images only, so we expect buyers to rerun it and to test on their own media.

Security evidence includes ISO/IEC 27001, ISO/IEC 27701, ISO/IEC 42001 and SOC 2 Type II. Deployment options are managed cloud API, private cloud or VPC, secure container, on-premises and air-gapped, scoped during evaluation.