Secrets management RFPs usually ask whether a product "stores secrets securely" and "supports rotation", every bidder says yes, and the gaps only show up when the first database credential will not rotate without an outage. This template is a ready-to-issue request for proposal for a secrets management platform, with numbered requirements that can be checked in a proof of concept and scored. It covers vaulting, access control, dynamic secrets, rotation, CI/CD and Kubernetes integration, secret scanning, auditing, platform security, services and pricing. It is vendor-neutral and written for platform, security and procurement teams running a selection. For what the market offers and how to think about it, read the Secrets Management Buyer's Guide; this page is the procurement document.
How to use this template
- Replace text in square brackets, such as [Organisation], [cloud providers] and [number], with your own details. Delete requirements that do not apply rather than leaving them unscored.
- Each requirement has an ID (for example SM-RT-03) and a type: M mandatory (pass or fail; a fail eliminates the bid), S scored (0 to 5, weighted) or I informational (not scored). Keep M items to the handful you would genuinely walk away over.
- Weights, volumes and timings in brackets are illustrative. Set them from your own risk and scale before issue, and do not change them once responses arrive.
- Issue sections 1 to 8 to bidders. The Implementation guidance section is for your evaluation panel only.
- Ask for responses in a spreadsheet with one row per requirement ID, plus a link to the product documentation page that supports each answer.
1. Purpose and scope
[Organisation] invites proposals for a secrets management platform and associated services. The platform must become the single authoritative store and broker for machine credentials: API keys, database passwords, cloud access keys, tokens, certificates and encryption keys used by applications, pipelines and AI agents.
- In scope: central vaulting; authentication of workloads and people to the vault; fine-grained access policy; dynamic (on-demand, short-lived) credentials; automated rotation of static credentials; integration with [CI/CD platforms], [Kubernetes distributions] and [cloud providers]; discovery of secrets outside the vault, including secret scanning of code repositories; audit logging; break-glass access.
- Out of scope: [human password management for staff]; [privileged session recording, covered by a separate PAM procurement]; [hardware security modules, unless offered as an integration].
- Contract term: [three] years with an option to extend by [two] years.
- Drivers: [secrets found hard-coded in repositories]; [manual rotation causing outages]; [audit findings on shared credentials]; [growth in non-human identities and AI agents]; [consolidating several cloud-native secret stores].
2. Organisation background and current state
| Item | [Organisation] value |
|---|---|
| Applications and services consuming secrets | [number], of which [number] containerised |
| Known secrets today, by type | [number] database credentials, [number] API keys, [number] cloud keys, [number] certificates, or "unknown, discovery required" |
| Current secret stores | [cloud-native secret managers], [CI/CD variable stores], [Kubernetes Secrets], [configuration files], [spreadsheets] |
| Cloud platforms and on-premises estate | [providers, number of accounts, subscriptions or projects; data centres] |
| CI/CD platforms | [platforms, number of pipelines, self-hosted or managed runners] |
| Kubernetes | [distributions, number of clusters, namespaces] |
| Source code hosting | [platforms, number of repositories] |
| Identity providers | [workforce IdP]; [cloud workload identity mechanisms in use] |
| Hosting and residency | [SaaS acceptable in named regions / self-hosted required / both] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarification questions by [date]; answers shared with all bidders by [date]; responses due [date, time, time zone]; shortlist and proof of concept [dates]; decision [date].
- Single point of contact: [name, email]. Contact with other [Organisation] staff about this RFP may lead to disqualification.
- Response scale: for each requirement state one of available now; available with configuration; available with custom development; third-party product required (name it); roadmap (with a committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Evidence: reference the documentation page, screenshot or demonstration supporting each "available now" answer.
- Edition: state which edition or tier each answer applies to. An answer that needs a higher tier than the one priced in Appendix B must say so.
4. Functional requirements
4.1 Vaulting and secret storage
| ID | Requirement | Type |
|---|---|---|
| SM-VT-01 | Stores secrets encrypted at rest with authenticated encryption (for example AES-256-GCM) using envelope encryption, with key-encryption keys held in [HSM or cloud KMS] and never stored beside the data they protect. | M |
| SM-VT-02 | Versions every secret, keeps previous versions for a configurable period and supports rollback to a named version. | S |
| SM-VT-03 | Records metadata per secret: owner, purpose, consuming workloads, environment, creation date, last rotation, expiry. | M |
| SM-VT-04 | Supports secret types: key-value, certificates and private keys, SSH keys, and encryption as a service (applications send data to be encrypted without receiving the key). State which are included. | S |
| SM-VT-05 | Provides high availability across [zones or sites] and documented, tested backup and restore, with encrypted backups. State recovery point and recovery time objectives. | M |
| SM-VT-06 | Supports multi-region or multi-cluster replication with defined consistency behaviour, and describes how secrets are served if the primary is unreachable. | S |
4.2 Authentication and access policy
| ID | Requirement | Type |
|---|---|---|
| SM-AC-01 | Authenticates workloads using platform identity rather than a stored bootstrap secret: cloud instance and workload identity, Kubernetes service account tokens, and OpenID Connect tokens from CI/CD platforms. List supported methods. | M |
| SM-AC-02 | Enforces least privilege per secret or path, per identity, with deny by default and policy as code under version control. | M |
| SM-AC-03 | Human access through [Organisation] SSO (SAML 2.0 or OpenID Connect) with phishing-resistant MFA; no local administrator accounts in routine use. | M |
| SM-AC-04 | Supports approval workflows and time-bound access for sensitive secrets, including dual control for break-glass retrieval. | S |
| SM-AC-05 | Supports tenancy separation (namespaces, projects or equivalent) so that teams administer their own secrets without platform-wide rights. | S |
See the Secrets Zero Problem Guide for why SM-AC-01 matters more than any storage feature.
4.3 Dynamic secrets
| ID | Requirement | Type |
|---|---|---|
| SM-DY-01 | Generates unique, short-lived credentials on request for [databases], [cloud providers] and [message brokers], with a lease and automatic revocation at lease expiry. List supported targets. | M |
| SM-DY-02 | Allows lease duration and maximum time to live to be set per role, and supports early revocation of one lease, all leases for an identity, or all leases for a target. | M |
| SM-DY-03 | Ties each dynamic credential in audit logs to the requesting workload identity, so a database login can be traced back to the workload. | S |
| SM-DY-04 | Describe the effort to add a target that has no built-in plugin, and who maintains the plugin. | I |
Restarting an application does not revoke a stolen credential: only lease expiry or explicit revocation does, as the OWASP Secrets Management Cheat Sheet points out. See the Dynamic Secrets and Ephemeral Credentials Guide.
4.4 Rotation of static secrets
| ID | Requirement | Type |
|---|---|---|
| SM-RT-01 | Rotates static credentials on a schedule and on demand for [target list], updating the credential on the target system, not only in the vault. | M |
| SM-RT-02 | Rotates without downtime using a staged process: create the new version, test it against the target, promote it to current, then retire the old version after a grace period. Describe failure handling and automatic rollback. | M |
| SM-RT-03 | Notifies or pushes new versions to consumers (agent, sidecar, CSI volume refresh, webhook) so applications pick up rotated values without redeployment. | S |
| SM-RT-04 | Reports secrets past their rotation or expiry policy, by owner and team. | S |
| SM-RT-05 | Supports emergency rotation of every secret a given identity or system could read, in one operation, for incident response. | S |
The Secrets Rotation Runbook Template describes the process these requirements automate.
4.5 CI/CD integration
| ID | Requirement | Type |
|---|---|---|
| SM-CI-01 | Authenticates pipeline jobs with short-lived OIDC tokens from [CI/CD platforms], with policy bound to token claims such as repository, branch or ref and environment, so no long-lived vault token is stored in the pipeline. | M |
| SM-CI-02 | Provides native plugins or actions for [CI/CD platforms] that fetch secrets at job run time and mask them in job logs. | S |
| SM-CI-03 | Prevents jobs from forks or untrusted branches from obtaining production secrets. Describe the control. | M |
| SM-CI-04 | Discovers secrets stored in [CI/CD platform] variables and reports them for migration. | S |
See the CI/CD Pipeline Identity Security Guide.
4.6 Kubernetes and container integration
| ID | Requirement | Type |
|---|---|---|
| SM-K8-01 | Authenticates pods by Kubernetes service account identity, scoped by namespace and service account. | M |
| SM-K8-02 | Delivers secrets to pods without baking them into images, through at least one of: a Secrets Store CSI Driver provider, an agent or sidecar writing to an in-memory volume, or a controller syncing to Kubernetes Secrets. State which are supported and which are generally available. | M |
| SM-K8-03 | Refreshes delivered secrets in running pods after rotation and documents application restart requirements. | S |
| SM-K8-04 | Where secrets are synced into Kubernetes Secrets, document the dependency on etcd encryption at rest and on Kubernetes RBAC, and the bidder's recommended configuration. | S |
See the Kubernetes Secrets Security Guide and the External Secrets Operator security guide.
4.7 Discovery and secret scanning
| ID | Requirement | Type |
|---|---|---|
| SM-SC-01 | Scans [source code platforms], including full Git history on all branches, for hard-coded secrets, with built-in and custom patterns. | S |
| SM-SC-02 | Blocks secrets at commit or push time (pre-commit hooks or push protection) with a documented bypass and review process. | S |
| SM-SC-03 | Checks whether a detected secret is still valid and prioritises live findings. | S |
| SM-SC-04 | Scans container images, build logs and artefacts, and collaboration tools [list], and reports where each secret was found. | S |
| SM-SC-05 | Raises a remediation workflow per finding: revoke, rotate, move into the vault, then clean up. If scanning is not part of the bidder's product, state the integrations with third-party scanners. | S |
See the Git Secret Scanning Guide and Developer Secret Scanning Triage.
4.8 Audit, reporting and AI agents
| ID | Requirement | Type |
|---|---|---|
| SM-AU-01 | Logs every request, approval or denial, secret read, lease, rotation, policy change, authentication failure and administrative action, with identity, time and source, tamper-resistant and retained for [period]. | M |
| SM-AU-02 | Streams audit events to [SIEM] in near real time through a documented format. | M |
| SM-AU-03 | Never writes secret values to its own logs; describe how this is enforced. | M |
| SM-AU-04 | Reports unused secrets, secrets with no owner and identities with access to more secrets than they read. | S |
| SM-AU-05 | Describe support for AI agents and MCP servers obtaining scoped, short-lived credentials per task, and any generative AI features in the product, including what customer data they use. | I |
5. Platform security and non-functional requirements
| ID | Requirement | Type |
|---|---|---|
| SM-SEC-01 | Describe how the root or unseal keys are protected, split and recovered, and who can perform recovery. | M |
| SM-SEC-02 | For SaaS: describe how bidder staff access customer data, whether the bidder can decrypt customer secrets, and whether customer-managed keys are supported. | M |
| SM-SEC-03 | Provide a current independent assurance report (ISO/IEC 27001 certificate with in-scope service, or SOC 2 Type II) and a completed [SIG or CAIQ] questionnaire. | M |
| SM-SEC-04 | State the vulnerability disclosure process, patch cadence and the last two years of security advisories for the product. | S |
| SM-NF-01 | Availability commitment of [percentage] with service credits, and documented client behaviour (caching, retry) during an outage. | M |
| SM-NF-02 | Supports [number] secret reads per second at [latency] with [number] concurrent clients. | S |
| SM-NF-03 | Full export of secrets, metadata, policies and audit history in a documented format at exit. | M |
6. Implementation, services and support
- Approach: phases, deliverables and acceptance criteria for [first platform team, two pipelines and one cluster] within [months], then migration waves.
- Migration: method and tooling to import secrets from current stores, and how consumers are switched without outage.
- Team: named roles and experience with deployments of similar size; split between bidder, partner and [Organisation] effort.
- Upgrades: release cadence, notice period and long-term support versions for self-hosted deployments.
- Support: tiers, hours, response targets by severity. A vault outage stops deployments, so ask for a 24x7 severity 1 response.
- References: [two or three] customers of similar size, at least one running dynamic secrets in production.
7. Commercials
| Cost element | What to state |
|---|---|
| Licence metric | Per client, per secret, per API call, per node or flat; how workloads, pipeline jobs and AI agents are counted |
| Editions | Which section 4 and 5 requirements need a higher tier or add-on (for example replication, HSM integration, scanning) |
| Hosting | SaaS subscription, or self-hosted licence plus [Organisation] infrastructure cost |
| Implementation and migration | Fixed price or time and materials with day rates and estimated days by phase |
| Growth and renewal | Price at [twice] current volumes; cap on renewal increases |
| Exit | Charges for export and transition assistance |
8. Evaluation method and proof of concept
[Organisation] will check mandatory requirements first, then score the rest with these illustrative weights:
| Criterion | Weight | Evidence |
|---|---|---|
| Workload authentication and access policy (4.2) | [15%] | Response, proof of concept |
| Dynamic secrets and rotation (4.3, 4.4) | [20%] | Proof of concept |
| CI/CD and Kubernetes integration (4.5, 4.6) | [20%] | Proof of concept |
| Discovery and scanning (4.7) | [10%] | Demonstration on a test repository |
| Platform security, resilience and audit (4.8, 5) | [15%] | Assurance reports, questionnaire |
| Life-cycle cost (7) | [20%] | Appendix B at current and doubled volumes |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. Shortlisted bidders run a proof of concept of [two to four] weeks in a [Organisation] test environment covering at least:
- A pipeline job on [CI/CD platform] obtains a database credential using an OIDC token, with no stored vault token; a job from a fork is refused.
- A pod in [cluster] reads a secret by service account identity; the secret is rotated and the pod picks up the new value as documented.
- A dynamic database credential is issued, used, traced in the audit log to the workload, and revoked early.
- A static credential on [target] is rotated on schedule with no failed application requests; a deliberately failed rotation rolls back.
- A seeded test secret in a repository is detected, checked for validity and routed into the remediation workflow.
- All audit events from the test arrive in [SIEM] and contain no secret values.
- Break-glass retrieval under dual control, then a full export.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Test bootstrap first: a vault that needs a long-lived token baked into every pipeline only moves the problem. Treat SM-AC-01 and SM-CI-01 as the deciding items.
- Insist on target-side rotation: a product that versions a value in the vault but does not change it on the database is not rotating. Watch for this in demonstrations.
- Check edition answers against Appendix B: replication, HSM support and scanning are often priced separately. Score against the tier you are being quoted.
- Use synthetic secrets in the proof of concept: issue bidders time-limited test accounts, never production credentials, and revoke everything at the end.
- Treat the platform as tier zero: it holds the keys to most of the estate. Weight section 5 accordingly and plan the recovery ceremony before go-live.
- Plan migration and clean-up: moving a secret into the vault does not remove copies in history, images and logs. Budget for rotating every migrated secret.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 |
|---|---|---|
| Vaulting and encryption (4.1) | SC-12, SC-28 | PR.DS-01 |
| Authentication, policy, rotation (4.2 to 4.4) | IA-5, AC-6 | PR.AA-01, PR.AA-05 |
| No hard-coded secrets (4.5 to 4.7) | IA-5(7) | PR.AA-01 |
| Audit (4.8) | AU-2 | DE.CM-09 |
| Supplier assurance (5, 8) | SA-9, SR-6 | GV.SC-06 |
After award, carry requirement IDs into the statement of work and acceptance tests. For broader context see the Secrets Management Guide and the Security Vendor Evaluation and RFP Guide.
Standards and references
- OWASP: Secrets Management Cheat Sheet
- NIST: SP 800-53 Rev. 5 Security and Privacy Controls
- NIST: Cybersecurity Framework 2.0
- Kubernetes SIGs: Secrets Store CSI Driver
- Kubernetes: Encrypting Confidential Data at Rest
- GitHub Docs: About security hardening with OpenID Connect
- GitHub Docs: About secret scanning
Related NHI Mgmt Group resources: Secrets Management Buyer's Guide · Cloud Secrets Managers Guide · NHI Security Platform RFP Template · PAM RFP Template · Vendor Security Assessment Template