Cryptographic key management: the ISO 27001 evidence payment companies miss

Cryptographic controls sit at the heart of every payment company's security posture. Card data is encrypted. API tokens are signed. Webhooks carry HMAC signatures. Yet when an ISO 27001 auditor opens the evidence folder labelled "A.8.24 - Use of Cryptography," the same materials are routinely missing: no key lifecycle policy, no HSM configuration baseline, no rotation log, no access record for signing keys, and no evidence that split-knowledge or dual-control procedures were ever actually followed rather than just written down.

This is not a niche finding. For payment companies - acquirers, PSPs, gateways, and embedded finance platforms - cryptographic key management is where the gap between a written policy and auditable evidence is widest.

Why key management evidence is different from other controls

Most ISO 27001 controls have a straightforward evidence pattern: policy plus procedure plus record. For cryptography the pattern is longer because the asset - the key itself - must never appear in the evidence. The auditor cannot see the key. What they can see is everything around the key: who generated it, under what ceremony, on what hardware, with which access controls, rotated when, and destroyed how.

That means the evidence burden is almost entirely procedural and log-based. A single gap - a rotation that happened but was not logged, an HSM that is used but whose configuration was never baselined - can trigger a major nonconformity against A.8.24 even if the underlying cryptography is technically sound.

The key lifecycle: what auditors look for at each stage

A key lifecycle has at least five stages - generation, distribution, storage, rotation, and destruction - and each stage needs evidence.

Generation - Auditors expect to see a key generation ceremony record for any key that protects cardholder data or that is used for signing. The record should capture the date, the participants, the HSM serial or identifier, and confirmation that the ceremony followed the documented procedure. For companies using cloud KMS services (AWS KMS, Google Cloud KMS, Azure Key Vault), the equivalent evidence is the KMS audit log showing key creation events alongside the policy document that governed the parameters chosen.

Distribution - How was the key delivered to the system or person that needed it? Evidence here includes key-wrapping records, TLS transport logs for key material in transit, or - for physical key components - the courier or split-knowledge hand-off record. Any distribution that bypassed an approved channel is a finding.

Storage - The auditor will ask where keys at rest live and whether that location matches the policy. Acceptable answers for high-value keys typically involve an HSM or a FIPS 140-2 validated cloud KMS. Configuration baselines for the HSM - firmware version, tamper-evident logging enabled, network interface restrictions - need to exist and be current.

Rotation - This is where many companies accumulate their largest backlog. Rotation schedules are commonly set in policy (often "annually" or "every 90 days for API tokens") but rotation events are not logged in any retrievable way. The minimum evidence is a rotation log: key identifier or alias, rotation date, rotated by whom, and confirmation that the old key was revoked or destroyed on schedule.

Destruction - When a key is no longer needed, the evidence required is a destruction record. For HSM-held keys this is typically an HSM audit log entry or a signed ceremony record. For software keys the record should confirm that all copies - backups, environment variables, configuration files - were removed.

HSM evidence: beyond "we have an HSM"

Saying "we use an HSM" satisfies no auditor. The questions that follow are: which HSM, what firmware, who has administrative access, how is that access reviewed, is tamper-evident logging enabled and where do those logs go, and is the HSM configuration under change control?

Evidence a payment company should maintain includes an HSM asset record (make, model, firmware, location), an access control list for HSM admin roles with a date-stamped review, tamper-evident log exports retained in accordance with the organisation's log retention policy, and a change record for any firmware or configuration update.

If the company uses a cloud HSM or cloud KMS rather than on-premises hardware, the same questions apply to the cloud service configuration. IAM policies restricting key usage, CloudTrail or equivalent audit logs, and key policy documents showing separation of duties are the evidence equivalents.

Split knowledge and dual control: closing the ceremony gap

For the highest-sensitivity keys - acquiring master keys, PIN encryption keys, signing keys for settlement files - regulatory frameworks (PCI DSS, local scheme rules) typically mandate split knowledge or dual control. ISO 27001 does not mandate these specific techniques, but an auditor assessing A.8.24 against a payment company scope will expect that the cryptographic policy references and implements controls commensurate with the data classification.

The evidence gap here is almost always in the ceremony record rather than in the procedure document. A company may have a beautifully written split-knowledge ceremony procedure that has never produced a signed ceremony form. When the auditor asks for evidence that the last key generation or key-load event followed the split-knowledge procedure, the answer cannot be "we always do it that way." It needs to be a dated, signed ceremony record naming each custodian.

Access to signing keys: the overlooked control

Payment companies frequently sign outbound data - settlement files, webhook payloads, API responses. The private key used for signing is a high-value asset. Access controls on that key need to follow the same logic as access controls on any privileged credential: least privilege, role-based access, and a regular review.

Evidence auditors expect includes the access control record for the signing key (which role or service account has use permission, which has admin permission), an access review record showing that the list was reviewed within the policy cycle, and an alert or detection rule that would fire if the key were accessed outside of its normal signing context.

Where signing keys are held in a secrets manager (HashiCorp Vault, AWS Secrets Manager, GCP Secret Manager), the audit log from the secrets manager can serve as the access log provided that log retention meets policy.

Building an evidence pack that holds up under questioning

The test of a key management evidence pack is not whether it looks complete on the day of the audit. It is whether it would hold up under a line of questioning from an auditor who has been in payment company audits before and knows exactly which corners are typically cut.

A practical pre-audit checklist for cryptographic key management includes: key inventory (all keys, their purpose, algorithm, length, location, and owner); lifecycle records for each key from generation to current state; HSM or KMS configuration baseline with a date; rotation log covering at least the last two rotation cycles; access review for each key or key ring; ceremony records for any key that required split knowledge or dual control; and a destruction record for any key retired in the last 12 months.

None of these documents needs to be elaborate. A spreadsheet rotation log signed off monthly is adequate evidence. A ceremony form with three custodian signatures is adequate evidence. What is not adequate is a policy document on its own, however well-written.

Where Kellwick fits

Kellwick works with payment companies as an independent ISO 27001 readiness advisory - not a certification body - helping clients identify exactly these kinds of evidence gaps before a formal audit. A structured readiness review covers cryptographic controls in the context of the full Annex A assessment, producing a prioritised remediation list with suggested evidence templates. If your key management documentation does not yet match the standard an auditor would expect, our payments readiness service is the place to start.