.svg){kind=logo}
Your infrastructure is encrypted. TLS everywhere, AES-256 at rest, keys stored in a managed service. You’ve done the technical work. Then the auditor asks: “Can I see your cryptography policy?”
A cryptography policy is a formal document that defines which encryption algorithms your organisation approves, how cryptographic keys must be managed, and where encryption is required across your systems and data. It covers data in transit and at rest, specifies minimum key lengths, lists what’s prohibited, and assigns ownership for keeping those standards current.
The distinction matters. Encryption is the implementation. A cryptography policy is the governance layer: the rules that make your encryption decisions auditable, consistent, and defensible. Without it, every engineer makes their own call, and none of those calls leave a paper trail an auditor can verify.
Several compliance frameworks require it explicitly:
- ISO 27001:2022: Control 8.24, “Use of Cryptography,” is a named Annex A control
- SOC 2: Expected under CC9.1 (risk mitigation) and the Confidentiality criteria
- NIST: SP 800-131A, SP 800-57, and FIPS 140-3 all assume an organisational policy governing cryptographic use
- HIPAA: Technical safeguard requirement for encryption of electronic protected health information (ePHI)
- PCI DSS: Requirement 3.5 and 4.2 cover cryptographic controls for cardholder data
By the end of this guide, you’ll know exactly what a cryptography policy needs to contain, how to write one from scratch, and what evidence auditors expect to see.
Here’s what I’ll cover:
- What a cryptography policy is and how it differs from an encryption standard
- Why having encryption isn’t enough without a written policy
- A free, usable cryptography policy template mapped to ISO 27001
- How to implement and roll out the policy in your organisation
- What framework controls it satisfies
- Common mistakes that create audit gaps
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
Cryptography Policy: Definition, Scope, and Ownership
A cryptography policy is the set of rules that governs how your organisation uses encryption: which algorithms are approved, what key lengths are required, how keys are stored and rotated, and what’s explicitly prohibited.
Key insight
A cryptography policy isn't about implementing encryption — your engineers are probably already doing that. It's about documenting which algorithms are approved, which are prohibited, who controls the keys, and how key rotation is handled. That documentation is what auditors and enterprise procurement teams look for.
It doesn’t replace technical configuration. It sits above it, providing the documented rationale and requirements that your technical implementation must satisfy. If an auditor asks why you chose AES-256 over AES-128, or why you’re still running TLS 1.2 in certain environments, the answer should trace back to a written policy decision, not a Slack thread from 2021.
Who owns a cryptography policy?
Ownership typically sits with the CISO, Head of Engineering, or IT Security Lead. Senior management approves it. All technical staff, including contractors and third parties handling your data, are expected to follow it.
In smaller organisations, the CTO usually serves as policy owner by default. That’s fine, as long as someone specific is named, the policy is approved at an appropriate level, and there’s a process for keeping it updated.
Security policy in cryptography: what that phrase actually means
You’ll sometimes see the phrase “security policy in cryptography” used to mean the governance document that defines how cryptographic controls are deployed, as opposed to the cryptographic mechanisms themselves.
The distinction is this: the policy says “all data at rest must be encrypted using AES-256.” The technical standard (or encryption standard document) says “we use AWS KMS with the aws/s3 managed key, rotating annually.” Both are necessary. Some organisations keep them in one document, others split them. Either approach works, as long as both layers exist.
Cryptography policy vs. encryption standard: what’s the difference?
A cryptography policy is high-level governance: scope, ownership, requirements at a principles level, review cadence, and enforcement.
An encryption standard is the technical annex: specific algorithm names, exact key lengths, approved cipher suites, key management tool names. It’s more granular and changes more frequently, since NIST regularly updates its guidance on which algorithms are current.
Larger organisations maintain both separately. For most startups and mid-size companies, a single well-structured policy document that covers both layers is sufficient.
Why Encryption Without a Policy Creates Real Risk
I’ve spoken to founders who were confident going into their SOC 2 Type II audit because their systems were encrypted. Then they got a finding, not because the encryption was wrong, but because there was no documented policy showing they had made a deliberate choice.
Free Demo
Ad-hoc encryption choices create audit gaps even when the implementation is technically sound
ComplyJet generates a cryptography policy aligned to ISO 27001 A.8.24, SOC 2, and NIST requirements — with a pre-built approved algorithm list and key management framework.
The auditor’s question isn’t just “are you encrypted?” It’s “how do you know your encryption is correct, and how would you know if it stopped being correct?”
From a security perspective, without formal requirements, individual developers make ad-hoc decisions. Some choose deprecated algorithms (MD5 for checksums, SHA-1 for signatures, RC4 for legacy integrations). Some hard-code keys in environment variables and commit them to source control. Some skip encryption on internal APIs because “it’s behind the firewall.” None of these choices are inherently malicious, they’re just what happens when there are no rules.
From a compliance perspective, ISO 27001 auditors treat a missing cryptography policy as a nonconformity under control 8.24. Not a minor observation: a named nonconformity that will require a corrective action plan and follow-up evidence before your certification is issued.
From an operational perspective, inconsistent key management is quietly dangerous. If there’s no documented process for key rotation, revocation, and destruction, you may be running systems with keys that should have been retired months ago. A compromised key with no revocation procedure in place is a very bad situation.
Does Your Company Need a Cryptography Policy?
If you store or transmit customer data, handle PII in any form, or are pursuing a compliance certification, yes, you need a written cryptography policy.
Why it matters
ISO 27001 Control 8.24 makes a cryptography policy mandatory for certification. Even if you're only pursuing SOC 2, auditors will ask how you govern encryption decisions — especially for data at rest in cloud storage and data in transit between services.
More specifically:
- ISO 27001: Control 8.24 in the 2022 standard explicitly requires documented “rules for the appropriate use of cryptography, including cryptographic key management.” This is not optional.
- SOC 2: Not required by name, but SOC 2 auditors routinely request evidence of encryption controls as part of CC9.1 and the Confidentiality TSC. A written policy is the cleanest way to satisfy this.
- NIST frameworks: NIST SP 800-131A, FIPS 140-3, and SP 800-57 all assume an organisational-level policy governing cryptographic use. If you’re aligning with NIST, you need the policy.
- HIPAA: Encryption of ePHI is an addressable implementation specification under § 164.312. A cryptography policy documents that you’ve made a deliberate decision about how to satisfy it.
- PCI DSS: Requirements 3.5 and 4.2 cover cryptographic protection of cardholder data. A policy is expected evidence.
Who especially needs a cryptography policy
SaaS startups pursuing SOC 2 are the most common case. Enterprise procurement teams ask for SOC 2 Type II reports, auditors ask for encryption evidence, and the easiest path is a written policy with supporting technical evidence.
Healthcare tech vendors handling ePHI under HIPAA need this regardless of their certification status. The policy satisfies the encryption safeguard requirement.
Fintechs and payment processors under PCI DSS need documented cryptographic controls for cardholder data protection.
Any B2B company selling into enterprise will eventually receive a security questionnaire asking about their cryptography policy. Having a document to reference saves a lot of time.
What a Cryptography Policy Should Cover
Most policies I see have the same gap: they establish requirements but leave out the governance structure needed to make those requirements auditable. A good cryptography policy covers both.
| Policy section | What to include |
|---|---|
| Purpose | Why the policy exists: which risk it addresses and which frameworks it satisfies |
| Scope | All systems, data, environments, staff, contractors, and third parties covered |
| Roles and responsibilities | Who owns the policy, who defines algorithm standards, who manages keys, who audits compliance |
| Approved algorithms | Minimum standards for symmetric, asymmetric, hashing, and transport encryption, with explicit key lengths |
| Key management | Key generation, storage, rotation, revocation, and destruction requirements |
| Data-in-transit requirements | TLS version requirements for all external and internal communications |
| Data-at-rest requirements | Encryption requirements by data classification tier |
| Prohibited practices | Banned algorithms and practices listed explicitly, not just implied |
| Exceptions | How to request an exception, who approves it, how long it lasts, how it’s documented |
| Enforcement | What constitutes a violation and what the consequences are |
| Review cadence | Annual minimum, plus specific triggers for out-of-cycle review |
Cryptography control policy: what ISO 27001 control 8.24 requires
Control 8.24 in ISO 27001:2022 (previously A.10.1 in the 2013 edition) covers the “Use of Cryptography.” It requires organisations to define and implement rules on:
- Which types of cryptography are used and where
- The key management lifecycle (generation through destruction)
- Alignment with legal, regulatory, and contractual requirements
- Use of approved cryptographic modules
The policy document is the primary piece of evidence. Auditors will supplement it with configuration screenshots, key management logs, and an algorithm inventory. If the policy doesn’t reference specific algorithms, an auditor cannot verify that your configuration actually satisfies it.
Algorithm and key length requirements to specify
Don’t leave algorithm requirements vague. Specify minimums:
- Symmetric encryption: AES-256 for data at rest. AES-128 is the absolute minimum for legacy systems.
- Asymmetric encryption: RSA-2048 minimum for legacy systems. RSA-4096 or ECDSA P-256/P-384 for new implementations.
- Hashing: SHA-256 minimum. SHA-384 or SHA-512 for high-sensitivity applications.
- Transport: TLS 1.2 minimum. TLS 1.3 preferred. TLS 1.0 and 1.1 explicitly prohibited.
- Key storage: Approved key management service (AWS KMS, GCP Cloud KMS, Azure Key Vault, HashiCorp Vault). Plaintext keys in source code or configuration files explicitly prohibited.
Free Cryptography Policy Template (ISO 27001-Ready)
The template below is immediately usable. Replace the bracketed placeholders with your organisation’s specifics. Everything else is pre-populated with best-practice language aligned to ISO 27001 control 8.24 and NIST SP 800-57.
Free Template
Download the Free PDF Template
Pre-built and compliance-ready. Customise and use immediately.
[Company Name] Cryptography Policy Policy Owner: [Name, Title] Approved by: [Name, Title] Effective Date: [Date] Version: 1.0 Next Review Date: [Date + 12 months]
Purpose
To ensure the proper and effective use of cryptography to protect the confidentiality, authenticity, and integrity of information. This policy establishes requirements for the use and protection of cryptographic keys and cryptographic methods throughout the entire encryption lifecycle, and limits cryptographic use to algorithms that have received substantial public review and have been proven to work effectively.
Scope
This policy applies to all information systems developed, operated, or controlled by [Company Name] that store or transmit confidential data. It applies to all employees, contractors, and third-party vendors when they access, develop, or operate systems handling confidential or customer data.
| System / Data Type | In Scope |
|---|---|
| Production application databases | Yes |
| Customer data in cloud storage | Yes |
| APIs transmitting customer or confidential data | Yes |
| Employee endpoints (laptops, desktops) | Yes |
| Internal tooling (staging, development) | Yes, where customer data is present |
| Third-party SaaS storing data on our behalf | Yes (vendor contract must confirm encryption standards) |
Roles and Responsibilities
| Role | Responsibility |
|---|---|
| Policy Owner ([Name]) | Maintains this policy, triggers reviews, approves algorithm changes |
| Senior Management | Approves this policy and any major amendments |
| Engineering / IT Security | Implements algorithm requirements, manages key management tooling, maintains algorithm inventory |
| All technical staff | Follow approved algorithm requirements; report deviations or concerns to the policy owner |
| Third-party vendors | Comply with encryption requirements as specified in vendor contracts |
Policy Requirements
[Company Name] shall evaluate the risks inherent in processing and storing data and shall implement cryptographic controls to mitigate those risks where appropriate. Where encryption is in use, strong cryptography with associated key management processes and procedures shall be implemented and documented. All encryption shall be performed in accordance with industry standards, including NIST SP 800-57.
Customer data and confidential company data must use strong ciphers and configurations in accordance with vendor recommendations and NIST guidance when stored or transferred over any network.
[Company Name] will not engage in “roll-your-own” cryptography. Custom encryption algorithms, custom implementations of standard algorithms, and “security through obscurity” approaches are prohibited in production systems.
Approved Cryptographic Algorithms
| Use Case | Algorithm | Minimum Key Length | Status |
|---|---|---|---|
| Data at rest (symmetric) | AES | 256-bit | Approved |
| Data at rest (legacy) | AES | 128-bit | Approved (existing systems only) |
| Asymmetric encryption | RSA | 2048-bit | Approved (new implementations: 4096-bit preferred) |
| Asymmetric encryption | ECDSA / ECDH | P-256 (256-bit) or P-384 | Approved, preferred for new implementations |
| Hashing (general) | SHA-2 (SHA-256) | 256-bit | Approved |
| Hashing (high-sensitivity) | SHA-2 (SHA-384 / SHA-512) | 384/512-bit | Approved |
| Password hashing | bcrypt / Argon2 / PBKDF2 | bcrypt cost 12+; Argon2 per OWASP rec | Approved |
| Transport (TLS) | TLS 1.3 | N/A | Preferred |
| Transport (TLS) | TLS 1.2 | N/A | Approved (minimum acceptable) |
| Web certificates | RSA or ECC with SHA-2+ signature | RSA 2048-bit+; ECC 256-bit+ | Approved, max 1-year validity |
| Endpoint storage | AES | 128 or 256-bit | Approved |
Prohibited Algorithms and Practices
The following are explicitly prohibited in all production systems:
| Algorithm / Practice | Reason | Prohibited from |
|---|---|---|
| MD5 | Cryptographically broken; collision attacks demonstrated | All uses except non-security checksums |
| SHA-1 | Deprecated by NIST; collision attacks demonstrated | All cryptographic uses |
| DES | 56-bit key; brute-force vulnerable | All uses |
| 3DES (Triple DES) | NIST deprecated 2023; Sweet32 attack vulnerable | All uses |
| RC4 | Multiple vulnerabilities; broken in TLS contexts | All uses |
| TLS 1.0 / TLS 1.1 | NIST deprecated; POODLE and BEAST attack surface | All new and existing systems |
| Custom / proprietary cryptographic algorithms | Unreviewed; cannot be audited | All production systems |
| Hard-coded cryptographic keys | Keys embedded in source code or config files | All systems |
| Self-signed certificates (unmanaged) | Cannot be revoked; no trust chain | External-facing systems |
| Plaintext storage of secrets | Keys, tokens, passwords stored unencrypted | All systems |
Key Management Requirements
Generation: All cryptographic keys must be generated using an industry-standard random number generator (RNG) as defined in NIST SP 800-90A. Key generation must occur within an approved key management system or HSM. Keys must not be generated in application code using non-cryptographic random number generators (e.g., Math.random()).
Storage: Cryptographic keys must be stored in an approved key management service. Access to keys is governed by your Identity and Access Management (IAM) Policy: [AWS KMS / GCP Cloud KMS / Azure Key Vault / HashiCorp Vault, select applicable]. Plaintext keys must not be stored in source code, configuration files, environment variable files, or databases.
Rotation: Keys must be rotated on the schedule below or whenever a compromise is suspected:
| Key Type | Rotation Frequency |
|---|---|
| Data encryption keys (DEKs) | Annual, or on compromise |
| Key encryption keys (KEKs) | Annual, or on compromise |
| TLS certificates | Annual maximum (automated rotation preferred) |
| API keys and service credentials | 90 days, or on staff departure or compromise |
| SSH keys | Annual, or on staff departure |
Revocation: Keys must be revoked immediately upon: suspected or confirmed compromise, staff departure (for personal keys), or decommissioning of the associated system. Revocation must be logged with timestamp and reason.
Destruction: Keys must be securely destroyed (overwritten or cryptographically erased) when no longer needed. Key destruction must be logged. Backup copies of keys must be destroyed using the same standard.
Data-in-Transit Requirements
All data transmitted over public networks must be encrypted using TLS 1.2 or higher. TLS 1.3 is preferred for new implementations.
Certificates must be signed by a trusted Certificate Authority (CA). Self-signed certificates may be used in internal development environments only, with documented justification.
Protocols transmitting data unencrypted (HTTP, FTP, Telnet) are prohibited for any communication involving confidential or customer data.
Data-at-Rest Requirements
All confidential and customer data stored by [Company Name] must be encrypted at rest using AES-256. Encryption requirements should align with the sensitivity tiers defined in your Data Classification Policy. Encryption must be applied at the storage layer (database encryption, file system encryption, or block storage encryption), not only at the application layer.
Employee endpoints must have full-disk encryption enabled at all times.
Third-party services storing data on our behalf must confirm equivalent encryption standards in their vendor contracts.
Exceptions
Requests for an exception to this policy must be submitted to [Policy Owner / Security Team] for approval before any non-compliant use of cryptography.
Each exception request must document:
| Field | Required content |
|---|---|
| Reason for exception | Why the standard algorithm cannot be used |
| System / scope affected | Which systems or data types are covered by the exception |
| Alternative control | What compensating control mitigates the risk |
| Expiry date | Maximum 12 months; must be reviewed before expiry |
| Risk owner | Named individual accepting residual risk |
Approved exceptions must be recorded in the risk register and reviewed at the next policy review cycle.
Compliance and Enforcement
Any known violations of this policy must be reported to [Policy Owner / Security Team]. Violations include: use of a prohibited algorithm in production, storing plaintext keys in source code, failing to rotate keys on schedule, or implementing custom cryptographic algorithms.
Violations may result in immediate withdrawal or suspension of system access and disciplinary action in accordance with company procedures, up to and including termination of employment.
Review and Version History
This policy must be reviewed at minimum annually. Out-of-cycle reviews are triggered by:
- NIST deprecation of an algorithm referenced in this policy
- A confirmed cryptographic key compromise or security incident
- A major change to the company’s technology infrastructure
- Addition of a new compliance framework with specific cryptographic requirements
- Publication of significant new vulnerabilities in approved algorithms
| Version | Date | Author | Approved by | Summary of changes |
|---|---|---|---|---|
| 1.0 | [Date] | [Author] | [Approver] | Initial version |
Cryptography Policy ISO 27001 Template: What It Must Contain
The template above maps directly to ISO 27001:2022 control 8.24 requirements. The algorithm table, key management lifecycle sections (generation, storage, rotation, revocation, destruction), and prohibited list collectively satisfy what ISO 27001 auditors look for under this control.
Key management section structure follows NIST SP 800-57 Part 1 Rev 5.
Cryptography Policy ISO 27001 PDF: Download Options
A formatted PDF version of this template, ready for signing and including in audit evidence packs, is available for download below. A Word/DOCX version for editing is also available.
Cryptography Policy Example: How a Filled-In Policy Looks
To see what this template looks like when populated for a real company: a 25-person SaaS startup on AWS would fill it in roughly as follows: Policy Owner is the CTO, approved algorithms are AES-256 (data at rest via AWS S3 SSE), TLS 1.3 for all external APIs, RSA-4096 for signing, SHA-256 for hashing. Key management tool is AWS KMS with annual rotation. Prohibited list includes MD5 (removed from codebase in Q2 2023), SHA-1, DES, RC4. No active exceptions.
That level of specificity is what makes the policy useful in an audit, not a generic document with no company-specific content.
How to Write and Roll Out a Cryptography Policy
Assign an owner. Name a specific person, not a team. CISO, CTO, or Head of Engineering. They’re responsible for keeping the policy current and for chasing approvals when it needs to be updated.
Inventory your current cryptographic posture. Before you write requirements, know what you’re actually using. Run an SSL Labs scan on your public endpoints, check your cloud provider’s encryption settings, and ask engineering what algorithms are in use for internal services. This often uncovers surprises.
Identify gaps against your target framework. If you’re going for ISO 27001, measure against control 8.24. If SOC 2, look at what your auditor firm expects for CC9.1. Document gaps now so the policy can address them.
Draft the policy. Use the template above. Customise the algorithm requirements to your actual tech stack. Don’t copy-paste a template and leave it generic: an auditor will notice immediately.
Get legal or DPO review if you handle personal data. GDPR doesn’t prescribe specific algorithms, but encryption is frequently used as a risk mitigation measure under Article 32. Your DPO may have specific requirements.
Obtain senior management approval. This step is often skipped or done informally. It needs to be documented. A signed approval from a named executive, with a date, is what auditors expect to see.
Communicate to all technical staff. Collect acknowledgements. Email the policy to your engineering team. If your GRC tool or HRIS supports policy acknowledgement workflows, use them. If not, a tracked email or Slack message with a read receipt works.
Map to compliance controls. In your GRC tool, link this policy to ISO 27001 8.24, SOC 2 CC9.1, HIPAA § 164.312, or whichever controls apply. This is how auditors trace evidence back to requirements.
Collect baseline evidence. Screenshot your TLS configuration. Export your KMS key list and rotation schedule. Save your algorithm inventory. These are the operational proofs that the policy is being followed.
Set a review reminder. Annual is the minimum. Also set a watch on the NIST algorithm deprecation page. When NIST deprecates something in your policy, you need to know about it before your auditor does.
Cryptography Policy and ISO 27001, SOC 2, and NIST
| Framework | Relevant control | What it requires |
|---|---|---|
| ISO 27001:2022 | Control 8.24 | Documented rules for cryptographic use, key management lifecycle, algorithm approvals |
| SOC 2 | CC9.1, Confidentiality criteria | Risk mitigation controls including encryption of sensitive data; policy evidence expected |
| NIST SP 800-131A | Full document | Defines approved, deprecated, and disallowed algorithms; your policy must align with the current revision |
| FIPS 140-3 | Full standard | Government and regulated sectors must use FIPS-validated cryptographic modules |
| HIPAA | § 164.312(a)(2)(iv), § 164.312(e)(2)(ii) | Encryption of ePHI at rest and in transit; policy satisfies the addressable implementation specification |
ISO 27001 cryptography policy: control 8.24 explained
Control 8.24 sits in Annex A of ISO 27001:2022, previously labelled A.10.1 in the 2013 edition. Its title is “Use of Cryptography” and it covers three areas: rules on where and how cryptography is used, key management from generation through destruction, and alignment with legal and regulatory requirements.
Free Demo
Get an ISO 27001-ready cryptography policy without building it from scratch
ComplyJet ships a cryptography policy pre-mapped to ISO 27001 Control 8.24, SOC 2 CC6.7, and NIST SP 800-57. Covers algorithm selection, key management, and certificate lifecycle.
Auditors will want to see the written policy, evidence it has been approved and communicated, an algorithm inventory showing what’s actually in use, and documented key management procedures. If any of those four are missing, expect a finding.
Common nonconformities I see: the policy references “strong encryption” without specifying algorithms, the key management section only covers storage and not rotation or destruction, or the policy hasn’t been updated since a NIST deprecation.
NIST encryption standards and your policy
NIST SP 800-131A (Transitioning the Use of Cryptographic Algorithms and Key Lengths) is the reference document for which algorithms are currently approved, deprecated, or explicitly disallowed. Your policy’s algorithm table should be reconcilable with the current revision.
NIST SP 800-57 covers key management principles. Your key management section should align with Part 1 Rev 5 of this document, at minimum covering key generation, distribution, storage, usage, archival, and destruction.
FIPS 140-3 applies to cryptographic module validation. If you’re selling to US federal agencies, state/local government, or regulated industries like healthcare or financial services, you may need to use FIPS-validated modules. Check with your customer contracts.
Quantum cryptography policy: preparing for post-quantum standards
In August 2024, NIST finalised its first post-quantum cryptographic standards: ML-KEM (based on CRYSTALS-Kyber), ML-DSA (based on CRYSTALS-Dilithium), and SLH-DSA (based on SPHINCS+). These are designed to resist attacks from large-scale quantum computers.
Most startups don’t need to implement post-quantum algorithms today. Current RSA-4096 and ECDSA P-384 remain safe against classical computers. But if your organisation processes data that needs to remain confidential for 10 or more years (healthcare records, financial data, national security), it’s worth noting a post-quantum migration review in your policy now, rather than scrambling when the timeline becomes urgent.
Your policy can simply state: “The company will monitor NIST’s post-quantum standardisation guidance and conduct a migration readiness review by [year].” That’s enough to show the issue is on your radar.
What Auditors Look for in a Cryptography Policy Review
The written policy is the starting point. But auditors don’t stop there. They want to see that the policy is actually being followed, not just filed somewhere.
| Evidence type | Example |
|---|---|
| Written cryptography policy | Signed document with policy owner, approver, effective date, and version |
| Algorithm inventory | Spreadsheet or GRC tool entry listing encryption in use per system, with algorithm and key length |
| TLS configuration proof | SSL Labs scan export, or server config showing TLS version and cipher suites |
| Key management documentation | KMS key list with creation dates and rotation schedule, or HSM configuration |
| Staff acknowledgement records | GRC acknowledgement log, signed email, or LMS completion record |
| Annual review record | Policy version history showing review date, reviewer, and any changes |
| Exception log | Any approved deviations from the standard algorithm requirements, with expiry dates |
The most common evidence gap is the algorithm inventory. Companies have encryption, but they don’t have a documented list of what’s in use where. An auditor cannot verify your policy is being followed without it.
Cryptography Policy Mistakes That Create Audit Gaps
These are the patterns I see repeatedly, mostly in smaller companies going through their first audit:
Watch out
The most common cryptography audit finding is relying on implicit encryption in cloud services without documenting the controls. "We use S3 with SSE-S3" is a technical fact, not a policy. Your cryptography policy should explicitly state which encryption is applied to which data class and who is responsible for verifying it.
Listing algorithms without key lengths. “We use AES” is not auditable. “We use AES-256 for data at rest and AES-128 is the minimum for legacy systems” is. Auditors need specifics to verify compliance.
No key management section. Policies that define algorithm requirements but say nothing about key rotation, storage, or destruction are incomplete under ISO 27001 8.24. The key management lifecycle is half the control.
Not explicitly banning deprecated algorithms. “Use strong encryption” is meaningless as a policy requirement. You need a named prohibited list: MD5, SHA-1, DES, RC4, 3DES, TLS 1.0, TLS 1.1. If it’s not listed as prohibited, an auditor cannot hold you accountable for using it.
Policy not updated after NIST deprecations. NIST deprecated SHA-1 for most uses in 2011 and completed the deprecation for digital signatures in 2014. I still see policies listing SHA-1 as acceptable. If your policy is from a Vanta or Drata template and hasn’t been reviewed since 2022, check it.
Treating the policy and the encryption standard as the same document. One document that tries to be both is usually either too vague to govern anything or too technical to be reviewed and approved by management. They serve different audiences.
No exception process. Legacy systems, older integrations, and acquired codebases often can’t be upgraded immediately. Without a documented exception process, any deviation from policy looks like non-compliance. With one, it’s managed risk.
Missing review triggers beyond “annual.” A once-a-year review cycle is too slow when NIST deprecates an algorithm mid-year. Your policy’s review section should include specific trigger events: NIST deprecation announcements, key compromises, major infrastructure changes.
Right-Sizing Your Cryptography Policy
Startups running their first audit
Keep it to one document. Approved algorithms table, key management basics (point to your managed key service), prohibited list, named owner, annual review.
Quick tip
At early-stage on AWS: your cryptography policy can be two pages. State your approved algorithms (AES-256 at rest, TLS 1.2+ in transit), your key management approach (AWS KMS), and your certificate rotation cadence (90 days or annual). That covers 90% of what SOC 2 and ISO 27001 auditors need at this stage.
Don’t build a custom key management system. Use AWS KMS, GCP Cloud KMS, or Azure Key Vault. Document that you use it. That covers the key management requirement without needing a separate procedure document.
For post-quantum: one sentence noting you’ll review when NIST migration guidance is finalised is enough. You don’t need a migration roadmap at this stage.
The bar for a startup’s first SOC 2 or ISO 27001 audit isn’t perfection. It’s consistency and documented intent. A short, approved, honest policy is better than a long, generic one that doesn’t reflect what you actually do.
Growing companies scaling their security programme
At this stage, separate the policy from the technical encryption standard. The policy stays at the governance level. The standard document handles algorithm specifics and is updated more frequently by the security or engineering team without requiring board-level approval each time.
Add a formal exception process. Once you have 50+ people and more than a handful of systems, legacy exceptions become real. Document them before an auditor finds them.
Bring your algorithm inventory into your GRC platform. Manual spreadsheets break down as system count grows. Map each policy requirement to specific controls so audit evidence collection is automated.
Larger organisations managing complex key infrastructure
At enterprise scale, key management becomes its own workstream. You’ll need documented key ceremony procedures for key generation events, clear key escrow policies, and potentially HSM deployment for the most sensitive keys.
If you’re selling to US federal agencies or regulated verticals, FIPS 140-3 module validation becomes a requirement, not a nice-to-have. Your policy should reference which validated modules your systems use.
Post-quantum planning needs a named owner and a review schedule tied to NIST’s migration timeline. NIST has indicated that existing RSA and ECC algorithms should be replaced by 2030 in sensitive applications. That’s a real planning horizon for enterprise security teams.
How ComplyJet Keeps Your Cryptography Policy Current
Most compliance tools give you a generic policy template and call it done. The hard part isn’t writing the policy: it’s getting it approved, getting the team to acknowledge it, keeping it mapped to the right controls, and knowing when it needs updating.
ComplyJet ships a pre-built cryptography policy mapped to ISO 27001 control 8.24, SOC 2 CC9.1, HIPAA, and NIST out of the box. Approval workflows and staff acknowledgement tracking are built in, so you’re not chasing email threads. Review reminders fire before your audit, not after.
When NIST deprecates an algorithm, you need to know before your auditor does. ComplyJet flags policy review triggers and keeps your evidence, including TLS configurations, key rotation logs, and acknowledgement records, in one place.
Frequently Asked Questions
What is a cryptography policy?
A cryptography policy is a formal document that defines which encryption algorithms an organisation approves, how cryptographic keys must be managed throughout their lifecycle, and where encryption is required across your systems and data. It governs data at rest, data in transit, key generation, storage, rotation, revocation, and destruction. It’s distinct from your technical implementation: the policy sets the rules, the configuration satisfies them.
Is a cryptography policy required for ISO 27001?
Yes. ISO 27001:2022 control 8.24 explicitly requires documented rules for the use of cryptography and key management. It’s a named Annex A control, which means ISO 27001 auditors will check for it specifically. Absence of a written policy is a nonconformity, not a minor observation.
What encryption algorithms should a cryptography policy require?
At minimum: AES-256 for data at rest, TLS 1.2 (preferably TLS 1.3) for data in transit, SHA-256 for hashing, and RSA-2048 or ECDSA P-256 for asymmetric operations. MD5, SHA-1, DES, RC4, 3DES, and TLS 1.0/1.1 should all be explicitly prohibited. Include specific key lengths, not just algorithm names.
Who is responsible for maintaining a cryptography policy?
Ownership typically sits with the CISO, Head of Engineering, or IT Security Lead. Senior management approves it. In startups, the CTO usually serves as policy owner by default. What matters is that a specific named person is accountable, the policy is approved at an appropriate level, and there’s a process for keeping it updated when NIST changes its guidance.
Does SOC 2 require a cryptography policy?
Not by that exact name. But SOC 2 auditors expect to see documented encryption controls as part of CC9.1 (risk mitigation) and the Confidentiality trust service criteria. A written cryptography policy is the cleanest way to demonstrate those controls exist and are being followed. Without one, you’re relying on auditors taking your word for it.
What NIST standards apply to a cryptography policy?
The three primary references are: NIST SP 800-131A (which algorithms are approved, deprecated, or disallowed), NIST SP 800-57 (key management principles), and FIPS 140-3 (cryptographic module validation, relevant if you sell to government or regulated industries). For post-quantum planning, NIST IR 8413 and the 2024 post-quantum standards (ML-KEM, ML-DSA, SLH-DSA) are the reference documents.
How often should a cryptography policy be reviewed?
Annually at minimum. Beyond that, out-of-cycle reviews should be triggered by: a NIST algorithm deprecation, a confirmed key compromise or security incident, a major change to your technology infrastructure, or the addition of a new compliance framework. Annual reviews are too slow when the threat landscape changes mid-year.
What’s the difference between a cryptography policy and an encryption standard?
A cryptography policy is the governance document: scope, ownership, requirements at a principles level, prohibited practices, and review cadence. An encryption standard is the technical annex: specific algorithm names, exact key lengths, approved cipher suites, and tool names. Larger organisations maintain both separately so the policy can be approved by management without requiring a cryptography background to understand it.
Related Policies
Information Security Policy: The parent policy that establishes the overall security governance framework. The cryptography policy sits beneath it and should reference it for overarching principles.
Data Classification Policy: Encryption requirements vary by data classification tier. The cryptography policy’s data-at-rest requirements should align with the classification tiers defined in your data classification policy.
Identity and Access Management (IAM) Policy: Key management access controls, who can create or access cryptographic keys, and service account permissions are closely related to IAM governance. The two policies overlap on key access control.
