Skip to Content
Security PoliciesKey Management Policy

Key Management Policy

FieldValue
Document IDPOL-004
Version1.0
Effective Date2026-04-08
Next Review Date2027-04-08
ClassificationInternal
OwnerInformation Security Officer
Approved ByCEO, Paylithix Inc.
Parent PolicyInformation Security Policy (POL-001)

1. Purpose

This policy defines the lifecycle management of cryptographic keys used to protect cardholder data in the Gatelithix Gateway. It governs key generation, storage, rotation, destruction, and custodianship, in compliance with PCI DSS 4.0.1 Requirements 3.5, 3.6, and 3.7.

2. Scope

This policy applies to all cryptographic keys used within the Gatelithix Gateway CDE:

  • PAN Encryption Keys — Cloud KMS HSM-backed keys used to encrypt/decrypt PANs via AES-256-GCM
  • Cloud SQL Encryption Keys — CMEK (Customer-Managed Encryption Keys) for database encryption at rest
  • TLS Certificates — Managed by Cloudflare (public endpoints) and GCP (internal service-to-service)
  • API Key Signing Material — Used for generating and validating merchant API keys
  • HMAC Webhook Signing Keys — Used for signing outbound webhook payloads to merchants

This policy does not cover: Auth0-managed session tokens (Auth0’s responsibility per their PCI AOC), Stripe API keys (Stripe’s responsibility), or GCP-managed infrastructure encryption (GCP’s responsibility per their PCI AOC).

3. Roles and Responsibilities

RoleResponsibility
Information Security OfficerKey custodian; approves key creation and destruction; leads annual crypto review
Engineering LeadSecondary key custodian; implements key rotation; manages Cloud KMS IAM bindings
Vault Service AccountSole automated consumer of PAN encryption keys (encrypt/decrypt operations)
All EngineersDo not export, copy, or locally store any cryptographic key material

3.1 Split Knowledge and Dual Control

  1. No single individual shall have the ability to reconstitute or export complete key material for PAN encryption keys.
  2. Cloud KMS HSM-backed keys cannot be exported by design — the key material never leaves the HSM boundary.
  3. Key creation and destruction require approval from both the ISO and the Engineering Lead (dual control).
  4. IAM changes granting cloudkms.cryptoKeyEncrypterDecrypter require approval from the ISO.

4. Policy Statements

4.1 Approved Cryptographic Algorithms

Use CaseAlgorithmKey LengthModeProvider
PAN encryption at restAES256-bitGCMCloud KMS HSM
Database CMEKAES256-bitGCMCloud KMS
Data in transitTLS1.2+ (ECDHE + AES-256-GCM preferred)Cloud Run / Cloudflare
Webhook HMAC signingHMAC-SHA256256-bitApplication (key from Secret Manager)
API key hashingbcryptcost factor 12Application

Prohibited algorithms: DES, 3DES, RC4, MD5 (for any cryptographic purpose), SHA-1 (for signing/HMAC).

4.2 Key Generation

  1. All keys protecting cardholder data shall be generated within Cloud KMS using HSM-backed key rings (protection level HSM).
  2. Key generation uses the cryptographic random number generator provided by the Cloud HSM hardware — no application-generated keys for PAN encryption.
  3. Each key is created with:
    • A descriptive name indicating its purpose (e.g., pan-encryption-primary)
    • The ENCRYPT_DECRYPT purpose for symmetric keys
    • The GOOGLE_SYMMETRIC_ENCRYPTION algorithm (AES-256-GCM)
    • HSM protection level
    • Automatic rotation enabled
  4. Key creation is logged in Cloud Audit Logs (Admin Activity).

4.3 Key Storage

  1. PAN encryption keys are stored exclusively within Cloud KMS HSM. Key material never leaves the HSM boundary and cannot be exported.
  2. Webhook signing secrets are stored in Google Secret Manager with IAM-restricted access.
  3. No cryptographic key material shall be stored in:
    • Application source code or configuration files
    • Environment variables containing raw key material (references to Cloud KMS key names are acceptable)
    • Local developer machines
    • Cloud SQL databases
    • Log files or error messages
  4. Key references (Cloud KMS key resource names) may be stored in Terraform state and application configuration.

