A privileged access management RFP that only asks about password vaults and session recording will select yesterday's product, because most privilege now sits in cloud roles, pipelines, service accounts and AI agents rather than in a few domain administrator passwords. This template gives you a ready-to-issue request for proposal for a PAM platform, with numbered requirements written so that every answer can be verified in a proof of concept and scored. It covers discovery, vaulting and rotation, just-in-time access, session management, cloud and infrastructure access, endpoint privilege, machine and agent credentials, vendor access, the security of the PAM platform itself, services and commercials. It is vendor-neutral and written for IAM and infrastructure security leads, procurement and evaluation panels. For what the market offers, read the PAM Buyer's Guide; for the selection process, the Security Vendor Evaluation and RFP Guide.
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.
- Each requirement has an ID (for example PAM-JIT-02) and a type: M mandatory (pass or fail), S scored (0 to 5, weighted) or I informational.
- Weights, volumes and timings in brackets are illustrative, not benchmarks. Set them from your own risk and scale before issue and do not change them afterwards.
- Issue sections 1 to 8 to bidders; the Implementation guidance section is for your panel only.
- If you are buying IGA at the same time, align the requirement IDs with the IGA RFP Template so that governance of privileged access is not bought twice.
1. Purpose and scope
[Organisation] invites proposals for a privileged access management platform and implementation services. The platform must ensure that privileged access by people, workloads and AI agents is discovered, granted only when needed, brokered or recorded where required, and revoked or rotated automatically.
- In scope: [on-premises directory and servers]; [cloud consoles, CLIs and IAM roles in named providers]; [databases]; [Kubernetes clusters]; [network devices]; [SaaS administrator roles]; [endpoints]; [service accounts, API keys and pipeline credentials]; [third-party administrative access].
- Out of scope: [workforce SSO]; [customer identity]; [general secrets for application configuration, if covered by an existing secrets manager].
- Drivers: [audit findings on shared administrator accounts]; [cyber insurance requirements]; [standing cloud administrator access]; [incident lessons].
- Contract term: [three] years with an option to extend by [two] years.
2. Organisation background and current state
| Item | [Organisation] value |
| Human privileged users (administrators, developers with production access, third parties) | [number], [number], [number] |
| Servers by operating system | [number] Windows, [number] Linux and Unix |
| Cloud estate | [providers], [number] accounts, subscriptions or projects |
| Databases and clusters | [engines and number]; [number] Kubernetes clusters |
| Service accounts and machine credentials known | [number or "unknown, discovery required"] |
| SSH keys and certificates | [estimated number]; [SSH certificate authority in use: yes or no] |
| Existing tooling | [vault, secrets manager, endpoint privilege tool, jump hosts] |
| Hosting constraints | [SaaS acceptable / self-hosted required / hybrid] |
3. Instructions to bidders
- Timeline: RFP issued [date]; clarifications by [date]; responses due [date, time, time zone]; proof of concept [dates]; decision [date].
- Single point of contact: [name, email].
- Response scale: available now; available with configuration; custom development; third-party product required (name it); roadmap (committed date); not supported. Roadmap answers score zero unless the date is contractually committed.
- Evidence: reference product documentation or a demonstration for each "available now" answer.
- Architecture: include a diagram of components, where credentials are stored, and every connection the platform makes into [Organisation] networks.
4. Functional requirements
4.1 Discovery and inventory
| ID | Requirement | Type |
| PAM-DSC-01 | Discovers privileged accounts, local administrator accounts, service accounts, SSH keys and cloud administrator roles across the estates in section 2, on a schedule. | M |
| PAM-DSC-02 | Maps service account dependencies (services, scheduled tasks, application pools, scripts) before rotation is enabled. | S |
| PAM-DSC-03 | Flags new privileged accounts and role assignments created outside the platform. | S |
4.2 Vaulting and rotation
| ID | Requirement | Type |
| PAM-VLT-01 | Stores privileged credentials encrypted, with keys protected by [HSM or cloud KMS], and describe key hierarchy and who can access keys. | M |
| PAM-VLT-02 | Rotates passwords and keys on schedule, after each checkout and on demand, and verifies the new credential works. | M |
| PAM-VLT-03 | Rotates a service account used by multiple dependent services without an outage; describe the mechanism. | S |
| PAM-VLT-04 | Supports exclusive checkout, dual control for named high-risk accounts and automatic check-in. | S |
4.3 Just-in-time access and zero standing privilege
| ID | Requirement | Type |
| PAM-JIT-01 | Grants time-bound elevation (group membership, role assignment or ephemeral account) with approval rules and automatic removal at expiry. | M |
| PAM-JIT-02 | Provides JIT for cloud consoles and CLIs in [cloud providers] without permanent role assignments. | M |
| PAM-JIT-03 | Requires a ticket or justification and links it to the session record. | S |
| PAM-JIT-04 | Reports standing privileged access remaining, per platform, as a measurable metric. | S |
See the JIT Access Guide.
4.4 Session management
| ID | Requirement | Type |
| PAM-SES-01 | Brokers RDP, SSH, database and web console sessions without revealing the credential to the user. | M |
| PAM-SES-02 | Records sessions with searchable keystroke or command metadata, and stores recordings tamper-evidently for [period]. | S |
| PAM-SES-03 | Applies command filtering or real-time alerting for defined risky actions, with the option to terminate a session. | S |
| PAM-SES-04 | Supports native client workflows (SSH clients, database tools) as well as browser access, so engineers are not pushed to bypass the platform. | S |
4.5 Infrastructure, cloud and endpoint privilege
| ID | Requirement | Type |
| PAM-INF-01 | Issues short-lived SSH certificates or equivalent identity-based access to Linux hosts, replacing static authorised keys. | S |
| PAM-INF-02 | Provides JIT access to [database engines] and Kubernetes clusters with per-user attribution. | S |
| PAM-INF-03 | Analyses cloud entitlements to identify unused and excessive permissions for human and workload identities. | S |
| PAM-INF-04 | Removes local administrator rights on endpoints with policy-based elevation for approved applications. | S |
| PAM-INF-05 | Manages SaaS administrator roles in [named SaaS platforms]. | I |
See the Cloud PAM and CIEM Guide and the Endpoint Privilege Management Guide.
4.6 Machine, pipeline and AI agent privilege
| ID | Requirement | Type |
| PAM-NHI-01 | Delivers credentials to applications, scripts and CI/CD pipelines at run time through an API or agent, removing hard-coded credentials. | M |
| PAM-NHI-02 | Issues dynamic or short-lived credentials for [databases and cloud], or integrates with workload identity federation, where the target supports it. | S |
| PAM-NHI-03 | Assigns an accountable owner to every privileged non-human identity and includes it in privileged access reviews. | M |
| PAM-NHI-04 | Controls privileged actions by AI agents: scoped, time-bound credentials per task, human approval for defined actions, and full attribution of agent actions to the agent and its owner. | S |
| PAM-NHI-05 | Integrates with [secrets manager] where both will coexist; describe the boundary. | I |
4.7 Third-party access, analytics and governance
| ID | Requirement | Type |
| PAM-VEN-01 | Provides vendor access without VPN or shared accounts: named external identities, approval, time window, recording. | S |
| PAM-ANL-01 | Streams privileged activity and platform audit events to [SIEM]; scores risky sessions and supports integration with identity threat detection. | M |
| PAM-GOV-01 | Runs privileged access reviews or feeds them to [IGA platform], with closed-loop revocation. | S |
See the Vendor Privileged Access Management (VPAM) Guide and the Privileged Session Management Guide.
A PAM platform holds the keys to the estate, so its own security is scored as heavily as its features.
| ID | Requirement | Type |
| PAM-SEC-01 | Platform administrators authenticate through [Organisation] SSO with phishing-resistant MFA; administrative roles are granular and separated from user roles. | M |
| PAM-SEC-02 | No bidder staff access to customer secrets; describe support access, approval and logging, and whether customer-managed keys are supported. | M |
| PAM-SEC-03 | Every platform API key, agent and connector credential is scoped, rotatable and revocable; list all credentials the platform holds for [Organisation] systems. | M |
| PAM-SEC-04 | Documented behaviour when the platform is unavailable, including a tested break-glass procedure that does not depend on the platform. | M |
| PAM-SEC-05 | Provide a current independent assurance report, a [SIG or CAIQ] response, a published vulnerability disclosure policy and the security incident history for the last three years. | M |
| PAM-SEC-06 | Updates to privileged agents can be staged in rings and deferred by [Organisation]. | S |
| PAM-NF-01 | Availability commitment of [percentage]; high-availability and disaster recovery design with stated recovery objectives. | S |
| PAM-NF-02 | Full export of vault contents, policies and audit history at exit, and certified deletion. | M |
See the Break-Glass Account Guide.
6. Implementation, services and support
- Phasing: propose phases with acceptance criteria, for example [domain and cloud administrators first, then servers, then service accounts, then developers and pipelines].
- Rotation risk: describe how service account rotation is introduced without outages: dependency discovery, test rotation, rollback.
- Team and references: named roles and [two or three] references of similar size, at least one using JIT for cloud and one managing machine credentials.
- Upgrades and support: release cadence, notice, support tiers and severity targets.
7. Commercials
| Cost element | What to state |
| Licence metric | Per privileged user, per target, per session, per secret or other; how service accounts, pipelines and AI agents are counted |
| Modules | Which section 4 requirements need separate modules (endpoint, cloud, secrets, vendor access) |
| Infrastructure | Customer-hosted components, sizing and any third-party licences required |
| Implementation and training | Fixed price or day rate with estimated days by phase |
| Growth, renewal and exit | Price for [growth percentage] more targets or identities; renewal cap; exit charges |
8. Evaluation method and proof of concept
| Criterion | Weight | Evidence |
| Functional fit (section 4) | [35%] | Response, proof of concept |
| Platform security and resilience (section 5) | [20%] | Assurance reports, architecture review, proof of concept |
| Usability for administrators and developers | [15%] | Proof of concept scored by the teams who will use it |
| Implementation approach and references | [10%] | Section 6, reference calls |
| Life-cycle cost | [20%] | Section 7 |
Scores use 0 to 5: 0 not met; 1 roadmap only; 3 met with configuration; 5 met fully and demonstrated. The proof of concept of [number] weeks will cover at minimum:
- Discovery against a test estate with known privileged accounts; measure what was found and missed.
- JIT elevation for an administrator in [cloud provider] and for a developer to a production database and Kubernetes cluster from the CLI, with approval and recording.
- Rotation of a service account with at least three dependencies, including rollback.
- A pipeline retrieving a credential at run time with no secret in the repository.
- Review of a recorded session containing a defined risky command, with alerting to [SIEM].
- Platform unavailability: show what still works and run the break-glass procedure.
Implementation guidance
This section is for the evaluation panel, not for bidders.
- Start from where privilege lives: count privileged identities by estate (directory, cloud, databases, Kubernetes, SaaS, endpoints, machines) before writing weights; weight the estates with the most standing privilege.
- Score the developer experience: a platform engineers avoid creates shadow access. Have the people who will use it score PAM-SES-04 and PAM-JIT-02 in the proof of concept.
- Test, do not trust, rotation: PAM-VLT-03 is where projects stall. Use a real service account with real dependencies in the proof of concept.
- Control proof-of-concept access: the bidder's test deployment will hold real privileged credentials. Use dedicated test accounts with expiry and revoke them all at the end.
- Plan for coexistence: decide early which tool owns machine secrets (PAM, secrets manager or both) so that PAM-NHI-01 and PAM-NHI-05 do not create two sources of truth. See the Secrets Management Buyer's Guide.
| Requirement group | NIST SP 800-53 Rev. 5 | NIST CSF 2.0 | ISO/IEC 27001:2022 Annex A |
| Discovery and ownership (4.1, 4.6) | AC-2, AC-6(5) | PR.AA-01 | A.8.2 Privileged access rights |
| Vaulting, rotation, machine credentials (4.2, 4.6) | IA-5, IA-5(7) | PR.AA-01 | A.5.17 Authentication information |
| JIT and least privilege (4.3, 4.5) | AC-2(2), AC-6, AC-6(2) | PR.AA-05 | A.8.2 Privileged access rights |
| Sessions and logging (4.4, 4.7) | AU-14, AC-6(9), AC-17(4) | PR.PS-04, DE.CM-03 | A.8.15 Logging |
| Platform security and supplier (5) | IA-2(1), CP-2, SA-9, SR-6 | GV.SC-05, GV.SC-06 | A.5.19 to A.5.22 Supplier relationships |
Standards and references
Related NHI Mgmt Group resources: PAM Buyer's Guide · Privileged Access Management Guide · IGA RFP Template · Security Vendor Evaluation and RFP Guide · PAM Maturity Model