Cryptography Policy
Cryptography Policy
Company Name:
Effective Date:
Policy Owner:
Approved By:
Chief Information Security Officer:
1. Purpose & Scope
1.1 This policy defines the Organization's requirements for the selection, implementation, and management of cryptographic controls used to protect the confidentiality, integrity, authenticity, and non-repudiation of information assets throughout their lifecycle. The policy establishes mandatory standards for encryption algorithms, key lengths, key management practices, digital certificate management, and the use of cryptographic protocols across all Organization systems and communications. This policy is aligned with ISO 27001 Annex A.10 Cryptography requirements, NIST SP 800-57 Recommendations for Key Management, and applicable regulatory requirements including data protection legislation and industry-specific compliance frameworks.
1.2 This policy applies to all cryptographic controls implemented within or on behalf of the Organization, including encryption of data at rest and in transit, digital signatures, hashing algorithms, certificate-based authentication, and cryptographic key management systems. Coverage extends to all Organization-owned and managed systems, networks, applications, databases, cloud services, endpoints, and removable media across all operating environments. All employees, contractors, IT administrators, application developers, and third-party service providers who are responsible for the implementation, configuration, management, or use of cryptographic mechanisms are bound by this policy. Third-party service providers who process Organization data shall be contractually required to apply cryptographic controls that meet or exceed the standards defined in this policy.
1.3 The Chief Information Security Officer shall be responsible for defining and approving the Organization's cryptographic standards, overseeing key management practices, evaluating new cryptographic technologies, and ensuring that the Organization's use of cryptography complies with applicable laws, regulations, and export control restrictions. The CISO shall designate a Cryptography Custodian within the Information Security team who shall be responsible for the day-to-day management of the Organization's key management infrastructure, certificate authority operations, and cryptographic compliance monitoring. The CISO shall review the Organization's cryptographic posture at least annually and shall update approved algorithms and key lengths in response to advances in cryptanalysis, changes in regulatory requirements, or updates to referenced standards.
2. Encryption Standards
2.1 All data classified as Confidential or Restricted under the Organization's Data Management Policy shall be encrypted at rest using AES-256 or another NIST-approved symmetric encryption algorithm of equivalent or greater strength. Full-disk encryption using BitLocker, FileVault, or an equivalent approved solution shall be enabled on all Organization-managed laptops, desktops, and removable media. Database-level or column-level encryption shall be applied to Confidential and Restricted data fields within databases and data warehouses. Encryption of data at rest in cloud environments shall utilize the cloud provider's encryption service with customer-managed encryption keys stored in the Organization's key management system or a hardware security module. Data classified as Internal may be encrypted at the discretion of the data owner, and data classified as Public does not require encryption at rest.
2.2 All data transmitted across internal and external networks, including communications between Organization systems, client-server communications, API calls, email transmissions, and file transfers, shall be encrypted using TLS 1.2 or TLS 1.3. Legacy encryption protocols, including SSL 2.0, SSL 3.0, TLS 1.0, and TLS 1.1, shall be disabled on all Organization systems, services, and endpoints, and shall not be used for any purpose. Where TLS is not applicable, such as for VPN tunnels or site-to-site connections, IPSec with AES-256 encryption and SHA-256 or stronger integrity algorithms shall be used. Cipher suites shall be configured to prefer forward secrecy using ephemeral Diffie-Hellman or Elliptic Curve Diffie-Hellman key exchange. The Information Security team shall maintain a list of approved cipher suites and shall conduct quarterly scans to verify that prohibited protocols and weak cipher suites are not in use across the Organization's infrastructure.
2.3 Asymmetric encryption operations, including key exchange, digital signatures, and certificate-based authentication, shall use RSA with a minimum key length of 2048 bits, with 4096 bits recommended for long-term keys and certificate authority keys, or Elliptic Curve Cryptography using NIST-approved curves with a minimum key length of 256 bits. Hash functions used for integrity verification, digital signatures, and password hashing shall use SHA-256 or stronger algorithms from the SHA-2 or SHA-3 family. The following algorithms and protocols are prohibited and shall not be used for any purpose within the Organization's environment: DES, 3DES, RC4, MD5, SHA-1 for digital signatures or certificate signing, and any proprietary or non-peer-reviewed encryption algorithms. The CISO shall maintain an approved cryptographic algorithms register and shall update it at least annually to reflect advances in cryptanalysis and changes in regulatory guidance.
3. Key Management
3.1 Cryptographic keys shall be generated using cryptographically secure pseudo-random number generators that comply with NIST SP 800-90A or equivalent standards. Key generation for high-value keys, including certificate authority keys, master encryption keys, and keys protecting Restricted data, shall be performed within FIPS 140-2 Level 2 or higher validated hardware security modules. All cryptographic keys shall be managed throughout their complete lifecycle in accordance with NIST SP 800-57, encompassing key generation, distribution, storage, activation, usage, rotation, deactivation, archival, and destruction. The Cryptography Custodian shall maintain a key inventory that records the key identifier, algorithm, key length, purpose, creation date, expiration date, custodian, and current lifecycle state for every active key.
3.2 Encryption keys shall be rotated at intervals proportionate to their sensitivity, usage volume, and the classification of the data they protect. Data encryption keys protecting Restricted data shall be rotated at least every 6 months. Data encryption keys protecting Confidential data shall be rotated at least annually. Keys protecting Internal data shall be rotated at least every 2 years. Transport layer encryption keys and session keys shall be generated per session using ephemeral key exchange mechanisms. Certificate authority signing keys shall be rotated in accordance with the Organization's certificate policy, typically every 3 to 5 years for intermediate CA keys. Key rotation procedures shall ensure zero downtime and shall include a transition period during which both the old and new keys are valid to allow for orderly re-encryption and re-signing of affected data and certificates.
3.3 Cryptographic keys shall be stored securely using hardware security modules, trusted platform modules, or Organization-approved key management systems that provide tamper-resistant storage, access control, and audit logging. Private keys and symmetric encryption keys shall never be stored in plain text on file systems, in application configuration files, embedded in source code or scripts, transmitted via email or messaging platforms, or shared through unencrypted channels. Access to key management systems shall be restricted to authorised Cryptography Custodians and shall require multi-factor authentication. All key access events shall be logged and monitored. Key backup and recovery procedures shall be documented and tested at least annually to ensure that encrypted data can be recovered in the event of key loss. Destroyed keys shall be overwritten using NIST-approved sanitisation methods, and destruction shall be documented in the key inventory.
4. Certificate Management
4.1 Digital certificates used for TLS/SSL server authentication, client authentication, code signing, email encryption, and document signing shall be issued by the Organization's internal certificate authority or by a trusted external certificate authority that has been evaluated and approved by the CISO. The Organization shall maintain an internal certificate authority infrastructure with appropriate physical and logical security controls, including offline root CA, dedicated intermediate CAs for different certificate types, and hardware security module-backed key storage. Certificates issued by the internal CA shall comply with the Organization's certificate policy, which shall define certificate profiles, validity periods, key usage extensions, and revocation procedures. Wildcard certificates shall be used only where justified and approved by the Information Security team, due to the increased risk associated with private key exposure.
4.2 The IT department shall maintain a centralised certificate inventory, managed through the Organization's certificate lifecycle management platform, that tracks all active digital certificates across the Organization's infrastructure. The inventory shall record the certificate subject, issuer, serial number, key algorithm and length, validity period, associated system or service, responsible owner, and renewal status. Automated monitoring shall be configured to alert the responsible owner and the IAM team at least 90 days, 60 days, and 30 days before certificate expiration. Certificates that are not renewed before expiration shall trigger an escalation to the IT Department Head and the CISO. The Organization shall implement automated certificate provisioning and renewal using the ACME protocol or equivalent automation where feasible to reduce the risk of certificate-related outages.
4.3 Certificates that have been compromised, are associated with compromised private keys, are no longer needed, or are associated with individuals or systems that have been decommissioned shall be revoked immediately through the Organization's certificate revocation process. The Cryptography Custodian shall publish updated certificate revocation lists within 4 hours of any revocation event. The Organization shall maintain Online Certificate Status Protocol responders that are available 24/7 with a target availability of 99.9% to enable real-time certificate validation. All Organization systems and applications shall be configured to check certificate revocation status before accepting certificates for authentication or encryption purposes. The Information Security team shall conduct quarterly reviews of the certificate inventory to identify and revoke expired, orphaned, or unnecessary certificates.
5. Compliance & Policy Review
5.1 The Information Security team, in coordination with the Internal Audit function, shall conduct semi-annual audits of the Organization's cryptographic controls. Audit scope shall include encryption coverage for data at rest and in transit across all systems containing Confidential or Restricted data, algorithm and key length compliance with the approved cryptographic algorithms register, key management lifecycle compliance including generation, rotation, storage, and destruction practices, certificate inventory accuracy and expiration management effectiveness, and compliance of third-party service providers with the Organization's cryptographic requirements. Audit findings shall be classified by severity and reported to the CISO. Critical and high-severity findings shall be remediated within 30 days, and remediation shall be verified through a follow-up assessment.
5.2 Any violation of this policy, including the use of prohibited or deprecated encryption algorithms, improper storage of cryptographic keys, failure to encrypt data as required by the data classification framework, bypassing or disabling encryption controls, or failure to rotate keys within the defined schedule, shall be subject to disciplinary action proportionate to the nature and impact of the violation. Where a violation creates an immediate risk of data exposure, the Information Security team shall implement emergency remediation measures, which may include revoking access, isolating affected systems, or initiating key rotation. All violations shall be documented, investigated, and reported to the CISO. Disciplinary proceedings shall be coordinated with Human Resources and Legal Counsel.
5.3 This policy shall be reviewed comprehensively at least once every 12 months by the CISO, in consultation with the Cryptography Custodian, the IT department, application development leads, and Legal Counsel. Reviews shall specifically assess the continued suitability of approved algorithms and key lengths in light of advances in quantum computing and post-quantum cryptography research, changes in NIST, ISO 27001, and other referenced standards, emerging cryptanalytic techniques that may weaken currently approved algorithms, and regulatory developments including export control changes. The Organization shall monitor NIST's Post-Quantum Cryptography Standardization project and shall develop a quantum-readiness migration plan within 12 months of the publication of final post-quantum cryptography standards. Approved amendments shall be communicated to all affected personnel and integrated into development standards and deployment procedures.
What Is a Cryptography Policy?
A cryptography policy is a formal document that defines an organization's requirements for the use of encryption, digital signatures, hashing, and key management to protect the confidentiality, integrity, and authenticity of information assets. It establishes the approved algorithms, key lengths, key lifecycle management practices, and certificate management procedures that must be followed across all systems and communications.
Cryptography is a foundational element of information security, providing the mathematical mechanisms that protect data from unauthorised access and tampering. ISO 27001 Annex A.10 specifically addresses cryptographic controls, requiring organizations to develop and implement a policy on the use of cryptographic controls and to establish key management procedures. NIST provides extensive guidance through SP 800-57 on key management and SP 800-175B on the use of cryptographic standards.
A cryptography policy covers encryption of data at rest and in transit, approved symmetric and asymmetric algorithms and key lengths, cryptographic key lifecycle management, digital certificate provisioning and revocation, and compliance with export control regulations governing the use and transfer of encryption technology.
Why Your Organization Needs a Cryptography Policy
A formal cryptography policy ensures that your organization's encryption practices are consistent, up to date, and effective at protecting sensitive data. Without standardised cryptographic controls, different systems and teams may use inconsistent or outdated algorithms, mismanage encryption keys, or fail to encrypt data that requires protection.
The consequences of weak or mismanaged cryptography can be severe. Outdated algorithms such as DES, RC4, and MD5 have known vulnerabilities that can be exploited by attackers to decrypt data or forge digital signatures. Improperly managed encryption keys — stored in plain text, embedded in source code, or shared through insecure channels — negate the protection that encryption is supposed to provide. A cryptography policy prevents these failures by mandating approved algorithms and prohibiting deprecated ones.
Regulatory requirements increasingly mandate specific cryptographic controls. PCI DSS requires strong cryptography for the protection of cardholder data. HIPAA's Security Rule requires encryption of electronic protected health information. GDPR identifies encryption as a key technical measure for data protection. A documented cryptography policy demonstrates compliance with these requirements and provides the framework for consistent implementation.
The emergence of quantum computing adds urgency to cryptographic planning. NIST has been developing post-quantum cryptography standards that will eventually replace current public-key algorithms. Organizations that maintain a formal cryptography policy with regular reviews are better positioned to monitor these developments and plan their transition to quantum-resistant algorithms.
Key Components of a Cryptography Policy
An effective cryptography policy contains four core components that together establish a comprehensive framework for the use and management of cryptographic controls.
The first component is Encryption Standards. This defines the approved algorithms and minimum key lengths for symmetric encryption, asymmetric encryption, hashing, and transport layer security. It explicitly lists prohibited algorithms and specifies the approved cipher suites for each use case.
The second component is Key Management. This establishes the procedures for the entire key lifecycle: generation using cryptographically secure random number generators, secure distribution, protected storage in hardware security modules or approved vaults, rotation at defined intervals, archival for data recovery, and secure destruction at end of life.
The third component is Certificate Management. This covers the organization's internal and external certificate authority infrastructure, certificate provisioning and renewal procedures, centralised inventory management, automated expiration monitoring, and revocation processes.
The fourth component is Compliance and Review. This defines the audit program for cryptographic controls, addresses export control and regulatory compliance, and establishes the review cycle for updating approved algorithms in response to advances in cryptanalysis and quantum computing developments.
How to Implement This Cryptography Policy
Implementing this cryptography policy requires coordination between the Information Security team, IT infrastructure, application development, and vendor management.
Step one: inventory your current cryptographic landscape. Audit all systems, applications, and communications channels to identify where encryption is currently deployed, which algorithms and key lengths are in use, and where gaps exist. Pay particular attention to legacy systems that may still use deprecated algorithms.
Step two: remediate prohibited algorithms. Identify and replace all instances of prohibited algorithms including DES, 3DES, RC4, MD5, and SHA-1. Prioritise systems that handle Confidential or Restricted data. For legacy systems that cannot be immediately upgraded, implement compensating controls and create a migration timeline.
Step three: deploy key management infrastructure. Implement a key management system and hardware security modules for the generation, storage, and rotation of encryption keys. Migrate keys from plain text storage, configuration files, and source code into the approved key management solution.
Step four: establish certificate lifecycle management. Deploy a certificate lifecycle management platform, build your centralised certificate inventory, and configure automated monitoring and alerting for certificate expirations. Implement the ACME protocol or equivalent automation for certificate provisioning and renewal where feasible.
Step five: plan for quantum readiness. Begin monitoring NIST's Post-Quantum Cryptography Standardization project and assess your organization's exposure to quantum computing threats. Develop a quantum-readiness roadmap that identifies the systems, algorithms, and timelines for migration to post-quantum cryptography standards.
Frequently Asked Questions
Written by Adithyan RK