4.4 Key Rotation

  1. PAN encryption keys shall be rotated automatically every 90 days via Cloud KMS automatic rotation.
  2. Cloud KMS automatic rotation creates a new key version while keeping previous versions available for decryption of data encrypted under older versions.
  3. After rotation, new encryption operations use the latest key version. Decryption automatically selects the correct key version based on the ciphertext metadata.
  4. Webhook signing secrets shall be rotated at least annually, with a grace period during which both old and new secrets are valid.
  5. API key signing material rotates implicitly when merchants generate new API keys.
  6. TLS certificates are rotated automatically by Cloudflare (public) and GCP (internal).

4.5 Cryptoperiod Policy

Key TypeMaximum CryptoperiodRotation MethodGrace Period
PAN encryption (Cloud KMS)90 days per versionAutomatic (Cloud KMS)Previous versions remain for decrypt only
Cloud SQL CMEK365 daysAutomatic (Cloud KMS)Previous versions remain active
Webhook HMAC secrets365 daysManual (Secret Manager)7 days dual-validity
TLS certificates90 days (Cloudflare)AutomaticOverlap during renewal

4.6 Key Access Control

  1. Access to perform encrypt/decrypt operations on PAN encryption keys is restricted to the vault Cloud Run service account only.
  2. IAM bindings for cloudkms.cryptoKeyEncrypterDecrypter shall include only the vault service account identity.
  3. No human user account shall have cryptoKeyEncrypterDecrypter permission on PAN encryption keys in production.
  4. cloudkms.admin role (key management, not encrypt/decrypt) is restricted to the ISO and Engineering Lead accounts.
  5. Key access is audited via Cloud KMS Data Access Audit Logs (enabled for all read and write operations).

4.7 Key Destruction

  1. Key versions shall not be destroyed unless:
    • All data encrypted under that key version has been re-encrypted under a newer version, or
    • The data protected by that key version has been securely deleted
  2. Key destruction requires written approval from both the ISO and Engineering Lead.
  3. Cloud KMS enforces a 24-hour scheduled destruction delay — destruction can be cancelled during this period.
  4. Before scheduling destruction, the Engineering Lead shall verify that no ciphertext in the vault database references the key version being destroyed.
  5. Key destruction events are logged in Cloud Audit Logs and recorded in the key management log.

4.8 Key Compromise Response

  1. If a key is suspected or confirmed to be compromised:
    • Immediately invoke the Incident Response Plan
    • Create a new key version in Cloud KMS
    • Re-encrypt all data protected by the compromised key version
    • Schedule destruction of the compromised key version (after re-encryption is verified)
    • Notify affected merchants if cardholder data may have been exposed
    • Document the incident, response actions, and lessons learned

4.9 Annual Cryptographic Review

  1. The ISO shall conduct an annual review of all cryptographic controls (PCI DSS 12.3.3). The review shall cover:
    • Inventory of all cryptographic keys and their purposes
    • Verification that rotation schedules are being followed (Cloud KMS rotation history)
    • Verification that IAM bindings on key rings match policy
    • Review of TLS versions and cipher suites in use across all connections
    • Confirmation that no prohibited algorithms are in use
    • Review of key access audit logs for anomalous access patterns
  2. The review shall produce a dated report with findings and any required remediation.
  3. Review schedule: April of each year (aligned with policy review cycle).

5. Compliance and Enforcement

  1. Any attempt to export, copy, or locally store cryptographic key material used for PAN encryption is a critical policy violation and shall be escalated immediately.
  2. Unauthorized changes to Cloud KMS IAM bindings are detectable via Cloud Audit Logs and treated as security incidents.
  3. Violations shall be handled per the Incident Response Plan.

7. Document History

VersionDateAuthorChanges
1.02026-04-08Information Security OfficerInitial policy creation