Split Knowledge and Dual Control

PCI DSS 4.0.1 Requirement 3.7.6 means that if people ever handle cryptographic keys in manual cleartext during key-management activities, you must run those activities with split knowledge and dual control so no single person can access or recreate the full key alone. You operationalize it by designing a two-person process, restricting what each person can see/do, and retaining evidence.

Key takeaways:

• This requirement triggers only when personnel perform manual cleartext key-management operations. Document whether you do, and where.
• Enforce two-person control plus separation of key components/knowledge for those operations, with tightly scoped access and logging.
• Auditors will look for proof: procedures, role assignments, access controls, and execution records for each key ceremony.

“Split knowledge and dual control” is a specific control pattern used to prevent insider misuse, mistakes, or coercion during sensitive cryptographic key operations. PCI DSS focuses it narrowly: it applies where personnel perform manual cleartext cryptographic key-management operations (for example, during a key ceremony where key components are handled, transported, entered, or stored in human-readable form). In those situations, policy alone is not enough. You need operational procedures that force at least two authorized people to participate and ensure neither person can reconstruct the complete key alone.

For a Compliance Officer, CCO, or GRC lead, the fastest path is to (1) determine whether any manual cleartext operations exist in your environment, including at third parties, (2) define the “key-management operations” in scope, (3) implement a two-person workflow with segregated key components, and (4) collect repeatable evidence each time the process runs. Most findings happen because teams say “we use an HSM so this doesn’t apply,” but still have a break-glass, migration, backup/restore, or legacy process where humans touch cleartext key material.

Regulatory text

PCI DSS 4.0.1 Requirement 3.7.6: “Where manual cleartext cryptographic key-management operations are performed by personnel, key-management policies and procedures are implemented to include split knowledge and dual control of keys.” (PCI DSS v4.0.1 Requirement 3.7.6)

Operator interpretation:
If a person can ever see, handle, type, print, read, copy, or transport cryptographic key material in cleartext as part of a key-management task, your written key-management procedures must require:

1. Dual control: at least two authorized people participate, with each person performing required steps.
2. Split knowledge: the key (or the knowledge needed to reconstruct it) is divided so no single person has the complete key.

This is a “design the process so abuse is hard” requirement. A policy statement without a two-person workflow, access restrictions, and execution records will not hold up in an assessment.

What “split knowledge” and “dual control” mean in practice

Split knowledge (what to enforce)

Split knowledge means you structure key handling so each person has only a component or partial knowledge. Common, practical implementations include:

• Key components (parts) held separately: two (or more) components must be combined to form the operational key.
• Separate credentials for key component access: one person can retrieve component A, another retrieves component B, and neither can access the other component.
• Separated key-injection/entry steps: one person enters one component; the second person enters the other component; the system combines them.

Your goal: any single individual acting alone cannot reconstruct the complete key.

Dual control (what to enforce)

Dual control means key-management tasks require two people, both authorized, each performing parts of the operation. It is not “two people are aware.” It is “two people are required for completion,” ideally enforced by workflow, access control, or system permissions.

Examples of dual control in real operations:

• Two-person approval and participation for a key rotation ceremony.
• Two operators present for decrypting a backup that contains key components (if that involves cleartext handling).
• Two custodians needed to open a safe or access a secure cabinet holding key components.

Who it applies to

Entity types

This requirement applies to organizations subject to PCI DSS, including merchants and service providers handling cardholder data environments, and payment processors, where they perform covered key-management operations. (PCI DSS v4.0.1 Requirement 3.7.6)

Operational context (the real scoping question)

The scoping trigger is narrow and critical: manual cleartext cryptographic key-management operations performed by personnel. (PCI DSS v4.0.1 Requirement 3.7.6)

Use this quick decision test:

Question	If “Yes”	If “No”
Do humans ever handle key material in cleartext during any key-management step (generate, distribute, load, rotate, backup/restore, archive, destroy)?	Requirement applies to those operations; implement split knowledge + dual control.	Document why (e.g., fully automated HSM/KMS workflows) and keep evidence that cleartext handling doesn’t occur.

Do not stop at your internal teams. If a third party performs key ceremonies or key injection for systems in scope, you need contractual and due diligence coverage to ensure their procedures meet the same control intent.

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

1) Identify all key-management operations and flag manual cleartext touchpoints

Build a key-management inventory that includes:

