Compliance Framework Alignment
ISO/IEC 27001:2022 — A.8.24 (Use of cryptography) SOC 2 — CC6.1 (logical access, encryption at rest & key management) SOC 2 — CC6.7 (protection of data in transit) PCI DSS v4.0.1 — Req 3 (protect stored account data; 3.5.1, 3.6, 3.7, 3.7.6) PCI DSS v4.0.1 — Req 4 (encryption in transmission; 4.2.1, 4.2.1.1) This policy operationalises the cryptography and key-management controls of the frameworks above. It is a template and not legal or compliance advice; algorithm choices and key-management practices must be validated against a current risk assessment and, where applicable, a QSA assessment before an audit.
ACME TECHNOLOGIES PVT LTD CRYPTOGRAPHY & KEY MANAGEMENT POLICY
Effective Date [Effective Date]
Policy Owner Chief Information Security Officer (CISO )
Review Cycle annually
Classification Internal — Controlled Document 1. Purpose and Scope
This policy establishes the mandatory rules for the effective use of cryptography and the management of cryptographic keys across Acme Technologies Pvt Ltd ("the Organisation"), in accordance with ISO/IEC 27001:2022 Annex A control 8.24. It applies to all information systems, applications, networks, endpoints, storage, cloud services, personnel and third parties that generate, use, store or transmit information owned or processed by the Organisation. Where the Organisation stores, processes or transmits cardholder data, this policy additionally governs the PCI DSS v4.0.1 Requirement 3 (protect stored account data) and Requirement 4 (protect cardholder data in transmission) obligations.
2. Cryptographic Objectives and Governance
Cryptography is used to preserve the confidentiality, integrity, authenticity and non-repudiation of information commensurate with its classification and the results of risk assessment. The CISO owns this policy, approves the approved-algorithm catalogue, and is accountable for cryptographic governance. Rules for the use of cryptography, and the roles and responsibilities for key management, are documented, communicated and reviewed at least annually, and following any material change to the threat landscape, standards (e.g. NIST SP 800-57 / SP 800-131A) or the Organisation's architecture.
3. Approved Algorithms and Minimum Key Lengths
Only the following approved, industry-standard algorithms and minimum key strengths may be used. Symmetric encryption of data at rest: AES with a minimum 256-bit key (AES-256) in an authenticated mode such as GCM or in CBC mode with HMAC. Asymmetric cryptography: RSA with a minimum 2048-bit modulus (3072-bit for keys with a validity period extending beyond 2030), or elliptic-curve cryptography (ECC) using NIST P-256/P-384 or equivalent (minimum 256-bit). Hashing and integrity: SHA-256 or stronger; keyed hashing (HMAC, CMAC or GMAC) with an effective cryptographic strength of at least 128 bits where used to render data unreadable. Password storage: a memory-hard function (Argon2id, scrypt or bcrypt) or PBKDF2 with a high iteration count and per-secret salt. Any deviation requires a documented, time-limited exception approved by the CISO .
4. Encryption in Transit
All information classified as confidential or above, and all authentication credentials, must be encrypted in transit over untrusted and public networks. TLS 1.2 is the minimum permitted version and TLS 1.3 is preferred; strong cipher suites with forward secrecy (ECDHE) must be enforced. SSL, TLS 1.0 and TLS 1.1 are prohibited and must be disabled on all endpoints. Other approved transport protocols include SSH-2 and IPsec/IKEv2. In satisfaction of PCI DSS v4.0.1 Requirement 4.2.1, primary account numbers (PANs) transmitted over open, public networks are secured using strong cryptography and secure protocols, only trusted keys and certificates are accepted, and the protocol in use is configured to accept only trusted keys and certificates.
5. Encryption at Rest and Protection of Stored Data
Confidential information at rest — including databases, backups, object storage, removable media and full-disk volumes on portable devices — must be encrypted using AES-256 with keys managed under this policy. In satisfaction of PCI DSS v4.0.1 Requirement 3.5.1, the PAN is rendered unreadable anywhere it is stored using strong cryptography with associated key-management processes, one-way keyed cryptographic hashes of the entire PAN (with an effective strength of at least 128 bits, e.g. HMAC/CMAC/GMAC), truncation, or tokenisation. Disk-level or partition-level encryption is only used as permitted for removable media and is not relied upon as the sole control for PAN in a database.
6. Key Generation and Distribution
Cryptographic keys must be generated using a validated cryptographic module and a NIST-approved deterministic random bit generator (DRBG) seeded from a high-entropy source, at the strength required for their intended algorithm. Keys are generated within, or imported directly into, a FIPS 140-2/3 Level 3 Hardware Security Module (HSM); private and secret keys must never exist in plaintext outside a secure cryptographic boundary. Keys are distributed only over secure, authenticated channels using key-wrapping or key-agreement; symmetric secret keys and private keys are never transmitted in cleartext. Data-encryption keys (DEKs) are protected by key-encryption keys (KEKs) under an envelope-encryption model.
7. Key Storage — HSM / KMS
All root keys and key-encryption keys are stored and used within a FIPS 140-2/3 Level 3 Hardware Security Module (HSM). Access to keys is restricted to the fewest number of authorised custodians necessary, enforced through role-based access control, strong authentication and least privilege, and all key-management operations are logged to a tamper-evident audit trail. Cryptographic keys are stored in the fewest possible locations and forms, are logically and physically separated from the data they protect, and production keys are never used in, or copied to, non-production environments. A documented description of the cryptographic architecture, including all algorithms, protocols and keys used to protect stored account data, their strength and expiry, and the separation of production and test key material, is maintained in accordance with PCI DSS v4.0.1 Requirement 3.6.1.1.
8. Key Rotation and Cryptoperiods
Every key is assigned a defined cryptoperiod after which it must be retired. Symmetric data-encryption keys are rotated at least every twelve (12) months, and no later than the end of their defined cryptoperiod (NIST SP 800-57 guidance of one to two years for data-at-rest DEKs is the outer bound). Key-encryption and root keys are rotated at least every twenty-four (24) months. Rotation is also performed immediately whenever the integrity of a key is weakened (for example, departure of a key custodian, suspected or known compromise, or where a key reaches the end of its cryptoperiod). Rotation is designed so that historical data can be re-encrypted or decrypted under the retiring key during a controlled transition window.
9. Split Knowledge and Dual Control
Where manual, cleartext cryptographic key-management operations are performed by personnel, they must be managed using split knowledge and dual control. In satisfaction of PCI DSS v4.0.1 Requirement 3.7.6, no single person has access to a full cleartext key or its components: keys are split into two or more components held by separate custodians (split knowledge), and at least two authorised custodians must be present and act together to reconstruct, load or use such a key (dual control). Key custodians formally acknowledge, in writing, their responsibilities for safeguarding their key components. These controls apply to key generation ceremonies, key loading, key backup and any recovery of cleartext key material.
10. Key Revocation, Suspension and Compromise
A key must be revoked or suspended when it is compromised, suspected of compromise, superseded, or when a custodian with knowledge of it leaves their role. On confirmed or suspected compromise the affected keys are revoked immediately, dependent certificates are revoked, data protected by the key is re-encrypted under a fresh key, and the event is handled through the security incident-response process. Retired or revoked keys are not reissued and are constrained so they can only be used, if at all, to decrypt previously protected data under dual control and never to protect new data.
11. Key Archival, Escrow and Destruction
Keys required to decrypt archived or legally-retained data are securely archived under the same protection and access controls as active keys, with dual control for retrieval. When a key reaches end of life and is no longer required for any lawful purpose, all instances and components of the key are securely destroyed using an approved method (for example, cryptographic erasure or zeroisation within the HSM/KMS) such that the key cannot be reconstructed. Destruction is performed under dual control, is logged, and a certificate or record of destruction is retained.
12. Certificate and PKI Management
Public-key certificates (TLS/SSL, code-signing and client certificates) are obtained from DigiCert / internal PKI / Let's Encrypt and are inventoried in a central certificate register recording owner, subject, issuer, key algorithm and length, issue and expiry dates, and deployment location. Certificates are monitored for expiry and renewed proactively before they lapse; expired, revoked or untrusted certificates must not be used in production. Certificate private keys are generated and stored subject to the key-storage controls in this policy, and revocation status is validated (CRL/OCSP). In satisfaction of PCI DSS v4.0.1 Requirement 4.2.1.1, an up-to-date inventory of all trusted keys and certificates used to protect PAN during transmission is maintained, and only valid, non-expired and non-revoked certificates are accepted.
13. Prohibited and Deprecated Cryptography
The following are prohibited for protecting confidential information and must be disabled or replaced wherever found: DES, 3DES/TDEA (for new use), RC4, RC2, Blowfish; the MD5 and SHA-1 hash algorithms for security purposes; RSA or DSA keys shorter than 2048 bits and ECC keys shorter than 224 bits; ECB block-cipher mode; SSL (all versions), TLS 1.0 and TLS 1.1; export-grade, anonymous, NULL or otherwise weak cipher suites; and any hard-coded, default, shared or unmanaged keys. The approved-algorithm catalogue is reviewed against evolving standards, and cryptographic agility is maintained so that deprecated algorithms can be migrated in a planned, timely manner.
14. Roles, Compliance and Exceptions
The CISO is responsible for maintaining this policy and the approved-algorithm catalogue; system and application owners are responsible for implementing conformant cryptography in their services; and designated key custodians are responsible for the secure handling of key material. Compliance is verified through internal review, logging and audit at least annually. Any exception must be risk-assessed, time-bound, documented and approved in writing by the CISO before implementation, and is tracked to remediation. Violations of this policy may result in disciplinary action up to and including termination and, where applicable, legal action.
Approved by
Chief Information Security Officer
______________________
Title
CISO
______________________
Date
[Effective Date]
______________________