Encryption policy

1. Purpose

This policy defines how HLD Group uses cryptography to protect the confidentiality and integrity of information at rest, in transit, and in use, and how cryptographic keys are managed throughout their lifecycle. Strong, correctly implemented, and well-managed cryptography is a mandatory control across our estate.

2. Scope

This policy applies to all company and customer data, all systems and communications that store or transmit it, and all cryptographic keys and certificates used by HLD Group.

3. Definitions

• Encryption at rest — protecting stored data so it is unreadable without a key
• Encryption in transit — protecting data moving across a network
• Key management — the generation, distribution, storage, rotation, and destruction of keys
• Hardware security module (HSM) — tamper-resistant hardware for key protection and cryptographic operations
• Perfect forward secrecy — a property ensuring that compromise of a long-term key does not expose past sessions
• Cryptographic agility — the ability to change algorithms and key sizes without redesigning systems

4. Policy statement

Sensitive and customer data is encrypted at rest and in transit using strong, current, industry-accepted algorithms. Proprietary or unvetted cryptographic algorithms are prohibited. Cryptographic keys are protected at least as strongly as the data they protect and are managed under a defined lifecycle.

5. Approved algorithms and strength

• Symmetric encryption: AES-256 (or AES-128 minimum) in an authenticated mode such as GCM
• Asymmetric encryption and key exchange: RSA 3072-bit or greater, or elliptic-curve equivalents such as ECDH over approved curves
• Hashing: SHA-256 or stronger; MD5 and SHA-1 are prohibited for security purposes
• Password storage: a memory-hard function such as Argon2id, scrypt, or bcrypt with an appropriate work factor
• Deprecated protocols and ciphers, including SSL and TLS below 1.2, are disabled

6. Encryption in transit

• TLS 1.2 or higher for all external network communication, with TLS 1.3 preferred
• Strong cipher suites with perfect forward secrecy, and HSTS enforced for web services
• Internal service-to-service traffic encrypted in transit, with mutual TLS where practicable
• Valid certificates from trusted authorities, monitored for expiry and revocation

7. Encryption at rest

• Full-disk or volume encryption for servers and endpoints
• Database and object storage encryption enabled, with field- or column-level encryption for the most sensitive data
• Backups encrypted as required by the Backup and Recovery Policy
• Removable media encrypted, and unencrypted removable media prohibited for sensitive data

8. Key management lifecycle

• Keys generated using approved, high-entropy methods
• Keys stored in a managed key management service or HSM, never in code or configuration
• Access to keys restricted, logged, and separated from access to the data they protect
• Keys rotated on a defined schedule and immediately on suspected compromise
• Key destruction performed securely, with crypto-shredding used to render data unrecoverable where appropriate
• Split knowledge and dual control applied to the most sensitive key operations

9. Certificate management

• Certificates inventoried with owners and expiry dates
• Automated issuance and renewal used where possible to prevent outages and lapses
• Private keys protected and never shared across unrelated systems

10. Cryptographic agility and future readiness

Systems are designed so that algorithms and key sizes can be changed without redesign. HLD Group monitors developments in post-quantum cryptography and maintains an inventory of cryptographic dependencies so that migration can be planned as standards mature.

11. Framework alignment

• ISO/IEC 27001:2022 Annex A control 8.24 (use of cryptography)
• NIST SP 800-53 Rev. 5 control family SC (System and Communications Protection), notably SC-12 and SC-13
• NIST SP 800-57 (key management) and FIPS 140-3 for validated modules where required
• SOC 2 Trust Services Criteria CC6.1 and CC6.7
• PCI DSS v4.0 Requirements 3 and 4 where cardholder data is in scope

12. Roles, exceptions, and review

Cryptographic standards are owned by the CISO. Exceptions require documented CISO approval with compensating controls and an expiry date. This policy is reviewed at least annually and whenever a relevant algorithm or protocol is deprecated.