• Key types (encryption, tokenization, database TDE, backup encryption, TLS private keys if managed in scope)
• Systems and storage locations (HSM, KMS, config management, offline media)
• Lifecycle operations (create, rotate, revoke, backup, restore, destroy)
• Whether any step involves manual cleartext handling

Deliverable: a scoped list of key-management operations where Requirement 3.7.6 applies.

2) Define roles and enforce separation (Key Custodian model)

Create at least two distinct roles, for example:

• Key Custodian A
• Key Custodian B Optionally add:
• Key Management Approver (separate from custodians)
• Observer/Auditor (can witness but cannot perform the steps)

Rules to encode in procedure:

• No one person can hold more than one component for the same key.
• No one person can complete the operation end-to-end.
• Temporary coverage (vacations) must be approved and logged, not handled informally.

3) Implement split knowledge mechanics for the key material

Choose a practical method appropriate to your tooling:

• If you use HSM/KMS but still have manual cleartext steps (break-glass export, migration), ensure exports are split into components or protected so no individual can access the full key.
• If components are stored offline, store them in separate physical containers with separate access controls.

Minimum operational requirement: each component has a distinct custodian and distinct access path.

4) Implement dual control workflow with hard stops

Your procedure should read like a checklist a technician can follow. Include:

• Preconditions (ticket approved, change window, required participants)
• Step-by-step actions with “Custodian A does X” / “Custodian B does Y”
• Verification steps (both confirm component identifiers, checksum/fingerprint where applicable, and successful key load)
• Abort conditions (mismatch, missing participant, unexpected output)
• Post-steps (secure storage, log capture, ticket closure)

Where possible, enforce dual control through:

• Two-person approvals in your ITSM/change system
• System permissions (no single admin role can retrieve all components)
• Physical controls (two keys/two combinations held by different people)

5) Update policies and procedures to match the operating reality

PCI calls out “policies and procedures are implemented.” (PCI DSS v4.0.1 Requirement 3.7.6) Assessors will compare what you wrote to what you do. Update:

• Key-management policy (states split knowledge + dual control requirement and scope trigger)
• Key ceremony/runbooks (the actual checklists)
• Access control standards (role design, approval requirements)
• Training/authorization criteria for custodians

6) Validate with a test ceremony and capture evidence

Run a controlled, non-production (or scheduled production) key operation using the new process. Validate:

• Two people were required
• No person could access the complete key alone
• Logs and records are complete and reproducible

7) Extend to third parties where applicable

If a third party performs any manual cleartext key-management steps for your in-scope environment:

• Add contractual obligations: dual control + split knowledge for manual cleartext operations
• Obtain evidence: their ceremony records (redacted), role definitions, and procedural excerpts
• Confirm escalation paths for incidents (lost component, suspected compromise)

Practical note: many teams treat third-party key injection as “out of scope.” If it affects keys protecting cardholder data, you still need assurance that their process meets the requirement intent.

Required evidence and artifacts to retain

Keep evidence that is specific enough to satisfy an assessor and repeatable enough for operations:

Core documents

• Key-management policy that explicitly requires split knowledge and dual control for manual cleartext operations (PCI DSS v4.0.1 Requirement 3.7.6)
• Key-management procedures/runbooks (key generation, rotation, distribution, loading, backup/restore, destruction)
• RACI or role descriptions for Key Custodians and approvers

Access and authorization

• Access control lists / IAM role mappings showing custodians have separated permissions
• Approval records for custodian assignment and any exceptions

Execution records ¹

• Change tickets with two-person approvals and named participants
• Key ceremony checklist signed/attested by both custodians (electronic approval is fine if controlled)
• System logs showing actions taken by each custodian account
• Inventory record updates showing key ID/version rotated and where components are stored

Exception handling

• Documented exceptions with compensating controls and management approval
• Incident records for lost component, suspected exposure, or process breaks

Common exam/audit questions and hangups

Expect these lines of questioning:

• “Show me where manual cleartext key handling occurs.” If you say “nowhere,” be ready to prove it with architecture and procedure evidence.
• “Walk me through your last key rotation or key load. Who did what?” Auditors want named participants and logs/tickets.
• “Can any one administrator export or reconstruct the key?” A single ‘super-admin’ path breaks the control intent.
• “How do you handle vacations and emergency access?” Informal swaps and shared accounts are common failure points.
• “What about third parties?” They will ask how you ensure outsourced key ceremonies meet the same requirement.

Frequent implementation mistakes (and how to avoid them)

