Register Owner: CISO + CTO
Effective Date: May 16, 2026
Reviewed: At each ISMS Management Review
Source procedure: Key Rotation
Source policy: Cryptography Policy → Key rotation cadence
Effective Date: May 16, 2026
Reviewed: At each ISMS Management Review
Source procedure: Key Rotation
Source policy: Cryptography Policy → Key rotation cadence
Purpose
For SOC 2 CC6.7 (key management) to test cleanly at the initial Type II report, each cryptographic-key cadence class needs at least one rotation evidence pack inside the observation window. The 90-day classes rotate on their natural schedule; the annual classes will not rotate inside a 3-month window unless management triggers a rotation early. This plan triggers one early rotation per cadence class so every class has operating evidence in the window.Scope
Cadence classes covered (per Cryptography Policy → Key rotation cadence (consolidated)):| Class | Cadence | Natural next-rotation date | Plan |
|---|---|---|---|
| Vault Transit application-layer keys | Annual | 2027-05-08 | Trigger early in window |
| AWS KMS Customer-Managed Keys (CMKs) | Annual | 2027-05-08 | Trigger early in window |
| Long-lived API keys (Neuroscale-issued; non-rotating customer-facing API keys) | Annual | 2027-05-08 | Trigger early in window |
| Service-account static keys (cloud IAM, OIDC, AppRole secrets) | 90 days | Natural | Document the natural rotation that falls in window |
| Database passwords (Aurora / Postgres admin / app-bound) | 90 days | Natural | Document the natural rotation that falls in window |
| Web certificates (TLS) | ≤1 year | Per ACM auto-renewal | Document the automated renewal evidence |
Rotation schedule — initial Type II window
| Class | Target rotation date | Owner | Evidence pack |
|---|---|---|---|
| Vault Transit application-layer key (one representative key) | 2026-06-30 | CISO + CTO (dual-presence per Key Rotation procedure → Process) | (a) Vault audit-device log entry; (b) Linear ticket with CISO + CTO sign-off; (c) post-rotation verification that the prior key version is retained for decryption-only until envelope-wrapped data is rewrapped. Filed at /registers/key-rotations/2026-06-vault-transit.mdx. |
| AWS KMS CMK (one representative CMK — typically the Aurora-data CMK) | 2026-07-15 | CISO + CTO | (a) AWS CloudTrail event for the ScheduleKeyDeletion / EnableKeyRotation / UpdateKeyDescription call as appropriate; (b) AWS-side rotation log; (c) Linear ticket with sign-off. Filed at /registers/key-rotations/2026-07-aws-kms.mdx. |
| Long-lived API key (one representative key — pick a Neuroscale-issued upstream-AI-provider key) | 2026-07-31 | CTO + Engineering on-call | (a) Provider-side console screenshot of the old key revocation timestamp + new key creation timestamp; (b) Vault entry for the new secret; (c) Linear ticket with sign-off + rollback rehearsal note. Filed at /registers/key-rotations/2026-07-long-lived-api.mdx. |
| Service-account static key (natural rotation that falls in window — pick whichever rotates first per the Vault rotation schedule) | 2026-08-15 target (actual is the natural date that falls in window) | Engineering on-call | (a) Vault audit-device log; (b) workload restart / re-auth confirmation; (c) Linear ticket. Filed at /registers/key-rotations/2026-08-service-account.mdx. |
| Database password (natural rotation — Aurora admin or app-bound, whichever rotates first in window) | 2026-08-30 target (actual is the natural date in window) | CTO + Engineering on-call | (a) AWS Secrets Manager / Vault Database secrets-engine rotation event; (b) connection-string update + workload restart confirmation; (c) Linear ticket. Filed at /registers/key-rotations/2026-08-db-password.mdx. |
| Web certificate (TLS) | Continuous — AWS Certificate Manager auto-renewal documented at first ISMS-MR | Engineering | (a) ACM cert inventory; (b) auto-renewal event log for any cert renewed inside the window. Filed at /registers/key-rotations/2026-tls-acm.mdx (one summary file). |
Process per rotation
Each rotation follows the Key Rotation procedure end-to-end. The evidence pack per rotation contains:- Authorization — Linear ticket with named approvers per the procedure.
- Pre-rotation rehearsal — for annual-cadence classes, a dry-run in staging documented in the ticket.
- Execution log — timestamps for: prior key marked decryption-only / pending-deletion; new key issued; workloads updated and verified; prior key fully revoked.
- Verification — post-rotation health-check: workload re-auth succeeded; sample envelope-wrap / decrypt operation succeeded; no error spike in observability.
- Sign-off — CISO + CTO sign the evidence file (for Vault Transit and KMS), CTO + Engineering on-call sign for static-key and DB-password rotations.
Subsequent-window plan
Annual-cadence classes return to their natural cadence in the first subsequent 12-month window (Sep 22, 2026 – Sep 22, 2027). The whole-class annual rotation sweep (per Cryptography Policy) operates by 2027-05-08 for each annual class. 90-day classes continue to rotate naturally. This plan applies to the initial window only; an analogous register is created for any future window where the natural-cadence-only posture would leave a class without in-window evidence.Cross-references
- Cryptography Policy → Key rotation cadence (consolidated)
- Key Rotation procedure
- Secrets Management
- Controls Inventory — CC6.7 control rows
- Annual Controls — First-Cycle Treatment — the cross-domain analog of this plan
Version history
| Version | Date | Description | Author | Approved by |
|---|---|---|---|---|
| 1.0 | May 16, 2026 | Initial key rotation plan for the initial Type II window. Triggers one rotation per cadence class to land inside the window for CC6.7 operating-effectiveness evidence. | Cameron Wolfe | Ishan Jadhwani |