Control Definition
Organizations must establish and put into practice rules governing how cryptography is used effectively—covering where encryption is required, which algorithms are acceptable, and how cryptographic keys are managed across their full lifecycle.
Control Objective
To protect the confidentiality, integrity, and authenticity of information through appropriate use of encryption, establish secure key management practices, and ensure cryptographic controls meet business, regulatory, and security requirements.
What This Really Means
Use of cryptography means applying encryption to protect sensitive data from unauthorized access—encrypting data stored on databases and file servers (data at rest), encrypting data moving across networks (data in transit), digitally signing documents to verify authenticity, and using cryptographic hashing to detect tampering. It also includes safely managing the encryption keys themselves (generating, storing, rotating, and destroying keys).
Think of encryption like converting a message into a secret code that only authorized people with the right key can decode. Just as you would lock sensitive documents in a safe and control who has the key, encryption locks digital data and cryptographic key management controls who can unlock it.
This control requires you to define a cryptography policy stating when and what type of encryption to use, implement encryption for sensitive data at rest (disk encryption, database encryption) and in transit (TLS/SSL for websites and APIs, VPNs for network connections), use strong cryptographic algorithms (AES-256, RSA-2048+, SHA-256+) avoiding weak legacy encryption (DES, MD5, SHA-1), securely manage encryption keys using key management systems or hardware security modules, rotate keys periodically, and destroy keys when data is retired. The goal is mathematically-strong protection ensuring even if data is stolen, it remains unreadable without the keys.
Why It Matters
Data breaches regularly expose unencrypted sensitive information resulting in massive regulatory fines, reputational damage, and identity theft. Encryption is both a regulatory requirement and fundamental security control.
Without proper use of cryptography, organizations face:
- •Data Breach Exposure and Regulatory Fines – Stolen unencrypted data is immediately usable by attackers and maximizes regulatory exposure under DPDPA and similar laws; strongly encrypted data with uncompromised keys drastically limits the practical harm, and some regimes (such as GDPR) ease notification duties for it
- •Compliance Violations – PCI DSS mandates rendering stored cardholder data unreadable and encrypting it across open networks; HIPAA treats encryption of health records as the expected safeguard; DPDPA demands reasonable security safeguards for personal data; RBI master directions expect strong encryption in regulated entities
- •Data Theft During Transit – Unencrypted network traffic allows eavesdropping on sensitive communications; attackers intercepting traffic (man-in-the-middle) read passwords, customer PII, and business confidential data
- •Stolen Device Data Exposure – Lost or stolen laptops, phones, USB drives with unencrypted data allow immediate access to sensitive information; full-disk encryption renders devices useless to thieves
- •Cloud Data Exposure – Misconfigured cloud storage buckets exposing unencrypted data cause public breaches; encryption provides defense-in-depth even when access controls fail
Indian organizations should treat encryption as a core reasonable security safeguard under the DPDP Act, and BFSI players face explicit expectations: RBI master directions and SEBI's CSCRF expect sensitive financial and customer data to be encrypted both at rest and in transit.
Implementation Guidance
Define Cryptography Policy and Standards
Document when encryption is required: all personally identifiable information (PII), payment card data (PCI DSS requirement), health records, authentication credentials (passwords, API keys), confidential business data, data crossing network boundaries, data stored on portable devices, backups, and personal data in DPDP Act scope (encryption is the clearest reasonable security safeguard). Specify approved cryptographic algorithms and minimum key lengths: encryption (AES-256, RSA-2048+), hashing (SHA-256 or SHA-3), avoid deprecated algorithms (DES, 3DES, MD5, SHA-1, RC4). Define key rotation schedules and key lifecycle management requirements.
Implement Encryption for Data at Rest
Encrypt sensitive data stored on disk: full disk encryption for laptops/workstations (BitLocker for Windows, FileVault for macOS, LUKS for Linux), database encryption (Transparent Data Encryption for SQL Server/Oracle, encryption at rest for MongoDB/PostgreSQL), file server encryption (encrypting file systems or storage volumes), cloud storage encryption (AWS S3 server-side encryption, Azure Storage Service Encryption, Google Cloud default encryption), backup encryption (encrypt backup files before storage), and USB/portable media encryption (encrypted USB drives or software encryption). For databases, choose between transparent data encryption (entire database encrypted) vs. column-level encryption (only sensitive columns like credit cards, SSN encrypted).
Implement Encryption for Data in Transit
Encrypt network communications: TLS 1.2+ for web traffic (HTTPS for websites and web APIs), VPN tunnels for remote access (IPsec or SSL VPN), encrypted email (S/MIME or PGP for sensitive email attachments), database connections (SSL/TLS for database client connections), API authentication tokens (always sent over HTTPS never HTTP), file transfers (SFTP or FTPS, not plain FTP), and wireless networks (WPA3 or WPA2-AES, never WEP). Configure servers to reject weak cipher suites (disable RC4, 3DES, export-grade encryption) and enforce perfect forward secrecy (PFS).
Implement Secure Cryptographic Key Management
Manage encryption keys securely throughout lifecycle: Generate keys using cryptographically secure random number generators (never hardcode keys in application code), Store keys separately from encrypted data (database encryption keys not stored in same database), Use key management systems (AWS KMS, Azure Key Vault, Google Cloud KMS) or Hardware Security Modules (HSMs) for key storage providing tamper-resistance, Control access to keys (only authorized services/users can request decryption), Rotate keys periodically (annually minimum for data encryption keys, more frequently for high-risk systems), and Destroy keys securely when data is retired (cryptographic deletion - destroying keys makes encrypted data unrecoverable).
Use Digital Signatures and Certificates
Implement cryptographic authentication and integrity: Digital signatures for code signing (sign software releases and scripts to verify authenticity), document signing (sign contracts and official documents for non-repudiation), API authentication (sign API requests to verify sender identity). Manage TLS certificates: obtain certificates from trusted CAs (not self-signed for public-facing services), monitor certificate expiration (automate renewal before expiry), maintain certificate inventory, and revoke compromised certificates promptly. For internal services, consider private PKI (Public Key Infrastructure) issuing internal certificates.
Protect Cryptographic Keys from Exposure
Prevent key leakage: Never commit encryption keys to source code repositories (Git secrets scanning to detect accidental commits), Use environment variables or secure configuration management for application keys, Implement secrets management tools (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault) for centralized key distribution, Encrypt keys when stored on disk (key encryption keys protecting data encryption keys), Require multi-person control for key access (split keys or dual authorization for critical keys), and Log all key access and usage for audit trail.
Regularly Review and Update Cryptographic Practices
Stay current with cryptographic standards: Monitor NIST guidance for deprecated algorithms and sunset timelines, Review cryptographic implementations after security advisories (Heartbleed, POODLE-type vulnerabilities), Conduct cryptographic audits (penetration testing focused on encryption implementation flaws, certificate validation bugs), Test encryption effectiveness (verify data is actually encrypted, test key rotation procedures), Plan algorithm migration (gradually transition from SHA-1 to SHA-256, TLS 1.0/1.1 to TLS 1.2+), and Assess quantum-resistant cryptography timeline (NIST post-quantum standards for future-proofing).
Audit Evidence
During your ISO 27001 certification audit, auditors will expect to see the following evidence to demonstrate compliance with A.8.24:
Documentation
- Cryptography Policy defining when and how encryption shall be used
- Approved cryptographic algorithm standards and minimum key lengths
- Key management procedures for generation, storage, rotation, and destruction
- Data classification scheme identifying what data requires encryption
- Certificate inventory with expiration dates and renewal schedule
Interviews
- IT Security team about encryption implementation and key management practices
- Database administrators about database encryption configuration
- Cloud architects about cloud encryption and key management services
Observations
- Verification that sensitive data at rest is encrypted (sample database tables, file servers)
- Demonstration of TLS encryption for web applications and APIs
- Review of key management system access controls and audit logs
- Testing certificate validity and cipher suite configuration
Practitioner Insights
A pattern I keep finding in audits: the database is encrypted, but the decryption keys sit in a configuration file on the same server. This is like locking a safe but taping the key to the safe door—anyone who gains server access simply reads the key and decrypts everything. Keys must be stored separately—use key management services, HSMs, or at minimum a different server with restricted access. Encryption without key separation provides false security.
Many developers use weak encryption because they do not understand cryptography. I have seen MD5 for password hashing (completely broken), custom encryption algorithms (always flawed), and hardcoded keys in source code (discovered by attackers reading GitHub). Mandate that developers use established crypto libraries (OpenSSL, BouncyCastle, native crypto APIs) never roll their own encryption, and have security team review all cryptographic implementations before deployment.
Common Challenges & Solutions
Challenge
Encryption degrades application performance causing user complaints and slow database queries.
Solution
Optimize selectively: Use hardware-accelerated encryption (AES-NI CPU instructions, encryption-accelerated storage), encrypt only sensitive columns/fields not entire database (balance security with performance), use compression before encryption (reduces data size), implement caching strategically (cache decrypted data in application memory with short TTL), and scale infrastructure if needed (encryption overhead is often 5-15% - sometimes acceptable cost for security). Measure actual impact before and after encryption to inform decisions.
Challenge
Managing encryption keys across multiple cloud providers and on-premise systems is complex.
Solution
Centralize key management: Use multi-cloud key management solutions (HashiCorp Vault works across AWS/Azure/GCP), implement bring-your-own-key (BYOK) for cloud services allowing single key management system, establish key hierarchy (master keys protecting data keys), automate key rotation using APIs and automation scripts, and maintain key inventory documenting which keys protect which data systems. For simpler organizations, use native cloud KMS per cloud provider and maintain clear documentation of key locations.
Challenge
How do we recover encrypted data if encryption keys are lost or corrupted?
Solution
Implement key escrow and backup: Backup encryption keys to secure offline storage (encrypted USB drives in physically secure location, key recovery codes printed and stored in safe), use key splitting (M-of-N scheme where any 3 of 5 key custodians can recover), maintain key escrow with trusted third party for critical systems, document and regularly test key recovery procedures, and balance recovery capability with security (escrow creates additional attack surface). For cloud services, use provider managed keys with built-in durability and replication.
Challenge
Third-party applications and legacy systems do not support modern encryption standards.
Solution
Layered approach: Use network-level encryption (IPsec VPN tunnel, TLS proxy in front of legacy application), implement database-level encryption if application cannot encrypt (transparent data encryption), isolate legacy systems on separate network segments with strict access controls, encrypt at storage layer (storage array encryption), and prioritize migration or replacement of legacy systems that cannot support encryption. Document compensating controls when encryption is not feasible and ensure management accepts residual risk.
Challenge
Developers are hardcoding encryption keys in application code and checking them into Git repositories.
Solution
Preventive and detective controls: Mandate secrets management training for all developers, use secrets management tools (AWS Secrets Manager, Azure Key Vault, HashiCorp Vault) with SDK libraries for secure key retrieval, implement Git secrets scanning (detect credentials in commits before they are pushed), conduct code reviews requiring security approval for cryptographic implementations, use static analysis tools (SonarQube, GitGuardian) detecting hardcoded secrets, and immediately rotate any keys accidentally exposed in version control. Make secure key management easy so developers choose the right path.