1. Confusing dual control with dual approval
   Two approvals in a ticketing tool do not equal dual control if one person can still perform all technical steps. Fix: require two distinct operator accounts to execute steps, plus a procedure that assigns tasks to each.

2. Shared “key custodian” accounts
   Shared accounts destroy accountability and make it impossible to prove separation. Fix: individual accounts, role-based permissions, and per-person logging.

3. Split knowledge in policy, but not in storage
   Teams write “split knowledge” but store all components in the same vault folder accessible to one admin group. Fix: separate storage locations and separate access paths.

4. Ignoring break-glass paths
   Your normal path may be HSM-backed and automated, but the emergency export path can create manual cleartext handling. Fix: map and control emergency procedures with the same rigor.

5. No ceremony record retention
   Assessors will ask for the last occurrence. Fix: standardize a “key ceremony packet” and keep it with change records.

Enforcement context and risk implications

No public enforcement sources were provided for this requirement, so focus on the operational risk: manual cleartext key handling is a high-consequence insider threat and error surface. If a single person can reconstruct keys, one mistake or malicious act can expose encrypted data and invalidate your cryptographic boundary. PCI DSS pushes this control because cryptography fails if key custody fails.

Practical 30/60/90-day execution plan

First 30 days (Immediate containment and scoping)

• Identify all cryptographic keys protecting in-scope data and list every lifecycle operation.
• Flag any operation with manual cleartext handling by personnel.
• Freeze informal key ceremonies. Require a ticket and named participants for any key operation until procedures exist.
• Draft updated key-management policy language covering split knowledge and dual control for manual cleartext operations. (PCI DSS v4.0.1 Requirement 3.7.6)

Days 31–60 (Build the operating process)

• Define custodian roles, authorization requirements, and separation rules.
• Implement access separation in IAM/secrets platforms and physical storage.
• Write runbooks/checklists for each in-scope manual cleartext operation.
• Create a standard evidence packet template (ticket, checklist, log capture, approvals).

Days 61–90 (Prove it works and make it durable)

• Execute a live key operation under the new process and capture evidence end-to-end.
• Train custodians and approvers; document completion.
• Review third-party involvement; update contracts and collect due diligence evidence where they handle keys.
• Add periodic control testing: confirm no single account path exists to reconstruct a key and confirm ceremony records are retained.

Where Daydream fits (practical, earned mention)

If you struggle to keep key-management evidence consistent across teams and third parties, Daydream can act as the system of record for control narratives, procedure versions, and assessment-ready evidence packets. The goal is simple: every key ceremony produces the same artifacts, linked to the same requirement language, without chasing screenshots and email approvals during an audit.

Frequently Asked Questions

Does this apply if we use an HSM or cloud KMS?

It applies only where personnel perform manual cleartext key-management operations. If your HSM/KMS processes never expose cleartext keys to humans, document that determination and keep supporting architecture/procedure evidence. (PCI DSS v4.0.1 Requirement 3.7.6)

What counts as “manual cleartext key-management operations”?

Any step where a person can read, handle, enter, print, copy, or transport key material in human-readable form as part of key management. Treat break-glass exports, migrations, and offline component handling as prime candidates. (PCI DSS v4.0.1 Requirement 3.7.6)

Is dual approval in a change ticket enough for dual control?

Usually no. Dual control expects two authorized people to be required for the operation itself, not just a sign-off, and your logs/procedure should show task separation between the two. (PCI DSS v4.0.1 Requirement 3.7.6)

Can one person be both a key custodian and the approver?

Avoid it for in-scope manual cleartext operations because it concentrates power and weakens the control story. Separate approver and custodian duties, and document role boundaries in the procedure set. (PCI DSS v4.0.1 Requirement 3.7.6)

How do we handle emergencies when only one qualified person is available?

Write an exception process that requires management approval, documents why dual control was not possible, and adds compensating oversight (for example, real-time monitored session plus immediate post-event review). Track exceptions and trend them down over time. (PCI DSS v4.0.1 Requirement 3.7.6)

What evidence will an assessor actually ask to see?

Expect a recent key ceremony or key operation record: ticket with approvals, named custodians, checklist/runbook followed, and system logs showing each custodian’s actions. They will also ask for the policy/procedure text that mandates split knowledge and dual control for manual cleartext operations. (PCI DSS v4.0.1 Requirement 3.7.6)

Footnotes

1. PCI DSS v4.0.1 Requirement 3.7.6