Describe your cryptographic key management: generation, rotation, revocation, and destruction of keys.

Encryption is only as good as the handling of its keys. Walk through the key lifecycle: where keys are created and stored, who can use them, how they rotate, and how they are revoked or destroyed. Evidence to have ready: A key management policy or standard; KMS configuration showing key policies and rotation settings; access records for key administration roles.

Cryptographic key management questionnaire answer

What is cryptographic key management?

Cryptographic key management is how an organization handles encryption keys across their whole lifecycle. The cryptographic key lifecycle runs from generation and storage through use, rotation, and revocation to destruction. It usually lives in a key management service (KMS) or a hardware security module (HSM).

What the buyer is really asking

Encryption is only as good as the handling of its keys. Walk through the key lifecycle: where keys are created and stored, who can use them, how they rotate, and how they are revoked or destroyed.

Other ways buyers ask it

Every one of these wants the same answer:

“Describe your key management process.”
“Where are encryption keys stored?”
“Who has access to encryption keys?”
“Do you use a KMS or HSM?”

Evidence to have ready

A key management policy or standard
KMS configuration showing key policies and rotation settings
Access records for key administration roles

Sample answers by company stage

The right answer depends on what you actually run today. Each sample below is honest only if its condition is true for you. Swap the bracketed details for your own.

Early startup

Use this if: You rely on your cloud provider's managed key service and have not built any key handling of your own.

Encryption keys are generated and stored in [AWS KMS], a managed service backed by FIPS 140 validated hardware security modules. We never handle raw key material. Our application and storage services use keys through KMS APIs, and IAM policies limit that use to specific roles. Automatic rotation is enabled on our customer managed keys every [365] days. Key administration is limited to [two] named engineers. Every key operation is logged in [CloudTrail]. To revoke a key we disable it in KMS. To destroy one we schedule deletion with a [30]-day waiting period.

Scaling

Use this if: You have a written key management standard, separate keys per environment or data type, and a periodic review of who can administer keys.

Our key management standard covers generation, use, rotation, revocation, and destruction. Keys are generated inside [AWS KMS] and are never exported. We use separate keys per environment and per data class, so a production key cannot decrypt staging data. Data is protected with envelope encryption: data keys encrypt the data, and a KMS key encrypts the data keys. Key policies separate administration from use, so the engineers who manage keys cannot use them to decrypt data. Rotation runs automatically every [365] days. We review key policies and administrator access [quarterly]. If we suspect a key is compromised, our runbook disables it, re-encrypts affected data under a new key, and schedules the old key for deletion once nothing depends on it.

Enterprise-ready

Use this if: You offer customer managed keys or dedicated HSMs, and your key controls are inside an audited scope.

Key management follows our cryptography standard, which maps to NIST SP 800-57 and is tested in our SOC 2 Type II audit. Keys are generated in FIPS 140 validated HSMs through [AWS KMS] and cannot be exported. Enterprise customers can supply their own key held in their own cloud account. If a customer revokes our access to that key, their data becomes unreadable to us within [minutes]. We keep an inventory of every key with its owner, purpose, and last rotation date. Disabling or deleting a production key requires approval from two people. Key compromise is a named scenario in our incident response plan, and we exercise it [annually].

How the major questionnaires word it

Each standard questionnaire asks this in its own structure. These are paraphrased summaries, not the licensed question text.

CAIQ v4 (Cloud Security Alliance): The Cryptography, Encryption and Key Management domain splits this into many separate yes or no rows: generation, rotation, revocation, destruction, inventory, and more. Each row also asks whether the control belongs to you, your customer, or both. Answer every row on its own and point the notes back to one lifecycle description so the rows never contradict each other.
SIG (Shared Assessments): SIG asks whether a documented key management process exists. It then drills into who can access keys and whether keys are stored apart from the data they protect. Expect follow-ups about HSM use and rotation frequency.
VSA (Vendor Security Alliance): VSA-style questionnaires usually ask it in one line: how are encryption keys managed, and who has access to them? A short lifecycle paragraph with the service name fits well.
HECVAT (higher education): HECVAT pairs a yes or no about having a key management process with an additional information column. Reviewers read that column. Put the key service name and rotation interval there instead of leaving it blank.

More evidence reviewers accept

A key inventory listing each key with its purpose, owner, and last rotation date
An export of the key policy that shows administrators separated from key users
Audit log excerpts showing key usage and administration events
Your cloud provider's FIPS 140 certificate for its key service
The section of your incident response plan that covers a compromised key

Red flags reviewers look for

Keys stored next to the data. A key in the same database, repository, or environment file as the ciphertext protects almost nothing. This is why reviewers ask where keys live.
No answer for revocation or destruction. Many answers cover generation and rotation and then stop. The question usually names all four stages. Skipping two reads as never having thought about them.
Admins can use every key. If the role that manages keys can also decrypt with them, one compromised account exposes everything. Reviewers probe for separation of duties here.
Rotation with no mechanism. Saying keys rotate regularly without naming an interval or an automatic setting invites a request for proof you may not have.
Keys in source code. Any hard-coded key or secret, even one only in git history, is an immediate finding. Run a secret scanner before you claim otherwise.

Follow-up questions to expect

Do you use an HSM?

If you use a cloud key service, the answer is usually yes: AWS KMS, Google Cloud KMS, and Azure Key Vault Premium keep keys in FIPS 140 validated hardware. Say that the provider operates the HSMs. Claim a dedicated HSM only if you pay for one, such as CloudHSM.

Can we bring our own key?

Answer yes only if a customer can hold the key in their own account and revoke your access. If every tenant shares keys you control, say so and describe how tenant data is kept separate instead.

Who at your company can decrypt our data?

This is the question behind the question. Name the roles, not a vague group, and say whether decryption happens only inside services or whether any person can do it by hand.

How would you know if a key was misused?

Point to the audit log for key usage and say whether anyone reviews it or alerts on it. A log that nobody reads is weaker evidence than a single alert on unusual decrypt volume.

How Tyrvar answers this

Tyrvar treats every wording above as one question. You write the answer once, attach the evidence, and revisit it when your setup changes. Each buyer gets that approved answer no matter how their questionnaire words it. If you have not answered it yet, Tyrvar flags the question for you and does not make something up. Try it on your own questionnaire.

Cryptographic key management: how to answer it in a security questionnaire