Platform Documentation
Breadcrumbs

Cryptographic Key Policy

Purpose

This policy establishes requirements for the creation, use, rotation, storage, and destruction of cryptographic keys, ensuring the confidentiality, integrity, and availability of protected data.


Scope

This policy applies to all cryptographic keys used in:

  • Data encryption (at rest and in transit).

  • Authentication and signing (e.g., API tokens, SSH keys).

  • Cloud services (GCP KMS and Hashicorp Vault).

  • GitHub and Google Workspace integrations.


Policy Statements

3.1 Key Generation

  • Keys must be generated using approved cryptographic algorithms and key sizes (e.g., AES-256, RSA-2048+, ECDSA P-256+).

  • Keys must be generated in a trusted environment (cloud KMS, HSM, or equivalent).

3.2 Key Storage

  • Keys must not be stored in plaintext.

  • Keys must be managed via cloud-native KMS or a hardware security module (HSM) whenever possible.

  • Secrets and API tokens must be stored in an approved secrets manager (e.g., AWS Secrets Manager, HashiCorp Vault, Google Secret Manager).

3.3 Key Rotation

  • Encryption keys: Rotated at least every 12 months, or immediately if compromised.

  • API tokens and service account keys: Rotated at least every 90 days.

  • SSH keys: Rotated at least every 12 months, and revoked immediately upon employee departure.

  • Rotation must be automated where supported by the platform.

3.4 Key Usage

  • Keys must be granted least privilege (scoped to only required services).

  • Shared or generic keys are prohibited.

  • All key use must be logged and monitored.

3.5 Key Revocation & Destruction

  • Keys must be revoked when no longer needed.

  • Retired keys must be destroyed using secure erasure functions provided by the key management system.

3.6 Monitoring & Auditing

  • Logs of key creation, rotation, and deletion must be retained for at least 12 months.

  • Annual audits must verify compliance with this policy.


Governance

This policy is jointly owned by the Head of Engineering and Head of Security/Compliance, and it is reviewed at least annually or whenever practices evolve significantly.

For any questions or clarifications regarding this policy, please contact the Security or Engineering leadership team.