Introduction
The reported theft of billions of dollars in cryptocurrency from Binance is a stark reminder that cybersecurity is not simply an IT issue. It is a fundamental governance, risk management and operational resilience concern for every organisation responsible for safeguarding digital assets, processing financial transactions or providing critical technology services.
On 30 October 2026, Sky News reported that more than $6.3 billion (£4.7 billion) in digital assets had been taken from Binance in what could become the largest cryptocurrency theft to date. The report, citing blockchain intelligence firm TRM Labs, attributed the attack to a North Korean hacking group. Binance’s initial investigation suggested that the incident may have originated with a compromised DevOps engineer’s laptop, although the exchange stressed that the attack involved a more complex process and that investigations were continuing. Deposits and withdrawals were suspended, while more than $3 billion in assets were reportedly frozen.
The full circumstances, extent of the losses and precise attack method will need to be established through further investigation. Nevertheless, the reported incident raises important questions for crypto exchanges, custodians, fintech businesses, technology providers and regulated financial services firms.
How secure are privileged access arrangements? Can an organisation detect and contain a sophisticated attack before assets are moved? Are recovery and continuity arrangements sufficiently robust? And can senior management demonstrate that cyber risks, third-party dependencies and operational vulnerabilities are being properly governed?
These questions sit at the intersection of cybersecurity, the EU’s Digital Operational Resilience Act (DORA), the FCA’s operational resilience framework and independent assurance approaches such as SOC 2.
For businesses operating in or supporting financial services, the incident provides an opportunity to reassess whether their security controls and resilience arrangements are capable of withstanding a serious cyber event.
A Cybersecurity Incident with Wider Implications
The reported Binance incident illustrates how a compromise affecting one part of an organisation’s technology environment can potentially create consequences across an entire financial service.
The initial account of a potentially compromised DevOps engineer’s laptop is particularly relevant. Development and operational technology environments often have access to sensitive systems, deployment processes, infrastructure configurations and privileged credentials. If an attacker gains access through an employee device or a compromised development environment, the consequences may extend far beyond that individual endpoint.
The incident highlights several areas of exposure.
- Privileged Access and Identity Security
Privileged accounts can provide access to systems and functions that ordinary employees cannot use. These may include infrastructure administration, software deployment, cloud environments, transaction processing and security configuration.
If privileged access is not appropriately restricted, monitored and reviewed, a compromised account or device can provide an attacker with a route into critical systems.
Organisations should consider whether they have:
- Multi-factor authentication for privileged and remote access.
- Strict controls over administrator and service accounts.
- Just-in-time or time-limited privileged access where appropriate.
- Regular reviews of access permissions.
- Monitoring of unusual login activity and privileged actions.
- Effective controls for employee devices and remote working environments.
The objective is to prevent a single compromised credential or endpoint from providing unrestricted access to critical infrastructure.
- Software Development and DevOps Security
Development and deployment environments can represent attractive targets because they may connect code repositories, build pipelines, cloud infrastructure and production systems.
Security controls should extend beyond conventional network protection. Organisations should assess the security of source-code repositories, deployment credentials, software dependencies, configuration management and the separation between development, testing and production environments.
A secure software development lifecycle should include appropriate access restrictions, code review, vulnerability management, change approval and monitoring of deployment activity.
- Incident Detection and Containment
The reported movement of large volumes of digital assets across multiple blockchain networks demonstrates the speed at which a cyber incident can develop.
Detection and response arrangements must therefore be capable of identifying suspicious activity quickly and initiating appropriate containment measures.
For digital asset businesses, this may include transaction monitoring, wallet controls, withdrawal restrictions, key management safeguards, blockchain analytics and clearly defined emergency escalation procedures.
The ability to freeze or restrict certain assets may help contain an incident, but it is not a substitute for preventing unauthorised access or having effective recovery arrangements. Nor does freezing assets guarantee that stolen funds will be recovered.
- Business Continuity and Customer Protection
Suspending deposits and withdrawals may be necessary to protect customers during an investigation. However, such restrictions can also disrupt normal business operations and affect customer access to services.
Organisations need to consider how they will maintain essential services, communicate with customers, manage complaints and restore operations safely.
A cyber incident response plan should therefore be connected to business continuity, disaster recovery, customer communications and wider operational resilience arrangements.
DORA: Strengthening Digital Operational Resilience
For financial entities within its scope, the EU’s Digital Operational Resilience Act (DORA) provides a regulatory framework for managing ICT-related risks and maintaining resilience during digital disruption.
DORA has applied since 17 January 2025 and establishes requirements across ICT risk management, incident reporting, resilience testing and ICT third-party risk management. It applies to a range of financial entities specified in the Regulation, including relevant crypto-asset service providers within the EU regulatory framework. Its precise application depends on the entity’s status and activities.
The Binance incident illustrates why these requirements matter.
ICT Risk Management
DORA requires in-scope financial entities to establish and maintain an ICT risk management framework proportionate to their size, risk profile and operational complexity.
This involves identifying critical systems and information assets, assessing vulnerabilities, implementing protective controls and maintaining appropriate detection, response and recovery capabilities.
For a digital asset business, this should include an assessment of:
- Wallet infrastructure and custody arrangements.
- Private key storage and access management.
- Trading and transaction processing systems.
- Cloud infrastructure and development environments.
- Identity and access management.
- Blockchain connectivity and external service dependencies.
- Data integrity, availability and confidentiality.
The framework should be reviewed and improved as the organisation’s technology, business model and threat exposure change.
ICT Incident Management and Reporting
DORA establishes requirements for detecting, managing, classifying and reporting major ICT-related incidents to the relevant competent authority.
Organisations should have clear procedures for identifying incidents, assessing their impact, escalating them internally and determining whether regulatory reporting obligations have been triggered.
A major cyber incident may involve more than a technical failure. It can affect customers, transaction processing, service availability, data integrity and the organisation’s ability to meet its obligations.
Firms should ensure that incident management procedures are integrated with senior management oversight, legal and compliance input, communications and business continuity arrangements.
Digital Operational Resilience Testing
DORA also requires in-scope entities to conduct appropriate digital operational resilience testing. The nature and frequency of testing should reflect the organisation’s risk profile and the applicable requirements.
Testing may include vulnerability assessments, network security testing, scenario-based exercises and other technical assessments. Certain entities are also subject to advanced threat-led penetration testing requirements.
For digital asset businesses, testing scenarios should consider realistic threats such as compromised privileged credentials, malicious software deployment, wallet access compromise, ransomware, cloud service disruption and attacks on critical third-party providers.
The purpose is not simply to identify technical vulnerabilities. It is to establish whether the organisation can detect, contain, respond to and recover from incidents without unacceptable disruption.
ICT Third-Party Risk
DORA recognises that financial entities increasingly depend on external technology providers. Its requirements address the management of ICT third-party risk, including contractual arrangements, ongoing monitoring and exit strategies for services supporting critical or important functions.
This is particularly relevant to businesses relying on cloud infrastructure, custody technology, cybersecurity providers, blockchain analytics, software vendors and outsourced development teams.
A supplier’s security assurances should not be accepted without appropriate assessment. Organisations need to understand the services being provided, the risks created by the arrangement and whether they can maintain operations if the provider becomes unavailable or compromised.
FCA Operational Resilience: Beyond Technology Security
For UK-regulated firms, the FCA’s operational resilience framework provides another important perspective.
The FCA defines operational resilience as the ability of firms, financial market infrastructures and the financial sector to prevent, adapt to, respond to, recover from and learn from operational disruption.
The rules apply to specified categories of firms, including banks, insurers, certain investment firms, payment and electronic money institutions, recognised investment exchanges and qualifying cryptoasset firms. Applicability should be assessed against the relevant regulatory provisions rather than assumed for every business operating in the crypto sector.
Firms within scope were required to complete the relevant mapping and testing work by 31 March 2025, enabling them to remain within their impact tolerances for important business services.
The reported Binance incident provides a useful scenario against which firms can assess their own arrangements.
Important Business Services
Firms should identify the services whose disruption could cause intolerable harm to consumers or market integrity.
For a digital asset business, these may include:
- Safeguarding and custody of customer assets.
- Processing deposits and withdrawals.
- Executing and settling transactions.
- Maintaining access to customer accounts.
- Providing essential platform and trading services.
The identification of important business services should reflect the actual services provided and the potential impact of their disruption.
Mapping Dependencies
The FCA expects firms to understand the people, processes, technology, facilities and information needed to deliver each important business service. This includes internal dependencies and third-party providers.
For a crypto exchange or custodian, mapping may need to cover wallet infrastructure, key management, cloud hosting, identity systems, transaction monitoring, blockchain connectivity, cybersecurity providers and specialist technology suppliers.
Without this understanding, an organisation may struggle to identify where a single point of failure could disrupt an important service.
Impact Tolerances and Scenario Testing
Impact tolerances establish the maximum tolerable level of disruption to an important business service before intolerable harm occurs.
Firms should test whether they can remain within these tolerances during severe but plausible scenarios. A major cyberattack involving compromised privileged access, unauthorised transactions and a suspension of withdrawals would be a relevant scenario for businesses providing digital asset services.
Testing should consider:
- How quickly the attack would be detected.
- Whether affected systems could be isolated.
- Whether customer assets and information could be protected.
- Whether essential services could continue through alternative arrangements.
- How long recovery would take.
- Whether customer and regulatory communications could be maintained.
The objective is to establish whether the firm can respond and recover effectively, not simply whether it has a documented incident response plan.
The FCA’s guidance on outsourcing and operational resilience also makes clear that firms remain responsible for managing risks arising from third-party providers.
SOC 2: Demonstrating That Security Controls Work
While DORA and FCA operational resilience requirements establish regulatory expectations for firms within their respective scopes, SOC 2 offers a different form of assurance.
Developed by the American Institute of Certified Public Accountants (AICPA), SOC 2 is an independent examination of controls against the Trust Services Criteria. These cover Security and, where relevant, Availability, Processing Integrity, Confidentiality and Privacy.
SOC 2 is not a UK regulatory certification and does not replace DORA, FCA requirements or data protection obligations. However, it can help technology providers and service organisations demonstrate to customers how relevant controls are designed and operated.
A SOC 2 Type I report examines the design and implementation of controls at a specified date. A Type II report also examines operating effectiveness over a defined period.
For organisations supporting financial services or digital asset businesses, a SOC 2 examination may provide useful assurance over areas such as:
- Identity and access management.
- Security monitoring and incident response.
- Change management and software development.
- Vulnerability management.
- Data protection and confidentiality.
- Business continuity and availability.
- Supplier and subcontractor controls.
However, a SOC 2 report should be assessed carefully. Customers should examine its scope, reporting period, exceptions and any complementary user entity controls they are expected to operate.
A report covering a technology provider’s general security environment does not necessarily demonstrate that every service, system or customer-specific risk has been examined.
For regulated firms, SOC 2 should therefore form part of a broader third-party assurance and oversight framework.
What Businesses Should Review Now: Seven Practical Priorities
The reported incident provides a timely reason for organisations handling digital assets or supporting financial services to reassess their cyber and operational resilience arrangements.
The following priorities offer a practical starting point.
- Review privileged access and endpoint security. Confirm that administrator accounts, developer access and employee devices are subject to appropriate restrictions, authentication and monitoring.
- Assess wallet and key management controls. Review how private keys are generated, stored, accessed and protected. Consider segregation of duties, approval mechanisms, recovery arrangements and monitoring of unusual transactions.
- Test incident response arrangements. Conduct realistic exercises involving compromised credentials, unauthorised transactions, ransomware and the loss of critical systems. Confirm that escalation and decision-making responsibilities are understood.
- Reassess third-party and cloud dependencies. Identify critical providers, understand their role in delivering important services and assess the consequences of their failure or compromise.
- Review operational resilience mapping and impact tolerances. Confirm that important business services, dependencies and recovery arrangements remain accurate and that scenario testing reflects current threats.
- Evaluate assurance and control evidence. Consider whether SOC 2 reports, penetration tests, vulnerability assessments and internal control reviews provide sufficient evidence for the risks being managed. Identify gaps that require additional testing.
- Strengthen governance and management information. Ensure that senior management receives meaningful reporting on cyber risks, incidents, vulnerabilities, testing results and overdue remediation. Significant weaknesses should be escalated and addressed promptly.
These activities should be prioritised according to the organisation’s risk exposure, regulatory obligations and the potential harm arising from disruption.
The Importance of Integrated Cybersecurity and Compliance Governance
One of the key lessons from major cyber incidents is that security cannot be managed in isolation.
Technology teams may be responsible for implementing technical safeguards, but senior management remains accountable for ensuring that risks are understood, appropriate resources are available and effective controls are maintained.
Compliance and risk functions have an important role in challenging the adequacy of arrangements, assessing regulatory implications and ensuring that issues are escalated appropriately.
An integrated approach should connect:
- Cybersecurity strategy and information security governance.
- Enterprise and operational risk management.
- Regulatory compliance and incident reporting.
- Third-party and outsourcing oversight.
- Business continuity and disaster recovery.
- Operational resilience testing.
- Independent assurance and remediation.
This helps prevent gaps between technical security arrangements and the organisation’s wider regulatory and operational responsibilities.
It also provides a more coherent basis for demonstrating control effectiveness to regulators, customers, investors and other stakeholders.
How Complyport Can Help
The reported Binance incident reinforces the importance of a coordinated approach to cybersecurity, regulatory compliance and operational resilience. Complyport supports financial services firms, fintech businesses and organisations operating in or supporting the digital asset sector through practical compliance, governance and risk management services.
Relevant areas of support include:
- Cybersecurity Governance and Risk Management: Reviewing information security governance, identifying control weaknesses and strengthening cybersecurity policies, procedures and oversight arrangements.
- DORA Compliance and Readiness: Assessing ICT risk management frameworks, incident management, resilience testing and third-party risk arrangements against applicable DORA requirements.
- FCA Operational Resilience: Supporting the identification of important business services, dependency mapping, impact tolerances and severe but plausible scenario testing.
- SOC 2 Readiness: Reviewing existing controls, identifying gaps and strengthening control documentation and evidence collection ahead of an independent SOC 2 examination.
- Third-Party Risk and Outsourcing: Assessing technology provider risks, reviewing supplier governance and due diligence arrangements, and strengthening ongoing oversight of critical third parties.
- Compliance Monitoring and Independent Reviews: Conducting targeted reviews of governance, policies, procedures and control effectiveness, with practical recommendations and remediation plans.
Complyport can tailor its support to an organisation’s regulatory status, business model, technology dependencies and existing control environment.
Discover Complyport.tech
Strengthening cybersecurity and operational resilience requires the right governance, controls and ongoing oversight.
Discover how Complyport can support your compliance needs. Visit https://complyport.tech/ to learn more about our RegTech solutions.
