What 3.6 asks for and why key protection decides whether encryption holds
If you must prove that stored PAN is protected by encryption, the question an assessor will push on is not whether encryption exists but who can use the keys that unlock it. Requirement 3.6 exists because encrypted card data is only as strong as the keys that protect it. Requirement 3.6.1 asks you to limit key access to the fewest custodians, make each key-encrypting key at least as strong as the data-encrypting keys it protects, store key-encrypting keys separately from the data they protect, and keep keys in the fewest possible locations and forms. Your first task is therefore an inventory: every key that can decrypt stored PAN, who holds it, where copies sit, and which of them are needed at all. A key nobody has listed is a key nobody has protected.
Requirement 3.6.1.2 narrows how secret and private keys may be held. They must be stored at all times in one of three forms: encrypted under a separate key-encrypting key, inside a secure cryptographic device such as a hardware security module, or as at least two full-length key components or shares. Plaintext keys in scripts, environment variables, configuration files, CI/CD variables, cloud console parameters or backup archives fall outside all three forms, and they are the usual reason assessors reject an otherwise sound encryption design. Hard-to-spot copies are the main difficulty: a key used once during a migration may still sit in a shell history file, a snapshot or a developer's workstation. Confirm with your engineering leads which systems ever held the key, not only the systems that use it today.
Requirement 3.6.1.1 applies only if you are a service provider. It asks for a documented cryptographic architecture that lists the algorithms and protocols in use, each key with its strength and expiry, how each key is used, and an inventory of hardware security modules and other secure cryptographic devices. Start this document early, because it is the reference an assessor uses to test everything else in 3.6. Ask your QSA which evidence format they expect, since the standard does not dictate one. Also note that keeping the same keys in production and test is now a required practice rather than optional, so confirm your separation of key material across environments before the assessment begins.
Which keys, systems and third parties fall under 3.6
Requirement 3.6 applies to every cryptographic key that protects stored account data, wherever that key lives and whoever operates it. The cards below separate the key types, the systems that hold them, and the third parties that touch them, so you can decide what sits inside your cardholder data environment and what your assessor will ask you to prove.
Data-encrypting keys for stored PAN
These are the keys that directly encrypt stored primary account number data under Requirement 3.5. Every system that can decrypt PAN depends on them, so they set the baseline for the rest of 3.6. Inventory each key by the datastore or application it protects, including keys used for database columns, file encryption and backup sets. Ask whether any application holds a copy of a data key in memory or in a configuration file, because that copy falls under the same controls.
Key-encrypting keys and their wrapping chain
A key-encrypting key protects other keys, so compromising one can expose everything beneath it. Map each wrapping relationship from the master key down to the data keys, and record where each layer is stored. Confirm that every key-encrypting key is at least as strong as the keys it protects and that it is held separately from them. Gaps often appear when a KEK is kept in the same vault, file or container as the data keys it wraps.
Secret and private keys
Secret and private keys include TLS private keys, API signing keys, service account credentials and keys used to sign or authenticate payment messages. Requirement 3.6.1.2 requires these to be stored only in an encrypted form under a separate key, inside a secure cryptographic device, or as split components. Review build pipelines, container images and developer workstations, since private keys copied there are the most common gap an assessor finds.
Backup, archive and disaster recovery keys
Keys that decrypt backups, snapshots and archived media are in scope even when the production system is not. A recovery copy of a key can be as exposed as the live one, and disaster recovery sites often run with separate key stores. List every backup set that contains PAN, identify the key that protects it, and confirm the recovery key is subject to the same custodian, separation and storage rules as the production key.
HSMs, cloud KMS and key vaults
These are the systems that hold or generate keys: hardware security modules, cloud key management services, and secrets managers. Each one is a component of the cryptographic architecture and should appear in your inventory with its location, owner and the keys it holds. Ask your cloud or hardware provider which controls are theirs and which you configure, and document the split. Application configuration files, environment variables and CI/CD secret stores also hold keys and belong in the same inventory.
Third parties and service provider scope
Requirement 3.6.1.1, which requires a documented cryptographic architecture, applies only to service providers. Merchants and other entities still must meet the other parts of 3.6, but they do not need that architecture document. If you are a service provider, decide whether keys used by a tokenization service or disk encryption product sit inside the CDE, and confirm this with your assessor before you write the architecture. Ask each third party which key custody model it uses and what it will share in evidence.
How a QSA tests key protection and what they ask to see
This table compares how a QSA tests each part of Requirement 3.6 (3.6.1, 3.6.1.1 and 3.6.1.2), the evidence they ask you to produce, and the findings that appear most often. Use it to prepare the evidence folder before fieldwork starts, and to check that each key store and custodian process can be shown, not just described.
| Test area | What the QSA asks to see | Where it usually fails |
|---|---|---|
| Custodian interviews (3.6.1) | Named custodians explain their key duties, how access is granted and how they would handle a key compromise | Staff who hold key material cannot describe their role, or access is shared through a generic account |
| Custodian list and access records (3.6.1) | Current custodian list, approval records, and logs showing who accessed or used each key and when | Custodian list is outdated, includes leavers, or has more people than the business case supports |
| KEK and DEK strength and separation (3.6.1) | Key hierarchy diagram, algorithm and key length for each key-encrypting key and data-encrypting key, and proof the KEK is stored apart from the DEKs it protects | KEK is no stronger than the DEK, or KEK and DEK sit in the same file, database table or configuration store |
| Plaintext key search (3.6.1) | Evidence of scans or reviews of configuration files, scripts, repositories and CI/CD variables for unencrypted keys, plus the review results | Keys or passphrases found in source repositories, container images, cron scripts or environment files |
| Key storage forms (3.6.1.2) | Documented storage method for each secret or private key: encrypted under a separate KEK, held in an HSM, or split into at least two full-length components | Keys stored encrypted under a key kept beside them, or split components held by the same person |
| HSM and secure device inventory (3.6.1.1, service providers) | Inventory listing each HSM or secure cryptographic device, its location, owner, firmware status and the keys it holds | Inventory missing devices, cloud KMS keys not recorded, or no link between the device and the keys it protects |
| Cryptographic architecture document (3.6.1.1, service providers) | Document covering algorithms, protocols, keys, key strength, expiry dates, key usage and the relationships between keys | Document describes the intended design but not the running system, or expiry dates are missing |
| Production and test key separation (3.6.1.1, required since 31 March 2025) | Separate key sets for production and test, key usage records showing no production key used in test, and controls that block the reuse | Production keys copied into staging or developer environments for convenience, with no record of the copy |
Implementing key protection in order: inventory, custodians, storage, architecture
This sequence moves an organization from an unknown key estate to a documented, restricted and separately stored key hierarchy, with each step producing an artifact an assessor can test.
Inventory every cryptographic key and its location
Start by listing every key that protects stored account data: data-encrypting keys, key-encrypting keys, secret and private keys, and keys held in applications, databases, backups, file stores and cloud key services. For each key, record its purpose, the data it protects, the system or device where it lives, and the form it takes. Scattered copies found during this work are often the most important results. The output is a key inventory that every later step refers to. It is complete when a system owner can confirm that no key protecting stored account data sits outside the list.
Restrict key access to the fewest custodians
Using the inventory, identify who can currently read, use or export each key, then reduce that group to the smallest number of named custodians the business can operate with. Requirement 3.6.1 expects key access to be limited in this way, so each custodian should have a documented role and a reason for access. Custodians are people, not shared accounts, and their names belong in a custodian register that records the keys each person may handle. The register is complete when every key in the inventory maps to a short, justified list of custodians and the register has been reviewed by the people who own the keys.
Design the key-encrypting key hierarchy
Define which keys wrap which. Each data-encrypting key that protects stored account data should be encrypted by a key-encrypting key, and each key-encrypting key must be at least as strong as the keys it protects. Store key-encrypting keys separately from the data and the keys they protect, so that compromise of one storage location does not expose everything. Keep the number of locations and forms as small as the architecture allows. The output is a storage design diagram showing the hierarchy, the strength of each level, and where each key is held. It is complete when a security engineer can trace any data-encrypting key to its wrapping key and to the storage location of that wrapping key.
Move secret and private keys into an approved form
Requirement 3.6.1.2 accepts three approved forms for secret and private keys: encrypted under a separate key-encrypting key, held inside a secure cryptographic device such as a hardware security module, or split into at least two full-length key components or shares. Pick the form for each key, migrate keys out of configuration files, source repositories and plain-text environment variables, and remove any unapproved copies. Open-source secret stores and transit encryption services can support the encrypted-under-KEK or service-held approaches, but the organization must confirm that each product's key handling meets the requirement in its own environment. The output is a migration record that maps each key to its approved form and the date of its move. The step is complete when scans of code, pipelines and configuration find no clear-text secret or private key.
Separate production and test keys
Confirm that no key used in production is also used in test, development or staging, and that test environments generate their own keys. This bullet was a best practice until 31 March 2025 and is now required, so it is a common gap in older environments where a test database was seeded from a production backup along with its keys. Check backup restores, cloned virtual machines, CI/CD variables and developer workstations. The output is a short attestation by the key owners together with a list of the environments checked and any key rotations completed. It is complete when every environment has a documented key source and no key appears in more than one of them.
Write the cryptographic architecture for service providers
If the organization is a service provider, Requirement 3.6.1.1 requires a documented cryptographic architecture. This document lists the algorithms and protocols in use, each key with its strength and expiry, how each key is used, and an inventory of hardware security modules and other secure cryptographic devices. Build it from the key inventory and storage design already produced, so that every entry can be traced to a system. Review it with the custodians and the people who operate the devices. Non-service providers can still benefit from the same document, but the requirement itself applies to service providers. The output is a versioned architecture document with an owner and a review date. It is complete when it matches the live environment, which an assessor will check by sampling keys and devices.
How a key-encrypting key hierarchy keeps data keys protected
Requirement 3.6 turns on a simple idea: a data-encrypting key (DEK) is the key that actually encrypts stored account data, and a key-encrypting key (KEK) is the key that protects the DEKs. Whoever holds a DEK in clear form can read the PAN it protects, so DEKs are rarely stored in plain text. Instead, each DEK is wrapped (encrypted) under a KEK, and the wrapped copy is what sits next to the data. The KEK must be at least as strong as the DEKs it protects, because a weaker outer layer makes the inner layer irrelevant. When you review your architecture, check the algorithm and key length of each KEK against every DEK it wraps, and record that comparison. Keeping KEKs separate from DEKs also limits blast radius: compromise of a data key exposes one data set, while the KEK sits in a different location with different custodians.
Requirement 3.6.1.2 names three approved ways to store secret and private keys, and each one trades convenience against control. The first is wrapping under a separate KEK, which is flexible and works in software, but it moves the problem up one level: the KEK still needs a safe home. The second is storing keys inside a secure cryptographic device such as a hardware security module (HSM), where key material stays inside tamper-resistant hardware and operations happen inside the device. This gives the strongest custody guarantees but adds purchase, hosting, licensing and operational skills to your budget. The third is splitting a key into at least two full-length components or shares, so no single custodian can reconstruct it. This suits rarely used master keys and supports dual control, but it creates recovery risk if shares are lost and demands careful custodian management. Most mature environments combine them, for example an HSM-protected root KEK that wraps working KEKs and DEKs. Confirm with your QSA which combinations your environment's documentation can support.
Evidence that passes 3.6 and how to keep it current
Requirement 3.6 is judged on records as much as on configuration. Assessors look for a current picture of every key, who can touch it, how it is stored and how it changes over time. The cards below describe each artifact an assessor is likely to ask for and the routine that keeps it accurate between assessments.
Key inventory
A register of every cryptographic key that protects stored account data, with its purpose, the data it covers, the system holding it, its algorithm and its current state. Assessors use it to confirm that no key sits outside the documented set. Keep it current by tying new key creation and retirement to the change process, so the inventory cannot drift from the live key store. Check it against the key management system's own listing at least once a quarter.
Custodian list with access logs
The named people or service roles allowed to handle key material, with the scope of each person's access and the logs that show what they actually did. Requirement 3.6.1 expects access limited to the fewest custodians possible, so the list should be short and justified. Review it whenever someone changes role or leaves, and reconcile the list against access logs to catch any custodian who has used a key outside their assigned duties.
KEK and DEK strength records
Records showing the algorithm and key length of each key-encrypting key and the data-encrypting keys it protects, with evidence that each KEK is at least as strong as the keys beneath it. Assessors check this comparison directly, so a mismatch after an algorithm upgrade is a common finding. Record strength at the time each key is created and re-verify it whenever an algorithm or key length is changed.
Storage form documentation
A description of how each secret or private key is held at all times: encrypted under a separate key-encrypting key, inside a secure cryptographic device, or as split components. Requirement 3.6.1.2 allows only these forms, so any key in plain text, in a configuration file or in a script is a failure. Keep the document aligned with actual deployments by checking storage forms during each change review and during periodic configuration scans.
HSM and secure device inventory
A list of every hardware security module and other secure cryptographic device, with make, model, location, firmware level, owner and the keys each device holds. This inventory is required for service providers under Requirement 3.6.1.1 and is the first thing an assessor compares against the architecture document. Confirm device status with the vendor's management tooling and update the list whenever hardware is added, moved, replaced or decommissioned.
Cryptographic architecture document
For service providers, a written description of the algorithms, protocols, keys, key strength, expiry dates, key usage and cryptographic devices in use. Requirement 3.6.1.1 applies only to service providers, but the same document helps any organization explain its design. Treat it as a controlled document with an owner and a review date, and update it through the change process whenever a key use or algorithm changes.
Production and test key separation
Evidence that keys used in production are never used in test, development or staging environments. Requirement 3.6.1.1 makes this separation mandatory now, having been a best practice until 31 March 2025. Show it with separate key stores or namespaces per environment, access reviews that confirm no test account can reach production key material, and a periodic check that compares key identifiers across environments.
Rotation and change records
Logs of key generation, rotation, replacement and retirement, each linked to a change ticket or an approval. Assessors look for proof that keys are replaced on the schedule the organization set and that compromised or departed-custodian keys were handled promptly. Keep rotation records automatic where the key management system allows it, and review a sample each quarter to confirm that every rotation has an approval and a matching inventory update.
What meeting 3.6 costs in money and effort
This table breaks down the money and effort behind Requirement 3.6 into cost components, showing who is paid, whether each cost is one-time or recurring, and what drives it up or down. Use it to build a quote request, not as a price estimate, because no supplied figures exist for these costs. The main takeaway is that licensed key management software and HSM hardware are only part of the spend, while documentation, custodian time and assessor sampling recur every cycle.
| Cost component | Who is paid or who spends effort | One-time or recurring | What drives it |
|---|---|---|---|
| HSM or cloud KMS fees | Hardware vendor, or cloud provider for managed key services | HSM purchase or setup is one-time; KMS usage and HSM support are recurring | Number of key hierarchies, key operations per second, HSM count for high availability, and whether keys stay in your facility or a cloud region |
| Key management software licenses | Commercial key management vendor | Usually recurring | Number of keys, tenants, environments and integrations. Open-source options such as OpenBao can remove this license line, but they still need hosting and operations time |
| Engineering time to migrate and document keys | Internal engineers or an implementation partner under a written scope | One-time for migration; documentation updates recur as keys change | Number of systems holding keys, age of current key storage, and whether keys in test and production are already separated |
| Custodian time | Internal staff named as key custodians | Recurring | Number of custodians (fewer is better under 3.6.1), dual-control procedures, and key ceremonies needed for rotation or recovery |
| Evidence upkeep | Internal compliance and security staff | Recurring | Frequency of key rotation, number of key inventories, HSM device inventories and cryptographic architecture updates required for service providers under 3.6.1.1 |
| External review or penetration testing of key handling | Independent testing firm, scoped in writing | Recurring, usually tied to the testing cycle | Scope of key storage, transit and application key use, and whether testers examine HSM configuration and key access paths |
| QSA sampling time | Qualified Security Assessor (fees set by the assessor's engagement) | Recurring with each assessment | Number of key stores and key types sampled, quality of evidence on hand, and whether the architecture is documented before the assessment starts |
Which open-source tools produce key protection evidence
OpenBao is an open-source fork of Vault licensed under MPL-2.0. Its transit secrets engine is the component most relevant to Requirement 3.6 because it lets applications encrypt and decrypt data while the key material stays inside the engine. The engine performs cryptographic operations on data that the application sends in, and it does not store that data. For key protection, this supports a model where data-encrypting keys are held centrally and applications never handle raw key material.
- Keys stay in the engine: applications send plaintext in and receive ciphertext back, so key material is not distributed to application hosts.
- Versioned keys: the engine supports versioned encryption keys and key rotation, which produces a record of which key version protected which data.
- Signing and verification: the engine can also sign and verify data, which can support integrity evidence for sensitive records.
- Access policy: access to the engine is controlled through its policy and authentication settings, which must be documented and reviewed as part of the key custodian model.
- Not a complete key store: the transit engine does not, by itself, produce the cryptographic architecture inventory that service providers must maintain under the service provider requirement.
Before relying on OpenBao, confirm with your assessor how the transit engine's root and unseal material is split and held, and whether the deployment meets the requirement for keys stored in a secure cryptographic device or encrypted under a separate key-encrypting key.
Nextcloud is licensed under AGPL-3.0-only and offers server-side encryption for files stored on local and external storage. Its encryption protects file contents at rest, and the keys are kept on the server. This is useful evidence for stored files that contain account data, but it is not a general answer to key protection. Because the keys sit on the same server as the encrypted content, the arrangement depends heavily on how the server and its key material are administered.
- File contents encrypted at rest: the server-side mode protects file bodies on local and external storage.
- Server-held keys: the keys live on the server, so access to the server and its key store must be restricted to named custodians.
- Metadata not encrypted: file names and folder structure are not encrypted, so any account data present in names or paths is not protected by this feature.
- Configuration evidence: the enablement settings, key handling procedures and any recovery arrangements can be captured as configuration evidence for an assessor.
- Separation from data keys: the server-side model does not by itself show a key-encrypting key stored separately from the data keys, so that design needs its own documentation.
Confirm that Nextcloud is not the storage location for any stored PAN or sensitive data without a further protection method, and check the current encryption configuration documentation against your version before recording it as evidence.
GitLab Community Edition is licensed under MIT, and its pipeline secret detection runs as a CI/CD job that scans files committed and pushed to the repository. It writes detected secrets to a gl-secret-detection-report.json job artifact, available in every tier. This addresses a different part of Requirement 3.6: keys sitting in source code or configuration where they should never be stored. It does not manage keys, so it works as a control that supports key protection rather than as a key store.
- Pipeline scanning: the job runs on committed and pushed files, which gives a repeatable check on each change.
- Artifact evidence: the gl-secret-detection-report.json artifact records what the job found for each pipeline run, which an assessor can sample.
- Detection limits: the scan finds patterns it recognizes, so keys with unusual formats or keys entered outside the repository may be missed.
- History and remediation: the report shows detections, but the team still needs a documented process to rotate exposed keys and record the rotation.
- Scope of coverage: the job covers repositories that run the pipeline, so repositories and branches outside it need their own review.
Confirm that the job runs on every repository that holds configuration in scope, that findings are triaged with recorded owners, and that the team can show a key was rotated after a detection.
Where key management usually fails the assessment
Most key management findings under Requirement 3.6 trace back to a few habits: keys handled outside controlled storage, too many people with access, and copies that exist outside the documented design. Each card below names one gap, why an assessor flags it, and the check to run before the assessment starts.
Keys in scripts and configuration files
Encryption keys hard-coded in deployment scripts, application config files or container images are the most frequent failure an assessor finds in this area. Anyone who can read the repository or image can read the key, and the key often outlives the code that uses it. Search repositories, CI/CD variables, Helm charts and image layers for key material. Then move each key into a dedicated key store and rotate any key that was exposed. Secret scanning in the pipeline helps catch new cases.
Too many key custodians
Requirement 3.6.1 expects access to keys to be limited to the fewest custodians needed. Assessors look for shared administrator accounts, former employees who still hold key shares, and keys that a whole engineering group can export. Pull the list of every person and service identity that can read, export or unwrap each key, and compare it with the named custodians in your key management procedure. Remove anyone whose role does not require access, and record the reason for each retained custodian.
No separation of key-encrypting keys
A key-encrypting key protects the data-encrypting keys beneath it, so it must be at least as strong as them and stored separately. Failures appear when the same key encrypts both the data and the keys that protect the data, or when the key-encrypting key sits in the same database, file share or container as the data it protects. Map each data-encrypting key to the key that wraps it, confirm the algorithm strength of both, and confirm they are held in different locations with different access paths.
Production keys reused in test
The requirement that prevents the same keys being used in production and test became mandatory on 31 March 2025, having been a best practice before that date. Assessors check whether test databases, staging environments and developer laptops decrypt data with production keys. Confirm that each environment has its own key hierarchy, that restored backups are not decrypted into test with production keys, and that the key inventory names the environment each key serves.
Missing HSM and device inventory
Where keys are stored in a hardware security module or another secure cryptographic device, the assessor expects a current inventory of those devices and their locations. Gaps appear when HSMs are added for a project and never recorded, when cloud key services are used without a list of the key stores, or when devices are reassigned without an update. Build the inventory from the infrastructure side, not from the procurement list, and reconcile it with the key register each quarter.
Undocumented architecture for service providers
Service providers must maintain a documented cryptographic architecture that covers algorithms, protocols, keys, key strength, expiry, key usage and secure device inventories. Many providers have the controls but no single document that ties them together, so the assessor cannot trace a key from creation to use. Write the architecture as a living document owned by a named role, and check that it matches the running system before the assessor asks for it.
Backup copies in unprotected locations
Backups of key material, including exported key shares, database snapshots that include wrapped keys and copies on removable media, often sit outside the controls applied to the live key store. An assessor who finds a readable key in a backup bucket or a sealed envelope in an unlocked cabinet will treat the whole key process as weak. List every backup location for keys and wrapped keys, apply the same custodian, storage and access rules as the primary store, and test a restore under documented dual control.
Questions buyers ask about 3.6 cost, effort and outside help
How much effort does requirement 3.6 take to meet?
Effort depends mainly on how many keys exist, where they are stored today and whether the environment already uses a managed key store. Requirement 3.6 is not a single task: it asks for documented key protection procedures, a restricted custodian list, correctly layered key-encrypting keys and approved storage forms. Most of the work is inventorying keys, mapping where each one lives and deciding which ones need to move. The cost is largely internal staff time plus any platform work to replace ad hoc key handling. Ask any partner to quote against a written list of key stores, applications and environments in scope, and to state which deliverables are one-time and which recur, such as quarterly custodian reviews.
Can an in-house team meet requirement 3.6 without outside help?
Yes, an in-house team can meet requirement 3.6 if it has people who understand key management, access control and cryptographic design. The organization owns its controls, so internal staff can write the procedures, restrict custodians and configure the storage forms. Outside help is most useful when the team lacks cryptography depth, when keys are spread across many systems, or when a service provider must produce a documented cryptographic architecture. Whatever you choose, the assessor will test the evidence, so confirm early with your Qualified Security Assessor (QSA) which records they expect to see.
Does requirement 3.6 require a hardware security module?
No. Requirement 3.6.1.2 allows secret and private keys to be stored encrypted under a separate key-encrypting key, inside a secure cryptographic device such as an HSM, or as at least two full-length key components or shares. An HSM is one accepted option, not a mandatory one. Choose the form that fits your architecture and key volume, document why, and confirm with your QSA that the approach meets the requirement as written. A cloud or open-source key manager can support one of the permitted forms, but confirm that its design matches the storage options before relying on it.
What does a partner need from our team to start?
A partner needs access to the people and systems that handle keys before it can prepare anything. Typically this includes a current list of systems that store or use keys, the names of staff who hold key custodian roles today, network and data-flow diagrams, existing key management procedures and the environments in scope for the assessment. The partner also needs decision-makers to confirm the storage forms the organization will use and who will approve custodian assignments. Ask for this list in writing as part of the scope. Missing inputs are the most common reason fixed-scope work slips, so agree on who supplies each item and by when.
How long does preparation for requirement 3.6 usually take?
Preparation length depends on the number of key stores, the amount of undocumented key handling and how quickly decisions are made about storage forms and custodians. No general duration can be stated for this requirement from the sources used here, so ask any partner for a timeline built from a written scope, with milestones for the inventory, the procedures, the implementation changes and the evidence collection. Also ask the QSA to confirm which evidence period they will review, because procedures that have run only briefly may not show the sustained operation an assessor expects.
Can the QSA who assesses us also implement the fix?
No, not without compromising the assessment. The QSA issues the Report on Compliance and must remain independent of the work it evaluates. Preparing systems, writing procedures and configuring key storage is implementation work, which an internal team or an implementation partner can do. Keep those roles separate, and check your assessor's independence rules before you engage anyone. DeployOpen prepares systems, controls and evidence for assessments, but it does not issue audit reports, attestations or certifications, which only an independent assessor can do.
What recurring costs follow once requirement 3.6 is in place?
The recurring costs are the ongoing operation of the controls: rotating custodians when staff change, reviewing access to key-encrypting keys, maintaining the cryptographic architecture for service providers, keeping the HSM or key manager inventory current and collecting evidence for each assessment cycle. These tasks usually cost more in internal time than in tooling. Ask any partner to separate one-time implementation fees from any retainer for support, upgrades or periodic review, and confirm which activities the retainer covers.
How DeployOpen prepares key protection evidence for 3.6
DeployOpen prepares the evidence for Requirement 3.6 but does not issue it. Before any work starts, we agree a fixed scope in writing that lists every key store, key hierarchy and cryptographic service that protects stored account data, including the keys held by backup jobs, file encryption and application-level encryption. The first deliverable is a key inventory that names each key by purpose, the systems that hold it, and the people or roles that can use it. Most gaps assessors find under 3.6.1 start here, because a key nobody listed cannot be shown to meet the custodian, storage and separation rules. Clients should ask for this inventory as a separate, signed deliverable so it can be checked against the scope before implementation begins.
On the build side, we implement self-hosted key platforms inside your own cloud accounts, data centers or air-gapped networks. For many environments this means a secrets and encryption service such as OpenBao, whose transit secrets engine encrypts application data without storing it and supports versioned keys with rotation, so the key-encrypting key stays in one controlled service rather than in application configuration. We configure access so that key administration is split across named custodians, set up storage so that key-encrypting keys sit apart from the data keys they protect, and confirm where secret and private keys are held in encrypted form, in a hardware security module, or as split components. For service providers, we also compile the cryptographic architecture record that Requirement 3.6.1.1 expects, including algorithms, key strength, expiry, usage and the inventory of secure cryptographic devices. Confirm with your QSA which approach the assessor will accept for each key store before you build it.
The custodian records and architecture documents are the parts assessors read most closely, so we prepare them as working records rather than templates. That covers custodian acknowledgments, access logs from the key platform, change records for key rotation and the procedures for storing and separating keys. Once the evidence is in place, we hand it to your Qualified Security Assessor, who decides whether it meets the requirement. DeployOpen does not issue Reports on Compliance, Attestations of Compliance or any other validation, and a certificate from us does not count as validation under PCI SSC rules. Your organization owns the controls and the assessment decision. Ask any implementation partner to state this in the written agreement before they touch your key infrastructure.
