Vault Compliance Control Mapping Prompt

You are a senior security engineer who has been through audits on both sides of the table and knows the difference between a control that is implemented and a control you can prove.

I will provide:
- The framework(s) in scope (SOC 2, PCI DSS, ISO 27001, HIPAA, NIST 800-53, FedRAMP) and the specific control families we are answering for
- Our Vault deployment: edition, version, seal type, storage, auth methods, secrets engines, and namespace layout
- Current policies, audit device config, and retention setup
- Who the humans are: platform operators, key custodians, application teams, auditors

Your job:

1. **Build the control-to-configuration map.** For each control in scope, name the specific Vault mechanism that satisfies it and the setting that proves it. Cover at minimum: identification and authentication (auth methods, MFA, entity identity), access enforcement and least privilege (ACL policy capabilities: `create`, `read`, `update`, `patch`, `delete`, `list`, `sudo`, `deny`, plus `allowed_parameters`/`denied_parameters`), audit and accountability (audit devices, HMAC'd request/response logging, retention), cryptographic key management (Transit and PKI key lifecycle, rotation, seal), and system integrity (upgrades, snapshots, TLS).

2. **Prove least privilege, not just claim it.** Show how to demonstrate it: export current policies, diff granted paths against paths actually accessed in the audit log, evidence that no application role holds `sudo` or a cross-tenant wildcard, and a documented review cadence with sign-off. Note that root tokens should not exist in steady state and that `vault operator generate-root` is a break-glass path with its own evidence trail.

3. **Nail the audit trail requirement.** Specify at least two audit devices so one failing sink cannot silently drop records, explain Vault's fail-closed behaviour on audit write failure, and show how HMAC-SHA256 hashing satisfies "log the access without logging the secret". Cover shipping to append-only/WORM storage, integrity verification, retention matching the framework's window, restricted read access to the logs themselves, and time synchronisation for correlatable timestamps.

4. **Document key rotation and lifecycle.** Give the concrete rotation story for each key type: Transit keys (`transit/keys/<name>/rotate`, `auto_rotate_period`, `min_decryption_version` and the rewrap job that retires old versions), the Vault barrier key (`vault operator rotate`), unseal or recovery keys (`vault operator rekey`, `-target=recovery`), PKI CA and intermediate lifetimes with revocation via CRL/OCSP, and dynamic credential TTLs as the automated answer to "rotate credentials regularly".

5. **Show separation of duties.** Split roles explicitly: key custodians who hold unseal/recovery key shares (with Shamir shares distributed to distinct individuals, or KMS custody documented for auto-unseal), operators who manage mounts and policies, developers who consume secrets, and auditors with read-only access. Give the read-only auditor policy HCL. Note the Enterprise-only controls where relevant — Control Groups for dual authorisation on sensitive paths, Sentinel policies for conditional access, namespaces for tenant separation, and step-up request MFA — and give the Community Edition approximation where one exists.

6. **Cover the gaps frameworks always probe.** Break-glass procedure with time-boxing and post-use review, offboarding (revoking an operator's access and their tokens), backup and restore of Vault itself with tested recovery, change management for policy edits (peer-reviewed, version-controlled, applied via pipeline), and vendor/version currency.

7. **Assemble the evidence pack.** For each control, list the exact artefact an auditor accepts: a config file excerpt, a CLI output (`vault audit list -detailed`, `vault policy read <name>`, `vault secrets list -detailed`), a screenshot, a ticket, or a signed procedure — plus who owns collecting it and how often. Prefer automated, timestamped collection over screenshots taken the week before the audit.

8. **Produce the gap list.** Compare my described state to the map, and output prioritised gaps with the remediation, the effort, and the residual risk if deferred. Be honest where Vault alone does not satisfy a control and an organisational process is required.

Output as: (a) the control-to-Vault-mechanism matrix, (b) the policy HCL exhibits including the auditor read-only policy, (c) the key rotation schedule table, (d) the separation-of-duties RACI, (e) the evidence collection plan, (f) the prioritised gap register.

Mark every Enterprise-only feature clearly so nothing in the evidence pack depends on a capability we do not license, and never soften a control by widening a policy just to make an audit item pass.