Encryption RFP Template and Checklist (2026): Customer-Controlled Keys for Cloud, SaaS and Databases

This encryption RFP template and data encryption RFP checklist gives you a vendor-neutral set of requirements for protecting data at rest in cloud, SaaS and database platforms with keys that you control. It covers eleven requirement groups (scope, encryption models, key control and sovereignty, platform integrations, availability, cryptography, access policies, audit, regulatory mapping, deployment and exit, vendor and support), a weighted scoring model, 20 vendor questions, red flags, a proof-of-concept plan and contract clauses. Every table can be copied into a spreadsheet.

---

Table of Contents

1. Who this is for and how to use it
2. Before you write the RFP
3. The requirements checklist
4. Weighted scoring model
5. 20 vendor questions to ask in the response
6. Red flags in vendor answers
7. Proof-of-concept plan with pass/fail tests
8. Contract and exit clauses
9. Copy-ready RFP introduction
10. FAQ
11. Conclusion
12. References

---

Who this is for and how to use it

This template is for security architects, CISOs, data protection officers, procurement and cloud platform owners who must buy, or re-tender, an enterprise data encryption solution in which the customer, not the cloud or SaaS provider, controls the keys. It applies whether you call the result BYOK, HYOK, external key management (EKM), double key encryption (DKE), client-side encryption, tokenization or field-level encryption.

How to use it:

1. Copy the introduction at the end into your RFP and adapt the scope.
2. Paste the requirement tables into a spreadsheet. Keep the ID column: it lets you score vendors and trace evidence later.
3. Delete requirements that do not apply (for example, the Salesforce rows if you do not use Salesforce) and re-weight the scoring model.
4. Ask for evidence, not assertions. Each row names the evidence to request.

Priorities are Must (disqualifying if absent), Should (scored, a gap is acceptable with a plan) and Advanced (differentiating capabilities that a serious product may offer but that you should not make mandatory unless your risk model needs them).

This page is a procurement aid, not legal advice. Check regulatory wording with your counsel.

---

Before you write the RFP

Most failed encryption projects fail before the RFP, on scope. Settle these five things first.

1. Inventory and classify the data. List the platforms that hold regulated or confidential data: Microsoft 365 (Exchange, SharePoint, OneDrive, Teams), Salesforce, ServiceNow, AWS storage and databases, Azure, SQL Server, Oracle, Snowflake, Databricks, and AI services such as OpenAI. Attach a classification (public, internal, confidential, regulated) to each and note data volumes and residency constraints.

2. Pick the threat you are buying protection against. Different models answer different questions:

3. Decide which encryption model per workload. A single model rarely fits every platform. See Hold Your Own Key (HYOK) for the trade-offs between server-side, BYOK and HYOK, and what BYOK really means.

4. Name the stakeholders. Security architecture, cloud platform owners, application owners, DPO or legal, operations/SRE (they will run the key service), procurement and internal audit.

5. Fix your decision criteria and weights before you read any response. The scoring model below gives a starting point.

---

The requirements checklist

Each group is a table with four columns: ID, Requirement, Priority and Evidence to request. Requirements are written so that a serious product in this category can satisfy and evidence them.

Group 1. Scope and data classification

Group 2. Encryption models

Group 3. Key control and sovereignty

Group 4. Platform integrations

Keep only the rows you need. "Supported" means documented, tested against current platform versions and supported by the vendor, not "possible with custom work".

Group 5. Performance and availability

External key services put your key manager on the critical path of your cloud data. This group is the one most often under-specified.

Group 6. Cryptography and post-quantum readiness

Group 7. Access policies

Group 8. Audit and monitoring

Group 9. Regulatory mapping

Ask the vendor to map capabilities to the rules that apply to you, in their own words. Do not accept a logo list. The references below are generic anchors, not a compliance claim.

Group 10. Deployment and exit/portability

Group 11. Vendor and support

---

Weighted scoring model

Weights should reflect your risk model. The table below is an example with made-up generic numbers.

0 to 5 scale for each requirement:

Apply a pass/fail gate first: any Must scored 0 or 1 disqualifies, or requires a written remediation before shortlist.

