What PCI DSS 3.7 key management lifecycle requires in practice
Requirement 3.7 asks you to manage the keys that protect stored account data across their whole life, from generation to retirement, and to prove it with records an assessor can inspect. If your encryption of stored PAN depends on keys, this requirement decides whether that encryption counts for anything. The nine sub-requirements, 3.7.1 to 3.7.9, cover how keys are generated with strength, distributed and stored securely, changed at defined cryptoperiods, retired or replaced when weakened or compromised, protected against unauthorized substitution, handled under split knowledge and dual control, acknowledged by the people who hold them, and, for service providers that share keys with customers, explained to those customers in documented guidance.
Keys are the weak point of encryption because the algorithm is rarely the problem. If a key is copied to a laptop, left in a configuration file, or held by one administrator who can also read the data it protects, the ciphertext offers little protection. Start by inventorying every key that protects stored PAN, including backup and archive copies, then record who can perform each cleartext operation. The most frequent gaps assessors report sit in 3.7.6, where manual cleartext key operations need split knowledge and dual control, and in 3.7.8, where custodians must formally acknowledge their responsibilities in writing or electronically. Both are easy to lack in practice because they depend on process records rather than on a system setting.
Confirm with your QSA how they expect to see evidence for each sub-requirement, and set your own cryptoperiods and retirement triggers in a written procedure before the assessment starts. If you are a service provider, decide early whether 3.7.9 applies to any key you share with customers, because that guidance must exist as a document. Open-source key managers such as OpenBao can hold and rotate keys and log access, but the custodian roster, acknowledgments and dual-control procedure remain your organization's responsibility and must be evidenced separately.
Which keys, systems and people fall under 3.7
Requirement 3.7 applies to every key that protects stored account data, wherever that key lives and whoever touches it. The decisions below determine how many keys, custodians and third parties your assessor will expect you to govern, so settle them before you size the work.
Keys protecting stored PAN
Every key that encrypts stored PAN is in scope, including keys for database columns, encrypted files, backup sets and tokenization services. Teams often count only the application key and miss the backup encryption key or the key behind an export job. Build an inventory that maps each key to the datastore it protects, the owner and the rotation method. Effort rises with the number of datastores and backup chains, so start the inventory there.
Key-encrypting keys
Keys that encrypt other keys carry the same lifecycle obligations as the data keys they wrap. A compromise of one key-encrypting key can expose every data key beneath it, so assessors trace the full chain. Document how each wrapping key is generated, stored and rotated, and where the wrapped data keys are kept. Expect extra effort when wrapping relationships were created years ago by different teams.
HSM, cloud KMS or self-hosted vault
The storage model decides which evidence you produce. A hardware security module, a cloud key management service or a self-hosted vault each handles key generation, access logging and rotation differently, and each shifts some responsibility to a provider. Confirm with each vendor which lifecycle steps are performed by the service and which are your duty. For self-hosted vaults, the transit engine in OpenBao supports versioned keys and rotation, but you still own the evidence that rotation happened on schedule.
Third parties who generate or hold keys
A payment processor, a managed key service or a hosting provider may generate, hold or transport keys on your behalf. Each arrangement needs a written allocation of who performs each lifecycle step and who keeps the records. Ask each third party for its key lifecycle procedures and its custodian acknowledgments, and list those gaps in your responsibility matrix before the assessment begins. Vendor reports alone rarely cover your keys, so plan for direct requests.
Manual cleartext key operations
Any step where a person handles a key in cleartext, such as loading a master key during recovery or printing a key component, triggers split knowledge and dual control. Find these operations by reviewing runbooks and break-glass procedures, not only system configuration. Each one needs two or more custodians, documented procedures and acknowledgment records. Automating these steps through a managed service can remove the manual exposure, so confirm which procedures remain manual.
Service provider status and 3.7.9
If you share keys with customers, Requirement 3.7.9 applies and you must provide documented guidance on securely transmitting, storing and updating those keys. This adds a customer-facing deliverable and a review cycle each time the key model changes. Entities that do not share keys with customers do not carry this extra duty. Confirm your status with your acquirer or the payment brand rules before you scope this work.
How to build a key lifecycle that passes 3.7
This sequence turns the key management lifecycle in Requirement 3.7 into a set of documented standards, registers and records that an assessor can trace from each key to its custodians, rotation history and retirement. Work through the steps in order, because each one produces the input the next one needs.
Inventory every key and its purpose
Start by listing every cryptographic key that protects stored account data, including data-encryption keys, key-encrypting keys, keys held in hardware security modules, keys inside application and database encryption, and keys used in backups and disaster recovery copies. For each key, record its purpose, the data or system it protects, where it is stored, which systems use it and who owns it. The output is a key inventory that the rest of the sequence refers to. Confirm the inventory against the data-flow and system diagrams, because a key missing from the inventory is usually a key missing from every later control.
Define generation and storage standards
Write a key standard that states how keys must be generated, which algorithms and key lengths are approved, which random number sources are acceptable, and which storage forms are allowed for each key type. The standard should say where keys may and may not sit in clear text, and it should name the approved hardware or software key stores in use. Ask your assessor, or your qualified security assessor, to confirm that the approved algorithms match the current version of the standard. The output is a signed key standard that engineers can follow and that an assessor can compare against each key in the inventory.
Set cryptoperiods and rotation triggers
For each key in the inventory, set a cryptoperiod, which is the defined period of use after which the key must be changed. Also define event-based triggers that force an earlier change, such as a custodian leaving the team, suspected exposure, a change in the system that holds the key, or a key reaching the end of its approved use. Base the periods on your risk analysis and on guidance from your key store vendor, and record the reasoning so the choice can be defended. The output is a cryptoperiod schedule and a list of rotation triggers, both referenced from the key standard.
Design dual control and split knowledge
Identify every manual operation that handles a key in clear text, such as loading a key component, entering a key by hand, or exporting a key for transfer. For each one, design dual control so that two authorized people must act together, and split knowledge so that no single person holds the full key. Document who may perform each operation and how the two parts are kept apart. Where the key store can do this inside the system, prefer that design and record why. The output is a set of documented manual key procedures, each with its dual control and split knowledge arrangement written out.
Name custodians and collect written acknowledgments
Name a custodian for each key or key component, keep the list short, and record the role each custodian holds. Ask every custodian to sign or electronically accept a statement that they understand and accept their responsibilities for the keys they hold. Store the signed acknowledgments with the custodian register, and set a reminder to reissue them when a custodian changes role or when the register changes. The output is a custodian register and a complete set of acknowledgments on file. An assessor will check that each name in the register has a matching acknowledgment and that no key operation was performed by someone outside the register.
Document compromise and retirement procedures
Write the procedures for what happens when a key is suspected of compromise, reaches the end of its cryptoperiod, or must be replaced. Cover how the replacement key is generated, how data protected by the old key is re-encrypted or retired, how the old key is destroyed or made unrecoverable, and who approves each step. Include a path for keys that are weakened by an algorithm change, not only keys that are stolen. The output is a compromise and retirement runbook plus a rotation record template that captures the date, reason, approver and outcome of each change.
Set up logging and rotation records
Configure the systems that hold or use keys to log key creation, access, export, rotation and deletion events, and send those logs to a location where they cannot be altered by the people operating the keys. Where a key management service exposes audit logs, enable them and confirm retention with your log policy. Use version control or a managed record store for the key standard, the custodian register and the rotation records so each change has an author and a date. The output is a set of key event logs and version-controlled records that show, for any key, its full history from generation to retirement.
How an assessor tests each 3.7 sub-requirement
Assessors start by asking how keys come into existence and how they reach the systems that use them. For generation, they interview the people who create keys and review the tooling or configuration that produces them. They look for evidence that keys come from a vetted random source with an approved strength, not from a password, a predictable seed or a value copied from a document. For distribution, they trace a sample of keys from creation to the point of use and check that transport happened over a protected channel or through a controlled ceremony.
- Interview: Ask the key owner how a new data encryption key or key-encrypting key is generated, who can trigger it and which library or hardware module performs it.
- Configuration review: Inspect the key generation settings, algorithm and key length, and any hardware security module or key manager policy that enforces them.
- Sample trace: Select several keys and follow each from generation to deployment, reviewing transfer logs and the channel used.
- Common findings: Keys generated by scripts with hard-coded seeds, keys sent by email or chat, and no record of which channel carried a key.
Before the assessment, confirm that you can show the generation method, the approved algorithms in use and a complete distribution log for a sample of keys.
This group covers where keys live while they are in use and how they change over time. Assessors check that keys are stored only in approved forms, that key-encrypting keys are protected separately from the data keys they wrap, and that each key has a defined cryptoperiod with a documented trigger for replacement. They also test whether compromised or weakened keys are retired on schedule. Rotation is judged on records, so the assessor will compare the defined cryptoperiods against the actual change history.
- Configuration review: Check key store settings, access policies and whether keys are held in an approved container such as a hardware module or a managed key service.
- Observation: Watch a live rotation or ask for a recent one to see the steps, approvals and the cutover to the new key.
- Sample of rotation records: Pick keys across different systems and compare each key's creation date, last rotation and the cryptoperiod written in the procedure.
- Common findings: Cryptoperiods written in policy but never applied, keys that were never rotated after staff changes, and key-encrypting keys stored beside the data they protect.
Before the assessment, make sure each key has a recorded owner, cryptoperiod and rotation history that can be exported without manual reconstruction.
Where a person handles a key in cleartext, the assessor expects no single individual to have the whole key and no single person to complete the operation alone. The test is largely observational. The assessor asks for the manual key operations your team performs, such as loading a key component or reconstructing a master key, and then watches or reviews records of how those steps were split between two or more people. The question is whether the control works in practice, not only whether it appears in a procedure.
- Observation of a key ceremony: Watch a manual operation and confirm that each component is held by a different custodian and that two people are present where dual control applies.
- Interview: Ask custodians which component they hold and how they would know if another custodian had acted alone.
- Records review: Check ceremony logs, sign-in sheets, witness signatures and the access rights that allow each component to be retrieved.
- Common findings: A single administrator with rights to both components, ceremonies run without a witness, and manual steps performed by one person in an emergency with no later review.
Before the assessment, list every manual cleartext operation, name the custodians for each component and keep the ceremony records together.
The final group concerns the people responsible for keys and, for service providers, the guidance given to customers. For custodians, the assessor checks that each person has formally acknowledged their responsibilities, in writing or electronically, and that the acknowledgment is current. For service providers that share keys with customers, the assessor reviews whether documented guidance covers how keys are transmitted, stored and updated. The test uses personnel files, acknowledgment records and the customer-facing documents themselves.
- Records review: Compare the current custodian list against signed or electronic acknowledgments and confirm that new and departing custodians are covered.
- Interview: Ask a custodian to explain their responsibilities and where the acknowledgment is kept.
- Document review: For service providers, read the customer guidance and check it covers transmission, storage and updating of shared keys.
- Common findings: Custodians who never signed an acknowledgment, lists of custodians that are out of date, and customer guidance that is generic or was never issued.
Before the assessment, confirm that every custodian has a dated acknowledgment and that any customer guidance is version-controlled and reflects current practice.
Why cryptoperiod evidence decides most 3.7 findings
Assessors rarely fail a team because it lacks a key rotation policy. They fail it when the team cannot show that keys were actually changed at the cryptoperiod it defined, that a retired or weakened key was replaced, and that the old copies were handled as the procedure says. A policy states intent; only dated records prove that the key lifecycle ran. Before the assessment, ask the team to pick several keys at random and produce, for each one, the generation date, the activation date, the scheduled change, the replacement and the destruction or archival of the prior material. If any link in that chain depends on an email or a memory, expect a finding.
Versioned keys make this provable when the platform records every version it creates. In OpenBao, the transit secrets engine supports versioned encryption keys with key rotation, so each ciphertext carries the version that produced it and the older versions remain available for decryption. The operator's job is to confirm which settings define the rotation interval, which audit device captures rotation events, and whether old versions are set to be disabled or deleted at a defined point. Ask the platform owner to show the audit log entries for a past rotation, not only the configuration that would produce them. Nextcloud server-side encryption, by contrast, keeps keys on the server, so the team should confirm how and when its master key material is changed and where that change is recorded.
Gaps usually appear when rotation is manual and depends on one person remembering a date or a command. The first sign is a key that is older than the defined cryptoperiod with no change record, and the second is a rotation performed by a single administrator whose only trace is a chat message. Plan for this risk now: put the cryptoperiod into a calendar or ticketing workflow owned by a named role with a backup, require a change ticket that links to the audit event, and review overdue keys each month. Illustrative example: a team rotates a data key every twelve months on paper, but the scheduled task was disabled after one administrator left, and nobody noticed until the assessor asked for the last change record.
Evidence that passes 3.7 and how to keep it current
Requirement 3.7 is tested through records, not declarations. The artifacts below show an assessor how keys are created, moved, stored, rotated, retired and handed to people, and each one stays useful only if it is updated when the key estate changes rather than rebuilt before each assessment.
Key inventory register
A current register of every key that protects stored account data, with its purpose, algorithm, location, custodians, creation date, cryptoperiod and status. Assessors start here to confirm that every key in scope has an owner and a rotation date. Keep it current by tying each new key to a change ticket, so a key cannot exist in production without a register entry. Review the register against a storage export each quarter and record discrepancies.
Generation and distribution procedures
Written procedures showing how strong keys are generated and how they reach the systems that use them without exposure in transit. Describe the approved generator, the entropy source and the secure channel used for distribution. Keep these procedures versioned, and update them when tooling changes so the written method matches what engineers actually run.
Storage configuration exports
Dated exports showing where keys are held, how they are protected and which access rules apply, such as key management service policies or vault configuration. Assessors compare these exports with the inventory to find keys stored in plain configuration files or source repositories. Schedule the export as an automated job and store each output with a timestamp, so the evidence builds up between audits instead of being assembled at the end.
Cryptoperiod policy and rotation logs
The defined cryptoperiod for each key type, along with logs proving that keys were changed when those periods ended. The policy sets the expected lifetimes, and the logs show rotation events with the old and new key versions. Keep the policy as the single source for rotation dates, and make sure the rotation log is generated by the system that performs the rotation rather than typed by hand.
Dual control and split knowledge records
Records of each manual cleartext key operation, showing that two or more people with separate key components performed it. Requirement 3.7.6 applies wherever personnel handle keys in cleartext, so the record should name each participant, the operation, the date and the approving authority. Keep this current by logging every ceremony at the time it happens, including the ones that look routine.
Custodian acknowledgments and compromise records
Signed or electronic acknowledgments from each key custodian confirming they understand and accept their responsibilities under Requirement 3.7.8, paired with records of any weakened or compromised key and its retirement or replacement. Re-acknowledge custodians when roles change, and link every compromise record to the replacement key and the incident ticket. Assessors look for gaps between departures and updated custodian lists, so reconcile those two sources each time someone leaves.
Service provider customer guidance
If the organization shares keys with customers, Requirement 3.7.9 expects documented guidance on secure transmission, storage and updating of those keys. Keep the guidance in a versioned knowledge base with a change history, so assessors can see what customers were told and when it changed. Confirm with the assessor whether this requirement applies to your entity before investing time in the document.
What meeting 3.7 costs and what drives it up
This table lists the cost components of meeting Requirement 3.7, whether each is one-time or recurring, what drives it up, and how to reduce it. Use it to frame a written quote, since no price or duration is published for this work and every figure depends on your own key estate.
| Cost component | One-time or recurring | What drives it up | How to reduce it |
|---|---|---|---|
| Key management tooling or licenses | Recurring | Number of keys and environments, HSM or cloud KMS fees, and commercial key manager licensing per node or tenant | Compare commercial licenses with self-hosted open source such as OpenBao, then confirm which features your assessor needs, such as versioned keys and rotation |
| Engineering time to build rotation and access controls | One-time, with ongoing changes | Manual cleartext key operations, number of applications that hold keys, and how many key-encrypting keys must be separated | Automate rotation and distribution early, and document one pattern that every application reuses |
| Custodian time and training | One-time setup, recurring refreshers | Number of custodians, turnover, and the number of dual control procedures that need named people | Keep custodian groups small, use a documented onboarding script, and schedule training with each role change |
| Written custodian acknowledgments | One-time per custodian, recurring on role change | Number of custodians and how often roles change, plus any HR or legal review of the wording | Use one standard acknowledgment template, and tie it to the joiner, mover and leaver process |
| Evidence upkeep | Recurring | Number of key operations logged, retention periods for logs and records, and how many systems feed evidence | Log key events centrally, keep rotation records in a versioned wiki or repository, and collect evidence on a fixed calendar |
| External review of the key design | Recurring or per project | Complexity of the cryptographic architecture, number of key hierarchies, and changes to providers or cloud regions | Review the design once after major changes, and ask the reviewer to scope the review against 3.7 only |
| Assessor sampling effort | Recurring at each assessment | Number of keys and custodians the assessor samples, and how well records match the documented process | Keep one complete record per key lifecycle event so sampling can be finished quickly |
| Service provider customer guidance (3.7.9) | One-time, recurring on update | Number of customers that receive shared keys and how often key transport methods change | Publish one controlled guide and version it with each change |
Who owns, implements and assesses the key lifecycle
Your organization owns the key lifecycle. The standard expects a named function that sets the key management policy, decides how keys are generated, distributed, stored and retired, and answers for the outcome. That accountability cannot be transferred to a consultant or a tool, even when much of the work is done by others. Your team also appoints the people who act as key custodians and approves changes to cryptoperiods and key retirement.
- Key policy ownership: Maintain the written policy that sets cryptoperiods, approved algorithms and key lengths, and the conditions for emergency replacement.
- Custodian appointments: Name each custodian, record the scope of their key duties, and collect their written or electronic acknowledgment of responsibilities.
- Rotation and retirement approval: Approve scheduled key changes and the replacement of any key suspected of weakening or compromise.
- Dual control decisions: Decide which manual cleartext operations need split knowledge and dual control, and who holds each part.
- Evidence custody: Keep the signed acknowledgments, change records and access logs where the assessor can request them.
Before the assessment, confirm that each custodian can name their duties and that the approvals in your records match the policy as written.
An implementation partner prepares the systems, procedures and evidence that your team then operates. DeployOpen plans, configures and documents self-hosted platforms in your own infrastructure, so a typical engagement may cover key storage and transit encryption design, tooling configuration, runbooks for custodians and a readiness review before the assessor arrives. The partner does not set your policy or act as a custodian, and it does not issue any report or validation.
- Lifecycle design: Map each step from generation to retirement to a documented procedure, tool and owner.
- Tool configuration: Configure a key management service so that versioned keys, rotation and access logging are in place. For example, OpenBao's transit secrets engine supports versioned keys with rotation, which can be configured to match the cryptoperiods in your policy.
- Procedure and runbook preparation: Write the steps for dual control, key distribution and emergency replacement for your team to approve.
- Evidence preparation: Set up the records an assessor will sample, such as rotation logs, approval tickets and custodian acknowledgments.
- Readiness review: Test the lifecycle against Requirement 3.7 and report gaps to your team before the formal assessment.
Agree in writing which deliverables the partner owns, and confirm that the partner will not sign off on controls it designed.
A Qualified Security Assessor tests the controls and documents the result in the Report on Compliance. The QSA samples key generation records, storage configuration, custodian acknowledgments and dual control logs, then decides whether each sub-requirement is met. Only the QSA's findings count toward validation, and the Attestation of Compliance comes from the QSA's assessment, not from any partner's work.
- Independent testing: The QSA examines evidence and interviews staff rather than relying on documents prepared for the audit.
- Design boundary: A QSA that designed the key lifecycle cannot then assess it, because that would be self-review. Confirm this with the QSA before engaging them.
- Sampling: Expect the assessor to select specific keys, rotations and custodians across the assessment period.
- Reporting: Findings appear in the ROC or the relevant SAQ and the Attestation of Compliance, which only the assessor and the organization submit.
- Scope questions: The QSA confirms which key stores and systems fall inside the cardholder data environment.
Before engaging a QSA, ask how they will separate advisory work from assessment work and whether any firm member helped build the controls.
Organizations often outsource the build and the testing, but keep the decisions. Work that is commonly outsourced includes tool configuration, runbook drafting, log collection and readiness testing. Work that usually stays internal includes policy approval, custodian appointments and rotation decisions. The line between advisory and assessment work matters most: a firm that helps design the controls should not also validate them.
- Common outsourcing: Configuration, documentation drafting, evidence collection and pre-assessment checks.
- Retained work: Policy ownership, custodian selection, approval of cryptoperiods and key retirement.
- Independence line: The assessor must not design the controls it tests. Keep the design partner and the assessor as separate firms where possible.
- Recurring work: Rotations, custodian reviews and evidence capture continue after the assessment, so plan who runs them.
- Quote scope: Ask any provider to list which deliverables are fixed and which recur.
Confirm in writing which party signs each deliverable and where the advisory and assessment work are separated.
Where 3.7 implementations usually fall short
Most 3.7 findings do not come from missing key management tools. They come from keys nobody can list, owners nobody can name, and procedures that exist on paper but leave no trace in the systems. Each card below names one gap, the fix that closes it, and the evidence an assessor will ask to see.
No complete key inventory
Teams often track the keys they remember, while keys inside application configuration, database tooling, backup jobs and older integrations go unlisted. An incomplete inventory makes it impossible to show that every key protecting stored account data is generated, stored, rotated and retired under 3.7. Build the inventory from the systems themselves, including key stores, cloud key services, HSM partitions and application config. Evidence to produce: a dated key register listing each key's purpose, location, algorithm, and the data it protects.
Keys with no named owner
A key without an accountable owner has no one to approve its rotation, respond to its compromise or confirm its retirement. Ownership gaps usually appear after staff changes or when a key was created for a project that has since closed. Assign a named owner and a backup owner to every key in the register, and review ownership whenever roles change. Evidence to produce: the register's owner field completed for every entry, with approval records for ownership changes.
Manual cleartext handling without split knowledge
Where personnel still type, print or move key components in cleartext, one person often holds the complete key. Requirement 3.7.6 calls for split knowledge and dual control in every case where manual cleartext key operations happen. Remove manual handling where an automated key service can do the work, and where manual steps remain, require two custodians who each hold a separate component. Evidence to produce: procedures naming both custodians, and logs showing both participated in each operation.
Custodians without signed acknowledgments
Custodians frequently receive key responsibilities through a ticket or verbal handover and never confirm in writing that they understand them. Requirement 3.7.8 requires each key custodian to formally acknowledge those responsibilities, in writing or electronically. Collect acknowledgments before a custodian receives any key material, and repeat them when duties change. Evidence to produce: a signed or electronically recorded acknowledgment for each custodian, linked to the key register entries they cover.
Rotation that exists only in policy
Many organizations document a rotation interval but never execute it, or rotate on a schedule nobody checks. Requirement 3.7.4 expects keys to change at the end of their defined cryptoperiod, and 3.7.5 covers retiring keys that are weakened or compromised. Set each key's cryptoperiod in the register and automate rotation where the platform supports it. For example, a transit encryption key service can keep versioned keys and rotate them, but the team still has to confirm the rotation ran and that old versions are retired. Evidence to produce: rotation logs with timestamps and the retirement record for each replaced key.
Keys copied into backups and developer machines
Keys often leak into places no one designated for key storage, such as backup archives, shared drives, developer laptops and committed configuration files. Each copy sits outside the controls protecting the original, which undermines secure storage under 3.7.3. Restrict where key material may live, encrypt backups with keys held separately, and scan repositories and pipelines for committed secrets. Evidence to produce: secret scan reports from CI/CD runs and documented backup procedures showing how key material is excluded or separately protected.
No customer guidance from service providers
Service providers that share keys with customers often send no written instructions on how to transmit, store and update them. Requirement 3.7.9 applies to service providers in this position and requires documented guidance on those three activities. Write the guidance as a controlled document, version it, and deliver it to each customer who receives shared keys. Evidence to produce: the current customer guidance document, its version history, and records showing delivery to each affected customer.
Questions buyers ask about 3.7 cost, effort and outside help
How much effort does requirement 3.7 take, and what drives it?
The effort depends mainly on how many keys protect stored account data, how many systems use them, and how much of key handling is manual today. Requirement 3.7 has nine sub-requirements covering key generation, distribution, storage, cryptoperiods, retirement, split knowledge and dual control, substitution prevention, custodian acknowledgment and, for service providers, customer guidance. Each one needs a documented procedure and evidence that people follow it. The largest one-time work is usually inventorying keys and key-encrypting keys and moving manual cleartext operations into controlled procedures. Recurring work includes rotation at defined cryptoperiods, custodian reviews and retaining records for the assessor. Ask any provider to break its quote into inventory, procedure design, technical changes and evidence collection so you can see where the effort sits.
Can a small team handle requirement 3.7 in-house?
A small team can often run 3.7 in-house if it keeps the number of key custodians low and uses a key management system that performs cryptographic operations on the team's behalf. The harder part is the governance: the team must document procedures, keep custodian acknowledgments on file, and run split knowledge and dual control correctly every time a manual operation happens. If manual cleartext key handling is rare, the workload stays small. If it is frequent or spread across many systems, the team needs time for ceremonies and a second person available for every step. Many organizations split the work: internal staff own the keys and the procedures, while an implementation partner prepares the technical setup and evidence. Confirm your own capacity against the procedures before deciding.
How long does the 3.7 work take?
The duration depends on the current state of key management, not on a fixed period. Timing is shaped by how many key stores exist, whether keys are generated and stored in approved forms, how many systems need changes, and whether custodians and approvers are available for the procedures. A well-documented environment with a central key store moves faster than one where keys live in scripts, configuration files and spreadsheets. Assessment timing matters too, because the assessor needs to see the procedures operating over a period, not only on the day they were written. Ask providers for a timeline in the written scope, with milestones tied to inventory, change windows and evidence collection.
What does requirement 3.7 need from our organization?
Requirement 3.7 needs people and time from your organization, which no partner can supply on your behalf. You must name key custodians, confirm each one has accepted their responsibilities in writing or electronically, and give them access to the key stores they manage. Split knowledge and dual control require at least two people for certain manual operations, so those people must be available and trained. You also need scheduled time for key ceremonies, such as generating or replacing a key-encrypting key, and a change window where systems switch to new keys. Finally, someone accountable must own the procedures and keep the records. Before you sign, ask the provider which of these items it expects you to supply and when.
Can a QSA design our requirement 3.7 controls for us?
No. A Qualified Security Assessor evaluates your controls and writes the Report on Compliance, so it must stay independent of the design work. If the same firm designs your key management and then assesses it, the assessment loses its independence. Your organization owns its controls. An implementation partner can prepare systems, procedures and evidence, while the QSA tests the result. Keep these roles separate in your contracts and in your planning. Ask any firm you speak with which role it is offering, and confirm the QSA you use is not also building the controls it will assess.
Can a cloud KMS alone meet requirement 3.7?
A cloud key management service covers some of the storage and generation needs of 3.7, but it does not meet the whole requirement by itself. The service can help with secure key generation and storage, yet you still own the cryptoperiods, the retirement and replacement process, the split knowledge and dual control procedures for any manual operation, the custodian acknowledgments and, for service providers, the customer guidance. Confirm with your assessor how the provider's shared responsibility documentation maps to each sub-requirement, and confirm which key operations the provider performs and which your staff perform. Self-hosted tools such as OpenBao's transit secrets engine can support versioned keys and key rotation, but you must still document and operate the surrounding procedures.
How DeployOpen works on this
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, then prepares the systems, documentation and evidence that support your 3.7 key management lifecycle controls. We do not issue reports or attestations. Your independent QSA assesses the controls and decides whether they meet the requirement.
How we scope
- Agree in writing which key stores, applications and cloud accounts hold keys that protect stored account data.
- Confirm which 3.7 sub-requirements apply to your environment, and which service provider duties under 3.7.9 your organization carries.
- Document the scope, deliverables and timeline before any work starts, so the boundary is clear to your assessor.
How we build
- Configure a self-hosted key management service with versioned keys, rotation settings and access restricted to named custodians.
- Set up split knowledge and dual control for manual cleartext key operations, using your existing identity and approval processes.
- Test key generation, rotation, retirement and replacement in a non-production environment and record the results.
How we hand over
- Deliver key lifecycle procedures, custodian lists and records of custodian acknowledgments for your team to own and maintain.
- Provide configuration exports, access logs and rotation records that show each 3.7 control operating as designed.
- Walk your assessor and internal staff through the evidence map so the QSA can test controls without DeployOpen issuing any opinion.
How we support
- Offer ongoing support, upgrades and continuous testing of key management platforms as a retainer, scoped in writing.
- Review changes to key stores, custodians and cryptoperiods against the documented procedures before they go live.
- Confirm with your QSA and your platform vendors which evidence formats they accept before the assessment window opens.
