How to use this checklist
This is the yearly look at the two or three modules that everything else in the estate ultimately trusts. It is not a penetration test and it is not an audit of your cloud provider. It asks a narrower question: does the key material you believe is protected actually carry the attributes that protect it, and can you prove that from a command rather than from a diagram someone drew at procurement time.
Run it on a fixed date each year, with the module owner and a security reviewer in the room at the same time. Half of the items below are answered by reading an attribute; the other half are answered by producing a document and a date. A review where every answer arrives verbally is a review that has recorded somebody’s recollection, not the state of the module.
Where the numbers come from
The key register is the working document for this review, and it is worth insisting that it exists as a file rather than as a wiki page. Identifiers, purposes, states, owners, cryptoperiods and backup decisions are read from it, and the commands above assume it is structured enough to query. Where the register disagrees with the module, the module wins and the register becomes a finding.
Attribute-level items are read from the token itself. Export the object attributes once at the start of the review and grep the export, rather than clicking through a vendor console item by item. Cloud KMS items are read from the provider API: key state, key usage, origin, rotation status and the list of versions still enabled.
Four items cannot be answered by a command at all. Whether the compromise playbook is separate from the rotation schedule, whether the module validation is still current on the CMVP list, and both quorum items are attested by a named person who has looked. There is no API that reports where a share is kept, and a command that claimed to answer it would be lying.
Access this needs
Read access to the key register, read-only credentials for the KMS that permit describing keys and listing versions but not using them, a PKCS #11 session as a user who can enumerate objects, and the Security Policy documents for the modules under review. No item here requires the ability to sign, decrypt, wrap or unwrap anything. If completing the review needed a privilege that could use the keys, the review would be a bigger risk than the finding.
What the review produces
One signed record per module, listing every item, its disposition, and the command output or the attestation that supports it. It goes to the platform owner and the security owner, and a copy is filed with the key register so that next year’s reviewer can diff against it. Findings become dated tickets with named owners. A module whose validation has moved to the historical list, or whose quorum has drifted to a threshold one person can reach, produces a written risk acceptance signed above the platform owner rather than a note in the margin.
Sign-off
- Reviewer: ________________ Date: ___________
- Platform owner: ___________ Date: ___________
- Security owner: ___________ Date: ___________
Every critical item must pass. A failing critical item means the module is not currently a trustworthy root for anything that depends on it, and that dependency list is the blast radius. Record the date, the reviewer, and the disposition of every item that did not pass, including the ones deliberately accepted.