For a crypto firm seeking to do business with institutional counterparties, the question of whether to pursue ISO 27001 certification has largely answered itself. The standard, formally titled ISO/IEC 27001, is the globally recognised benchmark for information security management. In the crypto sector, it is becoming a baseline requirement for custody partnerships, exchange listings, enterprise integrations, and regulated financial relationships. Firms without it are increasingly excluded from conversations before they begin.
This post explains what ISO 27001 is, why it matters specifically for crypto and Web3 organisations, how to scope and implement an information security management system for this context, and how to navigate the certification process. It is written for founders, CISOs, and security directors who need to understand what committing to this standard actually requires.
What is ISO 27001?
ISO/IEC 27001 is an international standard published jointly by the International Organisation for Standardisation (ISO) and the International Electrotechnical Commission (IEC). It specifies the requirements for establishing, implementing, maintaining, and continually improving an information security management system (ISMS): a systematic, risk-based approach to managing information security across an organisation.
A critical point that many organisations misunderstand at the outset: ISO 27001 is not a technical standard. It does not specify which technologies to deploy, which encryption algorithms to use, or which architecture to implement. It is a management system standard. Its focus is on governance: how does the organisation identify its information security risks, make decisions about treating them, implement and monitor controls, and continuously improve? The technical controls are largely contained in Annex A, but their implementation is driven by a risk assessment process, not a prescriptive checklist.
The most recent version, ISO 27001:2022, replaced the 2013 edition. The 2022 update restructured Annex A from 114 controls across 14 categories to 93 controls across four themes: Organisational controls (37), People controls (8), Physical controls (14), and Technological controls (34). Eleven new controls were introduced, several of which are directly relevant to crypto and Web3 operating environments.
Why Crypto Firms Need ISO 27001 Certification
The case for ISO 27001 in crypto is not theoretical. It is playing out in commercial and regulatory contexts that affect revenue and access to market.
Institutional counterparty requirements. Banks, asset managers, family offices, and regulated fund vehicles that wish to engage with crypto firms are increasingly requiring ISO 27001 as a baseline trust credential before proceeding with due diligence. For a crypto custodian, prime broker, or infrastructure provider targeting institutional clients, the absence of certification can be a disqualifying factor in procurement processes.
Exchange listing and integration criteria. Major exchanges and DeFi protocol operators conducting third-party integrations have begun incorporating security certification requirements into their technical partner criteria. The argument is straightforward: if a third-party integration introduces operational or security risk, the integrating party bears reputational exposure. ISO 27001 provides a structured basis for assessing that risk.
Regulatory alignment. MiCA requires crypto asset service providers to demonstrate robust governance and risk management. DORA imposes ICT risk management requirements on financial entities in scope. Neither regulation mandates ISO 27001, but both are substantially easier to satisfy for a firm that already operates a certified ISMS. Regulators and their supervisors increasingly view ISO 27001 as evidence of a credible baseline.
Insurance and liability. Cyber insurance underwriters apply significantly different criteria to firms with and without documented, audited security management systems. ISO 27001 certification is increasingly a factor in premium calculation and coverage eligibility for crypto-sector policies.
"ISO 27001 is not a compliance exercise. It is a structured commitment to managing information security risk systematically, continuously, and with demonstrable governance. For a crypto firm, that distinction determines whether it becomes a trusted institutional counterparty or remains perpetually excluded."
ISO 27001:2022 Controls Most Relevant to Web3
The eleven new controls introduced in the 2022 update map closely to the risk landscape of Web3 firms. Understanding which controls carry the most weight in a crypto context is essential for scoping the implementation effort accurately.
A.5.7 Threat intelligence requires the organisation to collect, analyse, and act on information about information security threats. For a crypto firm, this means structured consumption of on-chain threat data, blockchain forensics feeds, dark web monitoring, and intelligence about threat actor targeting patterns. Our coverage of Lazarus Group targeting of crypto firms illustrates precisely the type of threat intelligence that would feed this control.
A.5.23 Information security for use of cloud services addresses the governance of cloud service usage, including selection, usage, management, and exit from cloud services. For crypto firms that deploy nodes, APIs, or infrastructure on cloud platforms, this control requires formal policies and procedures governing cloud security configuration, access management, and data protection.
A.7.4 Physical security monitoring requires monitoring of physical premises for unauthorised access. For any firm with physical key storage, hardware security module installations, or server infrastructure, this control is directly applicable. HSM security, discussed in our post on hardware security modules for crypto, represents a primary physical security consideration.
A.8.8 Management of technical vulnerabilities requires a systematic approach to identifying, assessing, and remediating technical vulnerabilities. This aligns directly with a structured vulnerability management programme for Web3 infrastructure.
A.8.28 Secure coding requires the organisation to apply secure coding principles to software development. For Web3 firms developing smart contracts or protocol-level code, this control connects to the blockchain security audit process and the secure development lifecycle.
Beyond the new controls, several established controls carry particular weight for crypto firms. A.8.5 Secure authentication and A.5.15 Access control underpin the privileged access management requirements that are critical given concentrated key custody. A.6.8 Information security event reporting and A.5.26 Response to information security incidents connect directly to the incident response plan that every crypto firm must maintain. A.5.19 through A.5.22 govern information security in supplier relationships, which is the foundation of a vendor risk management programme.
Scoping Your ISMS for a Crypto Organisation
The scope of an ISMS defines which parts of the organisation, which assets, and which processes fall within the certification boundary. Scoping decisions have a significant impact on the complexity and cost of both implementation and annual surveillance audits. Getting scope right at the outset is one of the most consequential decisions in an ISO 27001 project.
For a crypto firm, the following assets and processes should almost always be included in scope:
Key management systems. Any system involved in generating, storing, distributing, or using cryptographic private keys is central to the firm's information security risk profile. This includes HSMs, multi-party computation infrastructure, hardware wallets used in a custodial capacity, and the procedures governing key ceremonies and access authorisation.
Node infrastructure. Validator nodes, archive nodes, RPC endpoints, and similar blockchain infrastructure represent both operational assets and potential attack surfaces. Their configuration management, access controls, and monitoring must be within scope.
Developer workstations. Developers with access to production codebases, deployment credentials, or signing keys represent a significant risk vector. Workstation security, including endpoint protection, disk encryption, and access policies, must be scoped in.
Third-party integrations. Any third-party service that has access to, or can influence, the firm's information assets should be addressed within the ISMS scope. This does not necessarily mean auditing the third party, but it does mean having documented policies and controls governing those relationships.
Reasonable exclusions from scope might include entirely separate legal entities, research and development activities with no production access, or marketing functions with no access to sensitive systems. However, any exclusion must be justified and documented, and the auditor will scrutinise exclusions that appear to be scope-narrowing exercises designed to simplify certification rather than genuine operational boundaries.
The Certification Process Step by Step
The ISO 27001 certification process follows a structured sequence. Each stage has distinct deliverables and readiness requirements.
1. Gap assessment. The starting point is an honest assessment of the organisation's current state against ISO 27001 requirements. A gap assessment identifies which clauses and controls are already addressed, partially addressed, or absent. The output is a prioritised remediation plan. This stage typically takes two to four weeks for a firm of 10 to 50 people.
2. ISMS design. The gap assessment informs the design of the ISMS: defining the scope, the information security policy, the risk assessment methodology, the risk treatment plan, and the Statement of Applicability (SoA). The SoA is a critical document: it lists all 93 Annex A controls and states, with justification, whether each is applicable to the scope and whether it is implemented. Designing the ISMS typically takes four to eight weeks.
3. Implementation. Controls are implemented according to the risk treatment plan. This is the most resource-intensive phase: writing and deploying policies, procedures, and technical controls across people, processes, and technology. For a crypto firm, this phase typically takes three to six months, depending on the volume of remediation required and the capacity of internal resource allocated to the project.
4. Internal audit. Before inviting the certification body, the organisation must conduct a formal internal audit of the ISMS. The internal audit assesses whether the management system is operating as documented and conforming to ISO 27001 requirements. Findings must be addressed and documented. The internal audit should be conducted by someone independent of the areas being audited.
5. Management review. Senior management must formally review the ISMS, considering audit results, risk treatment status, performance metrics, and any changes to the internal or external context. The management review output must be documented and demonstrates to the certification body that leadership is engaged with and accountable for the ISMS.
6. Stage 1 audit (documentation review). The chosen certification body conducts an initial audit, primarily reviewing the ISMS documentation: the scope, the risk assessment, the SoA, policies, and procedures. The Stage 1 audit identifies any areas of concern before the on-site assessment. Minor nonconformities at Stage 1 can typically be addressed without delaying Stage 2.
7. Stage 2 audit (certification audit). The certification body conducts an on-site (or remote) assessment of whether the ISMS is effectively implemented and operating. Auditors will interview staff, review evidence of control operation, and test whether documented procedures are actually followed. Any major nonconformities identified at Stage 2 must be resolved before certification is granted.
8. Certification and surveillance. Following a successful Stage 2 audit, the certification body issues the ISO 27001 certificate, valid for three years. Annual surveillance audits are required in years one and two, and a full recertification audit is required at year three. The surveillance audits are typically shorter than the initial certification audit but require evidence that the ISMS continues to operate effectively.
Common Failure Points
ISO 27001 projects fail in predictable ways. Understanding these patterns is worth more than any amount of documentation template.
Underestimating scope complexity. Crypto firms frequently define a narrow initial scope to reduce effort, then discover during the Stage 1 audit that the certification body considers the exclusions unjustified. Auditors are experienced at identifying scope boundary decisions that appear designed to avoid inconvenient controls rather than reflect genuine operational boundaries. A well-justified, honest scope is more defensible than a narrowed one.
Treating it as a documentation exercise. The most common failure mode is producing policies and procedures that describe how security should work without implementing the underlying controls. Certification body auditors are specifically trained to identify document-only compliance: they interview staff at all levels to test whether documented procedures are understood and followed, and they review evidence logs to confirm controls actually operate. A beautifully formatted policy set that nobody reads or follows will not pass Stage 2.
Insufficient management commitment. ISO 27001 Clause 5 places specific requirements on top management, including establishing the information security policy, ensuring ISMS objectives are aligned with strategic direction, and demonstrating leadership and commitment. If the CISO or security manager is running the project without visible leadership engagement, the management review documentation will be thin, the internal audit findings will not receive adequate resource for remediation, and the certification body will identify leadership commitment as a weakness.
Not embedding the ISMS in operations. The ISMS is not a separate compliance function; it is a management system that should govern how the organisation makes decisions about information security. Firms that operate the ISMS as a parallel activity disconnected from day-to-day decisions find themselves unable to demonstrate continuous improvement and find surveillance audits increasingly difficult as the gap between documented and actual practice widens.
ISO 27001 vs SOC 2
The comparison between ISO 27001 and SOC 2 is a common discussion in crypto security, and the answer depends primarily on the markets the firm is serving.
ISO 27001 is an internationally recognised management system standard. Certification is granted by accredited certification bodies and is globally understood as evidence of a systematic approach to information security management. It carries weight in European, Asian, and Middle Eastern institutional markets, and is the natural credential for firms seeking to demonstrate compliance with frameworks that reference ISO standards, including DORA.
SOC 2 is a US-based attestation report produced under the AICPA's Trust Services Criteria. It reports on controls relevant to security, availability, processing integrity, confidentiality, and privacy, based on an audit conducted by a licensed US CPA firm. SOC 2 is the primary trust credential in the US market and is commonly required by US venture-backed companies and their investors.
The two standards address overlapping ground but are not equivalent. ISO 27001 is a certification (pass/fail based on whether the management system meets the standard). SOC 2 is an attestation report (the auditor reports on the state of controls, which may be clean or may include exceptions). Many crypto firms targeting global institutional clients pursue both. The implementation overlap is substantial: a firm with a well-implemented ISO 27001 ISMS will find SOC 2 a materially easier exercise, as much of the required documentation, control evidence, and audit trail will already exist.
ISO 27001 and DORA Alignment
The relationship between ISO 27001 and DORA is one of significant structural alignment, and firms navigating both should plan their programmes to exploit that overlap explicitly.
DORA's ICT risk management framework (Chapter II) requires financial entities to maintain an ICT risk management framework that is documented, approved by the management body, reviewed at least annually, and covers risk identification, protection, detection, response, and recovery. The ISO 27001 ISMS, at its core, is precisely such a framework. A certified ISO 27001 ISMS provides audited evidence of a functioning risk management approach that maps directly to DORA's Chapter II requirements.
DORA's ICT-related incident management requirements (Chapter III) require documented incident classification, detection, reporting, and escalation procedures. ISO 27001 Annex A controls A.5.24 to A.5.27 cover information security incident management from planning through post-incident learning. The incident response plan required by our incident response guidance serves both frameworks.
DORA's digital operational resilience testing requirements (Chapter IV) require regular testing of ICT systems. ISO 27001 requires regular reviews, internal audits, and management reviews of the ISMS, as well as testing of business continuity and disaster recovery arrangements. The two requirements reinforce rather than duplicate each other.
For firms subject to both DORA and seeking ISO 27001 certification, the recommended approach is to design the ISMS scope and risk treatment plan with DORA requirements in view from the outset. Our detailed guides on DORA compliance and MiCA compliance provide the regulatory context needed to ensure the ISMS design covers both sets of requirements without unnecessary duplication.
The zero trust security architecture that underpins modern Web3 security programmes aligns naturally with the ISO 27001 access control and network security controls. Implementing zero trust principles during the ISMS implementation phase creates technical controls that serve both the ISO certification and the operational security posture simultaneously.
Timeline and Cost
Realistic planning requires honest estimates. The following applies to a crypto firm of 10 to 50 people with a defined scope covering core operations.
Timeline. From gap assessment to certification, the realistic range is 9 to 12 months for a firm starting from a low base. Firms with mature security controls and existing documentation can achieve certification in 6 to 9 months. Timeline is most commonly extended by three factors: slow internal decision-making on scope, insufficient resource allocated to implementation, and remediation backlogs that delay the internal audit.
Internal resource. ISO 27001 implementation is not a task that can be outsourced entirely. A project lead who understands both the standard and the firm's operations is required. For a firm of 10 to 50 people, expect the equivalent of 0.5 to 1.0 FTE of internal resource commitment over the implementation period, in addition to time from process owners and management for interviews, reviews, and training.
External costs. These include the gap assessment (typically conducted by a consultant), any policy and procedure development support, the certification body fees for Stage 1 and Stage 2 audits, and ongoing surveillance audit fees. For a firm of this size, total certification body fees for the initial three-year cycle typically range from £15,000 to £35,000, depending on the scope complexity and the certification body selected. Consulting support for an under-resourced implementation can add significantly to this figure.
Certification body selection. Certification bodies must be accredited by the national accreditation body in their jurisdiction (UKAS in the UK, DAkkS in Germany, ANAB in the US). Accreditation matters: certificates issued by unaccredited bodies are not recognised by many institutional counterparties or regulators. Choosing a certification body with demonstrable experience auditing technology and financial services firms will result in a more technically rigorous and credible process.
The investment is material. For most crypto firms pursuing institutional business, it is also unavoidable. The decision is not whether to certify, but when to start and how to resource the project so that the first attempt succeeds.
Frequently Asked Questions
What is ISO 27001 certification?
ISO 27001 is the international standard for information security management systems (ISMS). Certification demonstrates that an organisation has implemented a systematic, risk-based approach to managing information security, covering people, processes, and technology. It is awarded by accredited third-party certification bodies following a two-stage audit.
Why do crypto firms need ISO 27001 certification?
Institutional clients, exchange listings, enterprise Web3 partnerships, and regulated counterparties increasingly require ISO 27001 as evidence of baseline security maturity. It is becoming a de facto trust credential in the B2B crypto market, particularly for firms seeking to serve regulated financial institutions or to qualify as counterparties in custody and prime brokerage arrangements.
How long does ISO 27001 certification take for a crypto firm?
For a crypto firm of 10 to 50 people starting from scratch, the realistic timeline is 9 to 12 months from gap assessment to certification. Firms with existing security controls and documentation may achieve certification in 6 to 9 months. The timeline depends heavily on scope definition, management commitment, and the pace of remediation.
What is the difference between ISO 27001 and SOC 2?
ISO 27001 is an internationally recognised standard awarded through certification and valid globally. SOC 2 is a US-focused attestation report based on the AICPA Trust Services Criteria, primarily relevant for US clients and partnerships. Both address information security, but ISO 27001 is a prescriptive management system standard while SOC 2 is a report on controls at a specific point in time or over a period. Many crypto firms pursuing global institutional business seek both.
How does ISO 27001 support DORA compliance?
DORA references ISO standards extensively in its technical standards, and the ISO 27001 ISMS provides a structured foundation for the ICT risk management framework DORA requires. Firms with a certified ISO 27001 ISMS have already implemented many of the governance, documentation, monitoring, and review requirements DORA demands, significantly reducing the incremental effort required for DORA compliance.