Additional Key Protection for Service Providers

PCI DSS v4.0.1 Requirement 3.6.1.1 requires service providers to maintain a documented cryptographic architecture for stored account data that fully describes algorithms, protocols, and every key involved, including key strength, expiry, intended use, and an inventory of HSMs and key-management systems. Operationalize it by building and maintaining a living “crypto architecture pack” tied to systems, data stores, and key lifecycle records. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Key takeaways:

• You must document the full cryptographic picture, not just “we encrypt PAN at rest.” (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Examiners will expect traceability from stored account data locations to specific keys, key usage, and key custody systems (HSM/KMS). (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Treat this as a controlled, versioned architecture artifact with change management, ownership, and evidence-ready exports. (PCI DSS v4.0.1 Requirement 3.6.1.1)

This requirement exists because service providers often run multi-tenant, highly distributed environments where encryption can sprawl across databases, object storage, backups, logs, and analytics pipelines. A generic statement like “data is encrypted using AES” does not let an assessor confirm that every storage location is protected correctly, that keys are appropriate for their purpose, or that key-management devices are governed and inventoried.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to treat PCI DSS 3.6.1.1 as a documentation-and-traceability control. Your goal is a single, maintained description of your cryptographic architecture that can answer, on demand: where stored account data exists, what encryption and protocols protect it, which keys are used, what each key is allowed to do, when it expires, and which HSMs/KMS/secure devices manage those keys. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Done well, this becomes a reusable operational asset: it reduces firefights during assessments, speeds incident response, and makes key rotations and migrations safer because the blast radius is explicit rather than assumed.

Regulatory text

Requirement (service providers only): Maintain a documented description of the cryptographic architecture that includes details of all algorithms, protocols, and keys used to protect stored account data, including key strength and expiry date; description of key usage for each key; and an inventory of any HSMs, key management systems, and other secure cryptographic devices used for key management. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Operator translation (what you must do):

1. Produce a written, maintained cryptographic architecture description covering stored account data environments in scope. (PCI DSS v4.0.1 Requirement 3.6.1.1)
2. For each protection mechanism, list the algorithms and protocols actually in use (not aspirational standards). (PCI DSS v4.0.1 Requirement 3.6.1.1)
3. Create an inventory of all cryptographic keys that protect stored account data, including key strength, expiry date, and key usage per key. (PCI DSS v4.0.1 Requirement 3.6.1.1)
4. Maintain an inventory of HSMs, KMSs, and other secure cryptographic devices used for key management. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Plain-English interpretation (what auditors are trying to confirm)

Assessors want evidence that encryption is intentionally designed and governed, not scattered settings across teams. The documentation should let an independent reviewer:

• Identify every place stored account data sits (including replicas and backups) and confirm it is protected.
• See which exact keys protect which data stores, and what each key is permitted to do (encrypt/decrypt, wrap/unwrap, sign/verify).
• Validate key lifecycle hygiene (strength and expiry are recorded; rotation and decommissioning are manageable).
• Verify that key custody is anchored in managed systems (HSM/KMS/secure devices) and that those systems are inventoried for oversight.

Who it applies to

In-scope entities

• Service providers under PCI DSS, including payment processors and any organization providing services that store, process, or transmit account data on behalf of other entities. This is explicitly an “additional requirement for service providers only.” (PCI DSS v4.0.1 Requirement 3.6.1.1)

In-scope operational context

• Any environment where you store account data (primary databases, data warehouses, object storage, backup media, archival systems, file shares, log pipelines if they contain stored account data, etc.).
• Any key-management footprint tied to those environments (cloud KMS, HSM partitions, on-prem HSM appliances, certificate/key stores, “secure crypto devices” involved in key custody). (PCI DSS v4.0.1 Requirement 3.6.1.1)

What you actually need to do (step-by-step)

Step 1: Name an owner and define the “crypto architecture pack”

Assign a single accountable owner (often Security Architecture or Platform Security) and define a controlled artifact set:

• Cryptographic Architecture Description (narrative + diagrams)
• Key Inventory (table)
• HSM/KMS/Secure Device Inventory (table)
• Mapping between stored account data locations and the keys/devices that protect them

Treat these as versioned documents with change control.

Step 2: Enumerate stored account data locations (the scoping spine)

Build a list of every system/component that stores account data. Practical approach:

• Start with your data flow diagrams and storage catalog.
• Confirm with engineering where copies exist: read replicas, ETL landing zones, backups, DR, support exports.
• For each location, record: system name, environment, storage type, and owner team.

Output: a “Stored Account Data Storage Register” that becomes the backbone for mapping crypto controls.

Step 3: Document algorithms and protocols actually in use

For each storage location and data path relevant to stored account data:

• Record encryption at rest algorithm details (what is configured, where, and at what layer).
• Record protocols for any crypto-relevant channels tied to protection of stored account data (for example, service-to-KMS calls, database connections where crypto is negotiated). Keep it factual: configuration sources, IaC modules, KMS policy references, or platform settings.

Step 4: Build the key inventory with required fields

Create a key inventory that includes, at minimum, for each key that protects stored account data:

• Key identifier (KMS key ID / alias / HSM label)
• Where it lives (which KMS/HSM/secure device)
• Key strength
• Expiry date
• Key usage description (what the key can do and what data/system it is tied to)
• Systems/data stores protected by the key
  This maps directly to the requirement language. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Practical advice: include “wrapper vs. data-encryption key” role and whether the key is customer-dedicated or shared, because assessors commonly ask.

Step 5: Inventory HSMs, KMS, and other secure cryptographic devices

Maintain a separate inventory of key-management components:

• Device/service name (for example, cloud KMS tenant, HSM cluster name)
• Environment and region/location
• Ownership (team)
• What keys it hosts (link to key inventory)
• Administrative access model (who can administer, how controlled) This is explicitly required. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Step 6: Produce architecture diagrams that auditors can follow

You want diagrams that answer: “Where is encryption applied, and where are keys managed?” Include:

• Data stores (where stored account data resides)
• Key-management systems (KMS/HSM)
• Key flows (request/issue/unwrap operations at a high level)
• Trust boundaries (production vs. non-production, tenant boundaries)

Step 7: Make it maintainable (change triggers and workflow)

Define update triggers so the documentation stays current:

• New system storing account data
• New key created, rotated, revoked, or retired
• Migration between HSM/KMS platforms
• Algorithm/protocol changes
• Environment expansion (new region, new tenant model)

In practice, connect this to engineering change management. If you can’t gate changes, at least require a “crypto architecture update” task in the release checklist for in-scope systems.

Step 8: Evidence readiness (export and freeze)

Before assessments, generate an evidence snapshot:

• Export of key inventory with last-updated timestamp
• Export of HSM/KMS inventory
• Architecture description and diagrams
• Sample configuration evidence showing algorithms/protocols and key references

If you use Daydream to run third-party and internal control evidence collection, treat this requirement like a recurring evidence request: keep the architecture pack as a standing artifact and refresh it through a lightweight workflow rather than rebuilding it during audit season.

Required evidence and artifacts to retain

Maintain these artifacts in a controlled repository (GRC system or secured document store) with version history:

• Cryptographic architecture description (narrative)
• Architecture diagrams showing systems, stored account data locations, and key-management components
• Key inventory including key strength, expiry date, and key usage per key (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Inventory of HSMs, KMSs, and other secure cryptographic devices used for key management (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Evidence backing the documentation (config snippets, KMS/HSM exports, screenshots, IaC references, CMDB entries)
• Change log showing updates when crypto-relevant changes occurred

Common exam/audit questions and hangups

Expect questions like:

• “Show me all keys that protect stored account data and where each is used.” (PCI DSS v4.0.1 Requirement 3.6.1.1)
• “Which keys are allowed to decrypt, and who/what can call decrypt?” (ties to key usage) (PCI DSS v4.0.1 Requirement 3.6.1.1)
• “How do you know this inventory is complete and current?”
• “Which HSM/KMS components manage these keys, and are they all inventoried?” (PCI DSS v4.0.1 Requirement 3.6.1.1)
• “Where is the expiry date recorded, and what happens before expiry?” (PCI DSS v4.0.1 Requirement 3.6.1.1)

Hangups that slow teams down:

• Multiple KMSs across cloud accounts/projects with inconsistent naming.
• Keys created by managed services (databases, storage) that teams forget to record.
• Confusion between certificates (TLS) and keys for stored data; this requirement is centered on protection of stored account data, but still asks for protocols and keys used for that protection. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Frequent implementation mistakes (and how to avoid them)

1. Documenting “standards” instead of reality.
   Fix: pull configurations from KMS/HSM consoles, IaC, and service settings; cite where each item is configured.

2. No mapping from keys to data stores.
   Fix: add a mandatory “Protected systems/data stores” column in the key inventory and make it non-optional.

3. Missing expiry dates because the platform rotates automatically.
   Fix: record the platform’s expiry/rotation settings or the key’s expiration metadata, and still include an “expiry date” field populated per key. (PCI DSS v4.0.1 Requirement 3.6.1.1)

4. Ignoring “secure cryptographic devices” outside the main KMS.
   Fix: include payment HSMs, dedicated key appliances, or any managed crypto boundary that participates in key management. (PCI DSS v4.0.1 Requirement 3.6.1.1)

5. Treating the document as a one-time deliverable.
   Fix: add change triggers and assign an owner; tie updates to deployment workflows for in-scope services.

Enforcement context and risk implications

No public enforcement cases were provided for this requirement in the supplied sources. Practically, the risk is assessment failure or compensating-control sprawl: if you cannot prove which keys protect which stored account data, you may be forced into disruptive evidence hunts, emergency inventories, and last-minute remediation work that increases operational error risk.

Practical 30/60/90-day execution plan

First 30 days (establish the pack and get to “audit-readable”)

• Assign ownership and repository location for the crypto architecture pack.
• Build the initial storage register for stored account data.
• Export an initial list of keys from each KMS/HSM and draft the key inventory with required columns. (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Draft the first version of the cryptographic architecture narrative and one end-to-end diagram per major platform.

Days 31–60 (close completeness gaps and add traceability)

• Reconcile gaps: find unmanaged or “mystery” keys; resolve ownership.
• Map each stored account data location to the protecting key(s).
• Create/validate the HSM/KMS/secure device inventory and link devices to hosted keys. (PCI DSS v4.0.1 Requirement 3.6.1.1)
• Add a simple change log and define update triggers tied to engineering change management.

Days 61–90 (operationalize and evidence-automate)

• Implement a recurring review workflow (quarterly is common as an internal practice; choose a cadence that matches your change rate) and document it internally.
• Build an “assessment export” package format (PDF + CSV exports + diagrams) so you can produce evidence quickly.
• If you use Daydream, configure recurring evidence tasks for key inventory exports, KMS/HSM inventory updates, and architecture version attestations, so the documentation stays current without a scramble.

Frequently Asked Questions

Does this apply to merchants, or only service providers?

Requirement 3.6.1.1 is an additional requirement for service providers only. Merchants still have related cryptography and key-management requirements elsewhere in PCI DSS, but this specific documentation requirement is scoped to service providers. (PCI DSS v4.0.1 Requirement 3.6.1.1)

What counts as a “cryptographic architecture” document?

A practical cryptographic architecture description includes diagrams plus a written explanation that identifies algorithms, protocols, and every key used to protect stored account data, with key strength, expiry date, key usage, and the HSM/KMS inventory. (PCI DSS v4.0.1 Requirement 3.6.1.1)

We use cloud-managed encryption (KMS-integrated services). Do we still need a key inventory?

Yes. You still need an inventory of the keys protecting stored account data and the KMS components managing them, even if the underlying encryption is managed by a cloud service. (PCI DSS v4.0.1 Requirement 3.6.1.1)

How detailed should “key usage” be?

Make it specific enough that an assessor can distinguish what the key can do and what it is allowed to protect (for example: “encrypt/decrypt for PAN data store X” vs. “wrap/unwrap DEKs for service Y”). The requirement explicitly calls for a description of key usage for each key. (PCI DSS v4.0.1 Requirement 3.6.1.1)

Do we need to include every TLS certificate and mTLS key?

Focus on keys used for the protection of stored account data as stated in the requirement, and document the relevant protocols in that protection architecture. If TLS keys are part of the defined protection of stored account data in your environment, include them and clearly scope their role. (PCI DSS v4.0.1 Requirement 3.6.1.1)

What’s the minimum evidence an assessor will accept?

Provide the maintained architecture description, a complete key inventory with strength/expiry/usage, and an inventory of HSMs/KMS/secure crypto devices, plus configuration-backed evidence that the documentation reflects reality. (PCI DSS v4.0.1 Requirement 3.6.1.1)