Home · Synthesis · cl-cryptography-mgmt

Cryptographic controls, key management, and post-quantum readiness

ISO 27001 PCI DSS RBI CSF RBI ITGRCA SEBI CSCRF NIST CSF 2.0 CSA CCM v4 GDPR IRDAI 2026 ISO 27017 ISO 27018 MeitY CSP NCIIPC NIS2 NIST 800-53 SEBI Cloud

Primary statement

Cryptography across the organisation operates under: (1) an approved-algorithms and key-length policy; (2) hardware security module (HSM) custody for high-value keys including payment, signing, and customer authentication keys; (3) documented key lifecycle — generation, distribution, rotation, archive, destruction — with custodian segregation; (4) TLS 1.2 minimum at the network layer with TLS 1.3 preferred; deprecated algorithms (DES, RC4, MD5, SHA-1) forbidden in security-sensitive use; (5) post-quantum cryptography (PQC) inventory and migration roadmap — a 2024–26 emerging mandate.

Audit-fatigue payoff

A single cryptography programme — approved-algorithms policy, HSM deployment register, key lifecycle documentation, TLS configuration baseline, PQC inventory — satisfies cryptographic-control requirements across all 16 frameworks. The strictest specification draws PQC readiness from SEBI CSCRF PR.9, key management depth from RBI ITGRCA IM.4, and core algorithmic discipline from ISO 27001 A.8.24. PCI DSS layers specific cardholder-data requirements on top. Without the unified programme, the auditor asks: which algorithms are approved, where are keys, who has access, how are they rotated, when do you rotate, what about quantum — five questions per framework × 16 frameworks. With the unified programme, one programme document answers all.

Strictness matrix

Scope

Scope covers ALL cryptographic operations: data at rest encryption, data in transit encryption (TLS at all layers), database encryption, application-layer encryption of sensitive fields (card numbers, account numbers, biometric data), payment signing keys, authentication tokens, customer-facing certificates, internal CA infrastructure, and all keys protecting any of the above. Ceiling source: rbi_itgrca:ITGRCA.IM.4 Rationale: RBI ITGRCA IM.4 has the broadest scope, covering all use cases of cryptography in the organisation. ISO 27001 A.8.24 is broad but less enumerative; SEBI CSCRF and PCI DSS cover narrower segments.

Threshold

Threshold for HSM custody: high-value keys (payment signing, customer authentication root keys, code-signing certificates, infrastructure-level encryption keys). Threshold for application-layer encryption: sensitive fields (payment card primary account number, biometric identifiers, financial account numbers, health data). Threshold for algorithm deprecation: any use in security-sensitive context (not just primary use). Ceiling source: sebi_cscrf:CSCRF.PR.9 Rationale: SEBI CSCRF PR.9 with the August 2025 HSM mandate sets explicit thresholds: HSMs for MIIs and Qualified REs are mandatory, not optional. The mandatory-HSM threshold is the strictest threshold specification.

Method

Method specification: (1) approved-algorithms policy with allowlist AND denylist (DES, RC4, MD5, SHA-1 forbidden in security-sensitive use); (2) HSM (FIPS 140-2 Level 3 or higher) for high-value keys; (3) key custody segregation — key generation, storage, and usage roles separated; (4) documented key lifecycle covering generation, distribution, rotation (with periodicity per key class), archive, destruction; (5) TLS configuration baseline enforced via automated scanning; (6) application-layer encryption of sensitive fields additional to transport-layer encryption. Ceiling source: rbi_itgrca:ITGRCA.IM.4 Rationale: RBI ITGRCA IM.4 is the most-prescriptive method specification, enumerating six specific elements. The lifecycle specification and custody segregation are uniquely strict here; other frameworks require "key management" but do not detail the lifecycle stages.

Frequency

Cryptographic asset inventory refreshed continuously through change management; reviewed annually. PQC risk assessment performed annually with prioritisation of high-risk assets (long-lived secrets, signature schemes vulnerable to harvest-now-decrypt-later attacks). Key rotation per the documented key lifecycle (typical: signing keys annual, encryption keys quarterly or on event, session keys per session). Ceiling source: sebi_cscrf:CSCRF.ID.3 Rationale: SEBI CSCRF ID.3 with the PQC dimension sets the strictest frequency model: continuous inventory updates plus annual PQC assessment is the most-frequent cadence in the cluster. PQC readiness is a 2024–26 emerging mandate; this framework articulates it most explicitly.

Evidence

Required evidence: (1) approved-algorithms policy with explicit allowlist and denylist; (2) HSM deployment register identifying every HSM and its protected keys; (3) key lifecycle procedure with sample records of rotation, archive, destruction events; (4) custody segregation matrix (key generation role, custody role, usage role separated); (5) TLS configuration audit (SSL Labs equivalent) showing compliance with the baseline; (6) cryptographic asset inventory including keys, certificates, algorithms in use; (7) PQC risk assessment results and migration plan; (8) application-layer encryption verification (sample fields demonstrated encrypted at rest beyond transport-only). Ceiling source: sebi_cscrf:CSCRF.PR.9 Rationale: SEBI CSCRF PR.9 evidence list is the most enumerative, particularly on PQC and on the cryptographic asset inventory. This evidence depth satisfies the evidence expectations of all other frameworks in the cluster.

Auditor test pattern

Step 1: Inspect approved-algorithms policy; verify deprecated algorithms are explicitly forbidden; sample 2 systems and verify TLS configuration meets baseline (run SSL Labs or equivalent). Step 2: For HSM-mandated organisations (MIIs, Qualified SEBI REs), inspect HSM deployment; verify FIPS 140-2 Level 3+; sample 2 high-value keys and trace them to HSM custody. Step 3: Sample 3 keys and trace through the key lifecycle (when generated, when last rotated, who holds custody, when next rotation due). Step 4: Inspect the cryptographic asset inventory and the PQC risk assessment; verify high-risk assets are identified and migration timeline is documented. Step 5: For application-layer encryption, sample 2 sensitive fields and verify they are encrypted at rest (not just protected by transport encryption).

Common findings

Common 2024–26 findings: (1) TLS 1.0/1.1 still enabled on legacy systems; (2) Application-layer encryption claimed but actually transport-only — sensitive fields stored plain in the database; (3) HSM deployed but key rotation procedures never exercised (rotation policy theoretical); (4) Cryptographic asset inventory absent — keys, certificates, algorithms not enumerated; (5) PQC risk assessment never performed; (6) Custody segregation absent — one role holds key generation, storage, and use; (7) Approved-algorithms policy exists but denylist not enforced (deprecated algorithms still in use in non-primary paths).