Worked example (illustrative numbers only). Vendor A averages 4.0 on key control, 3.5 on integrations, 3.0 on availability, 4.0 on audit, 3.0 on cryptography, 4.0 on regulatory, 3.0 on deployment and exit, 3.5 on vendor. Weighted: 0.20 x 4.0 + 0.20 x 3.5 + 0.15 x 3.0 + 0.10 x 4.0 + 0.05 x 3.0 + 0.10 x 4.0 + 0.10 x 3.0 + 0.10 x 3.5 = 0.80 + 0.70 + 0.45 + 0.40 + 0.15 + 0.40 + 0.30 + 0.35 = 3.55 out of 5. Compare it with other vendors scored the same way, and with the price over five years.

---

20 vendor questions to ask in the response

1. For each platform in our scope, which encryption model do you actually deliver (provider-managed, BYOK, HYOK/EKM, client-side)?
2. Where does the cryptographic operation take place on a decrypt: at your service, or at the cloud provider with a key you gave it?
3. Who, in your organisation and in your hosting chain, can invoke or access key operations? Under what controls?
4. In which legal jurisdiction is the key service hosted and operated? Which authorities could compel you or your hosting provider?
5. What happens to our data when the key service is unreachable, per platform? Is it fail-closed, and for how long do caches keep working?
6. What latency does a key operation add, and what are the timeouts of each platform you integrate with?
7. Show us your highest-availability reference architecture and your last failover test.
8. What are your RPO and RTO for the key service itself?
9. How do we revoke the platform's access, and what is the measured time until data becomes inaccessible?
10. How are keys rotated, and does rotation require re-encryption of data?
11. Which HSMs or equivalents back root keys, and with which certifications?
12. How is administrator access authenticated, and can we require approvals from several people?
13. What is logged, where can it be exported, and how do we verify logs were not altered?
14. What happens if an audit record cannot be written?
15. Which of our regulations (GDPR, FADP, DORA, NIS2, FINMA, HIPAA) have you been assessed against by customers or auditors, and what do you provide for audits?
16. What is your post-quantum roadmap, with dates, for key wrapping and signatures?
17. Which parts of the solution are your own code, and which are third-party or open-source components?
18. Describe the exit: how do we leave in 90 days with all data readable?
19. What are the known limitations for each platform integration (features that stop working under customer-held keys)?
20. Which customers in our sector run this in production, and how long?

---

Red flags in vendor answers

• "Encrypted at rest" offered as the whole answer. That is provider-managed encryption; it does not address key control.
• No written statement of who can access keys, or an answer that depends on "trust".
• BYOK sold as HYOK. If the provider ends up holding a usable copy of the key, it is not HYOK.
• Fail-open behaviour presented as a feature, with no explanation of what that does to the control you are buying.
• No latency or capacity figures for the platform that matters most to you.
• High availability described as "cloud-native" without a failover test.
• Exit plan answered with "contact support".
• Compliance claims as a list of regulations with no mapping to capabilities.
• Post-quantum "ready" without named algorithms or dates.
• References that cannot be called.

---

Proof-of-concept plan with pass/fail tests

Run the PoC on the two or three platforms that carry the most risk. Define pass/fail before the PoC starts.

---

Contract and exit clauses

• Data and key ownership. Keys, key metadata and audit logs belong to the customer.
• Jurisdiction and access. Hosting location, entities with potential access, and an obligation to notify the customer of any legal request unless prohibited by law.
• Subprocessors. List, change notification and objection right.
• Availability. SLA with credits, defined fail-closed or fail-open behaviour and maintenance windows.
• Security. Vulnerability disclosure timelines, breach notification period, audit and inspection rights.
• Regulatory. Clauses addressing the specific frameworks that apply to you (for example DORA contractual provisions for ICT third-party services).
• Exit. Assistance, export formats, transition period, price for exit services, and deletion certificates.
• Escrow or continuity where the key service is critical.
• Termination for convenience or for regulatory change.

---

Copy-ready RFP introduction

[Company] is seeking proposals for an enterprise data encryption solution that protects data at rest in [list of platforms: for example Microsoft 365, Salesforce, ServiceNow, AWS, Azure, SQL Server, Oracle, Snowflake, Databricks and AI services] using cryptographic keys that remain under [Company]'s control. The solution must allow [Company] to determine who can use and revoke keys, document the behaviour of each platform when the key service is unavailable, provide audit evidence suitable for [applicable regulations: GDPR, Swiss FADP, DORA, NIS2, FINMA, HIPAA] and offer a documented exit path. Respondents must complete the requirement tables in Appendix B, state their assumptions for each platform, and provide evidence for each Must requirement. Respondents will be evaluated with the weighted model in Appendix C and shortlisted vendors will take part in a proof of concept with pass/fail criteria.

---

FAQ

What should an encryption RFP include?

It should include scope and classification, the encryption models by platform, key control and jurisdiction, integrations, failure behaviour, cryptography, access policies, audit, regulatory mapping, deployment and exit, and vendor support. Add a scoring model and a PoC. The checklist above provides all of these as copyable tables.

What is the difference between BYOK and HYOK in an RFP?

With BYOK you generate or import a key that the provider then holds and uses. With HYOK or external key management the key stays in your key manager and the provider calls it for each operation. Require the vendor to state which model applies per platform, and see BYOK explained.

Should we require fail-closed behaviour?

For regulated data, fail-closed is usually what you want: if the key service is unreachable or refuses, data stays inaccessible. The price is that your key service becomes critical infrastructure. Ask for high availability, outage tests and documented cache behaviour for each platform, and decide fail-closed versus fail-open per workload.

Do we need client-side or double key encryption?

Not for every workload. Double key encryption, such as Microsoft 365 DKE, is meant for a small set of highly sensitive content because some features, such as server-side search, are limited on protected content. Use external key management for the broad estate and double-key or client-side protection for the crown jewels. See the DKE setup guide.

How do we compare HSM-based and software or multi-party key services?

Compare them on the same requirements: who can access keys, certifications, availability, performance, audit and exit. Do not exclude a category by rule unless your regulation does. The KMS RFP template covers key management products in more depth.

How should we handle post-quantum cryptography in the RFP?

Treat it as a roadmap and crypto-agility requirement: ask which algorithms from FIPS 203, 204 and 205 are supported, when, and how algorithms are changed. See the post-quantum RFP template for a dedicated checklist.

Is a vendor outside the EU or Switzerland acceptable?

It depends on your risk assessment, the data and your regulator. What matters is who can access keys and under which legal system. Ask for the jurisdiction of the vendor and of the hosting entity, and read data sovereignty and encryption keys.

---

Conclusion

A good encryption RFP is a test of control, not of features. Ask who holds the keys at runtime, what happens when the key service goes down, how you revoke, how you prove it to an auditor and how you leave. Score vendors with the same weights, and validate in a PoC. DuoKey provides customer-controlled key management across the platforms above, and you can compare it against others using the comparison pages, Fortanix and Entrust. Include DuoKey, and every other vendor, only on the strength of evidence.

---

References

• AWS KMS developer guide, External key stores: https://docs.aws.amazon.com/kms/latest/developerguide/keystore-external.html
• Microsoft Learn, Double Key Encryption: https://learn.microsoft.com/en-us/purview/double-key-encryption
• Regulation (EU) 2016/679 (GDPR): https://eur-lex.europa.eu/eli/reg/2016/679/oj
• Regulation (EU) 2022/2554 (DORA): https://eur-lex.europa.eu/eli/reg/2022/2554/oj
• Directive (EU) 2022/2555 (NIS2): https://eur-lex.europa.eu/eli/dir/2022/2555/oj
• Swiss Federal Act on Data Protection (FADP): https://www.fedlex.admin.ch/eli/cc/2022/491/en
• FINMA Circular 2023/1 Operational risks and resilience: https://www.finma.ch
• HIPAA Security Rule, 45 CFR 164.312: https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-C/part-164/subpart-C
• NIST SP 800-57 Part 1 Rev. 5, Recommendation for Key Management: https://csrc.nist.gov/pubs/sp/800/57/pt1/r5/final
• NIST FIPS 203, 204, 205: https://csrc.nist.gov/projects/post-quantum-cryptography
• DuoKey documentation, OpenAI EKM: https://docs.duokey.com/docs/openai-ekm/overview
• DuoKey documentation, Salesforce EKM: https://docs.duokey.com/docs/salesforce-byok/ekm-module
• DuoKey documentation, SQL EKM: https://docs.duokey.com/docs/sql-ekm/overview
• DuoKey documentation, Cockpit security and audit: https://docs.duokey.com/docs/cockpit/security