$1,000,000 in security audit grants are live now, Apply here →
Services · Regulatory & Compliance

Regulators examine the system, not the policy.

MiCA, DORA, NYDFS and the GENIUS Act each ask, in their own words, whether your keys, systems, vendors and recovery hold up on a bad day. Guardian assesses you against the provisions that actually apply, one citation at a time, and hands over evidence a supervisor can trace back to the running system.

  • Regulatory readiness
  • Cybersecurity maturity
  • Operational resilience
  • Technical evidence
One control seven citations
THE CONTROL MFA ON EVERY PRIVILEGED PATH TESTED ONCE THE EVIDENCE IdP export, plus a bypass attempt, dated WHERE IT IS REQUIRED Part 500.12 NYDFS Art. 9(4)(d) DORA 16 CFR 314.4(c)(5) FTC Cyber Hygiene 4.6 MAS Annex A 8.5 ISO 27001 PR.AA-03 NIST CSF 2.0 CC6.1 SOC 2 One test. One artefact. Seven provisions answered.

Seven rulebooks, one requirement: nobody reaches a privileged system with a password alone. Guardian tests it once and maps the evidence to every provision that asks for it.

01 · Regulatory Readiness Assessment

Know which provisions apply before a supervisor asks.

Authorisation files and supervisory reviews now ask for technical detail: how client assets are safeguarded, how ICT risk is governed, how incidents are classified and reported, and which third parties you cannot run without. Guardian works out which provisions reach your business, tests where you stand against each one, and closes the gaps in the order an application or an examination will read them.

Start a readiness assessment
  • Applicability, by activity and market Your activities, legal entities and customer locations mapped to the regimes and licences that reach them: MiCA authorisation as a CASP or token issuer, a BitLicense, a payment stablecoin issuer, a MAS or SFC licence, a VARA licence. Confirmed with your counsel, who owns the legal reading.
  • A gap assessment, one citation at a time Every technology, security, custody and resilience provision listed by citation, with the control that meets it, the evidence that proves it, and the gap where neither exists yet.
  • Custody and safeguarding Segregation, key generation and storage, signing thresholds, cold storage ratios and recovery, assessed against the custody rules your licence carries.
  • The technical sections of your application The ICT, security, custody and continuity descriptions an authorisation file has to contain, written from the system as built, so they survive the follow-up questions.
  • A remediation plan in examination order Gaps sequenced by what blocks authorisation, what an examiner will test first, and what can wait, each with an owner and a date.
Readiness by provisioncited, not summarised
CITATION PROVISION STATUS MiCA Art. 70 Client assets safeguarded MiCA Art. 75 Custody policy, client register DORA Art. 19 Major incident filed in window DORA Art. 28 Register of ICT third parties NYDFS 500.12 MFA on every privileged path GENIUS Act Freeze and burn on lawful order 23 PROVISIONS IN SCOPE met 14 partial 6 gap 3

An application is read as a whole. One open provision on custody can hold up an authorisation that is otherwise complete, so the register is kept at the level the supervisor reads it.

$45B+In digital assets secured across Guardian engagements
300+Critical vulnerabilities reported and resolved
150+Teams trusting Guardian with their contracts
25+Global security competition wins
02 · Cybersecurity Maturity Assessment

A maturity score built from tests, not a questionnaire.

Most maturity assessments are interviews scored on a spreadsheet, and they flatter whoever answers them. Guardian scores the program from what the systems show: identity provider exports, signer inventories, pipeline settings, cloud configuration, and the results of our own testing. You get a current and a target profile against NIST CSF 2.0, the ISO 27001 and CCSS controls behind every score, and a plan that moves the number.

Score your program
CSF 2.0 profilecurrent vs target
FUNCTION TIER 1 TIER 2 TIER 3 TIER 4 GOVERN IDENTIFY PROTECT DETECT RESPOND RECOVER supported by evidence target profile

Each bar is the tier the evidence supports, not the tier the policy describes. The distance from each bar to its target line is the roadmap.

  • NIST CSF 2.0 profile Current and target tier for each of the six functions, Govern, Identify, Protect, Detect, Respond and Recover, scored at the level of the subcategories beneath them.
  • ISO/IEC 27001:2022 The 93 Annex A controls assessed for design and for operation, so certification readiness falls out of the assessment rather than becoming a second project.
  • CCSS for key management Key generation, storage, use, compromise response and keyholder grant and revoke, levelled against the CryptoCurrency Security Standard.
  • Verified, not attested Every score is backed by evidence Guardian collected or a test Guardian ran. A control that is written down but not enforced scores as absent.
  • Reporting for the board and the regulator The program stated for a board, and in the shape regimes ask for it, such as the CISO's annual written report under NYDFS 500.4 and the management body's ICT risk accountability under DORA Art. 5.
  • A roadmap that moves the score The shortest path from current to target profile, sequenced by risk removed per week of effort, with an owner on every step.
03 · Operational Resilience Assessment

Decide how long you can be down before an incident decides for you.

DORA, the UK regime, MAS and APRA ask one question in four vocabularies: which services matter most, how much disruption each can tolerate, and what shows you can stay inside that limit in a severe but plausible scenario. Onchain businesses carry dependencies those rules never pictured: RPC providers, bridges, oracles, custodians, and signers spread across time zones. Guardian maps them and tests them.

Test your resilience
  • The services that matter most Named the way each regime names them: critical or important functions under DORA, important business services in the UK, critical business services under MAS, critical operations under APRA.
  • Impact tolerances and recovery objectives The most disruption each service can absorb, set as a time and a scale, with recovery time objectives the infrastructure can actually meet.
  • Dependency mapping, onchain included The people, processes, technology, facilities, data and third parties behind each service, including the chains, RPC endpoints, oracles, bridges and custodians it cannot run without.
  • Severe but plausible scenarios Key compromise, a signer quorum that cannot be reached, a custodian or cloud region outage, an oracle failure, a chain halt and a depeg, exercised as tabletops and as technical tests.
  • Incident classification and reporting The reporting clocks you are subject to, the criteria that start each one, and a rehearsed path to file on time with every regulator at once.
  • Third parties, concentration and exit Your register of ICT third parties, the contract terms regulators require, concentration risk, and an exit plan tested against the vendor you depend on most.
  • Backups and key recovery, performed Restores and key recovery carried out and timed against the recovery objective, not inferred from a backup schedule.
One incident, many clocksfirst notice
REGIME NOTICE HOURS, LOG SCALE FIRST 24 HOURS MAS 1 h DORA 4 h NIS2 24 h US BANKS 36 h NYDFS 72 h GDPR 72 h FTC 30 d 0 1h 4h 24h 72h 30d Six of these seven first notices fall due inside three days. DORA then asks for 72 hour and one month reports.

Each clock starts at a different moment: discovery, classification, or a determination that the incident is reportable. The playbook has to know which, before it is needed.

04 · Technical Evidence

Evidence a supervisor can trace back to the system.

A regulator, an auditor, a bank partner or an exchange listing team will not accept a policy as proof that a control works. They accept artefacts: a pentest with its retest, a signer inventory read from the chain, an access review exported from the identity provider, a restore that was timed. Every Guardian engagement already produces them. Technical Evidence collects them, keeps them current, and maps each one to the provisions it answers, so the next request is a link rather than a fortnight.

Build your evidence pack
From engagement to citationanswered once
ENGAGEMENT audits pentests managed security risk monitoring detection (MDR) assessments EVIDENCE PACK ANSWERS MiCA · DORA NYDFS · GENIUS MAS · SFC · VARA FCA · PRA ISO 27001 · SOC 2 partner DDQs EVERY ARTEFACT CARRIES its scope, the commit or date it was produced at, and the provisions it answers.

Each asker gets the same answer, assembled once, instead of a different answer assembled by a different engineer in a week meant for shipping.

  • Mapped to the citation Every artefact is tagged with the provisions it evidences, so a reviewer working through DORA or Part 500 finds their article and the proof beside it.
  • Dated and versioned Each artefact carries its scope and the commit or date it was produced at, and is replaced when the system changes, so nothing in the pack describes a system you no longer run.
  • Residual risk, stated Open findings and accepted risks listed with the owner and the reason. A pack that admits something is trusted far more than one that claims everything is closed.
  • Shared on your terms Delivered as a pack or a trust center page, scoped to its reader: a supervisor, an exchange listing team, a bank partner, an allocator.
  • Questionnaires answered once Due diligence questionnaires answered from the same evidence, so every answer agrees with every other one.

The evidence ledger

What each Guardian service leaves behind, and the provisions every artefact answers.

Source A · Onchain

Smart contract audits and Vanguard

Manual review by independent teams, fuzzing and invariant suites, and update review after launch.

Audits & Pentests
  • Audit report with fix review

    Findings by severity, the remediation for each, and a fix review at a pinned commit, with the scope and lines of code stated.

    • MiCA RTS 2025/305 Art. 9
    • DORA Art. 25
    • OCC 12 CFR 15.13(b)
    • HKMA Guideline 6.5.5
    • SFC VATP 7.10
    • VARA Rule I.E.1
    • ADGM Guidance 33
    • ISO 27001 A.8.29
  • Invariant and fuzzing suite

    Executable safety properties run against every reachable state, with the results and a regression harness you keep and rerun on every change.

    • OCC 12 CFR 15.13(b)
    • DORA Art. 25
    • NIST CSF PR.PS-06
    • ISO 27001 A.8.29
    • CCSS 2.01
  • Privileged role and upgrade path map

    Every role that can move value, upgrade, pause, freeze or change parameters, with its holder, threshold and timelock, read from the deployed contracts.

    • HKMA Guideline 6.5.3, 6.5.4
    • GENIUS Sec. 4(a)(6)
    • DORA Art. 9(4)
    • NYDFS 500.7
    • ISO 27001 A.8.2
    • NIST CSF PR.AA-05
  • Deployment verification

    Deployed bytecode matched to the audited commit, and live configuration checked against what was reviewed.

    • DORA Art. 9(4)(e)
    • HKMA Guideline 6.5.5
    • SOC 2 CC8.1
    • ISO 27001 A.8.32
Source B · Offchain

Penetration tests

Infrastructure, web app, API, browser extension, SDK and offchain automation, each closed out with a retest.

Pentests
  • Penetration test report with retest

    Every finding reproduced, ranked by what reaching it would do, and retested after the fix, with the scope and test window stated.

    • NYDFS 500.5
    • NYDFS 200.16(e)
    • FTC 314.4(d)(2)
    • DORA Art. 25
    • MAS TRM 13.2
    • SFC VATP 12.13
    • VARA Rule I.E.1
    • ADGM GEN 3.5.14
    • APRA CPS 234 para. 27
    • PCI DSS 11.4
  • Cloud and infrastructure configuration review

    Cloud accounts, secrets, CI/CD, containers and vendor consoles checked against the hardening standard they are meant to meet.

    • MAS Cyber Hygiene 4.3
    • DORA RTS 2024/1774
    • NYDFS 500.15
    • SFC VATP 12.12
    • CIS Control 4
  • Signing and automation review

    Threshold signing services, keepers and bots reviewed for key scoping, input integrity and how they fail.

    • CCSS 1.05
    • UK CASS 17.4
    • MAS PS-G03 3.4.5
    • VARA Rule III.C.2
    • HKMA Guideline 6.5.7
Source C · Operations

Managed Security

Operational controls held by the Sentry platform and checked continuously against evidence from the systems you run.

Managed Security
  • Operational control register

    118 controls across keys, multisig, access, change, release, infrastructure, secrets, incident readiness and devices, each with an owner and its current state.

    • NYDFS 500.2, 500.3
    • DORA Art. 6
    • ADGM GEN 3.5.1
    • APRA CPS 234 para. 21
    • ISO 27001 Annex A
    • SOC 2 CC4.1
  • Access reviews and MFA coverage

    Who can reach what, exported from the identity provider and cloud accounts, with MFA coverage and the accounts removed since the last review.

    • NYDFS 500.7, 500.12
    • FTC 314.4(c)(1), (c)(5)
    • DORA Art. 9(4)
    • MAS Cyber Hygiene 4.1, 4.6
    • ADGM GEN 3.5.8
    • SOC 2 CC6.1, CC6.2
    • ISO 27001 A.8.5
  • Key custody and multisig records

    Signer inventory, thresholds and timelocks read from the chain, key ceremony and recovery records, and the verification of every transaction before it is signed.

    • MiCA Art. 75(3)
    • UK CASS 17.4.8R
    • NYDFS 200.9
    • MAS PS-G03 3.4
    • SFC VATP 10.8
    • VARA Rule I.D
    • CCSS 1.03, 1.04, 1.05
  • Change and release evidence

    Branch protection, review gates, deployment approvals and environment separation, read from the pipeline rather than the policy.

    • DORA Art. 9(4)(e)
    • HKMA TM-G-1 4.3.1
    • SOC 2 CC8.1
    • ISO 27001 A.8.32
  • Incident readiness and exercise records

    The incident plan, who holds each role, and dated tabletop and technical exercises with the lessons taken from them.

    • NYDFS 500.16
    • DORA Art. 11(6)
    • FTC 314.4(h)
    • APRA CPS 234 para. 26
    • ADGM GEN 3.5.16
    • SOC 2 CC7.4
Source D · Exposure

Risk Monitoring and Ratings

Continuous discovery of the internet-facing estate and deployed contract configuration, verified by hand and scored.

Risk Monitoring & Ratings
  • Asset inventory

    Domains, hosts, services, cloud assets and deployed contracts, discovered continuously, each with an owner.

    • NYDFS 500.13
    • DORA RTS 2024/1774
    • ADGM GEN 3.5.4
    • APRA CPS 234 para. 20
    • NIST CSF ID.AM-01
    • ISO 27001 A.5.9
    • CIS Controls 1, 2
  • Verified exposure findings with retest

    Exposed services, data and known vulnerabilities, confirmed by hand, ranked by reach, and retested once fixed.

    • NYDFS 500.5
    • FTC 314.4(d)(2)
    • SOC 2 CC7.1
    • ISO 27001 A.8.8
    • CIS Control 7
    • PCI DSS 11.3
  • Contract configuration drift

    Deployed parameters, roles and upgrades compared with the configuration that was reviewed, every change dated.

    • OCC 12 CFR 15.13(b)
    • HKMA Guideline 6.5.3
    • DORA Art. 9(4)(e)
    • SOC 2 CC7.1
  • Security rating history

    A derived score that breaks down into its findings, tracked over time and shareable with partners.

    • NYDFS 500.4
    • DORA Art. 5
    • VARA CRM I.D.5
    • SEC S-K Item 106(b)
  • Registrar, DNS and frontend integrity

    Registrar locks, DNS records and the delivery path to your users, watched for change.

    • DORA Art. 10
    • NIST CSF DE.CM-01
    • PCI DSS 11.6.1
Source E · Detection

Detection and response

Around-the-clock monitoring built from your estate, triaged by an engineer, with the response worked alongside you.

Managed Security
  • Detection coverage map

    What is monitored, which detections fire on it, and where the gaps are, kept against the asset inventory.

    • NYDFS 500.14
    • DORA Art. 10
    • MAS TRM 12
    • SFC VATP 12.12
    • SOC 2 CC7.2
    • NIST CSF DE.CM-01
  • Incident timelines

    Detection to containment, timestamped, with the decision record behind each classification.

    • DORA Art. 17
    • DORA RTS 2024/1772
    • NYDFS 500.17
    • SOC 2 CC7.4
    • CCSS 2.04
  • Regulator notification packs

    The facts each regulator's first notice asks for, assembled from the timeline for you to file inside every clock.

    • DORA Art. 19
    • NYDFS 500.17
    • MAS FSM-N13 para. 7
    • 12 CFR 53.3
    • VARA Rule I.K.1
    • ADGM GEN 3.5.18
    • GDPR Art. 33
    • SEC 8-K Item 1.05
Source F · Researchers

Bounties and contests

A hosted bounty and funded audit contests that keep outside researchers looking after launch.

Vanguard
  • Vulnerability disclosure records

    A published channel for researchers, with every report received, triaged, rewarded or closed on the record.

    • NIST CSF ID.RA-08
    • NIS2 Art. 21(2)(e)
    • ADGM GEN 3.5.14
    • ISO 27001 A.8.8
  • Contest results

    Findings from a funded contest, deduplicated and judged, with the fixes reviewed.

    • DORA Art. 24
    • VARA Rule I.E.1
    • CCSS 2.01
Source G · Assessments

Readiness, maturity and resilience

The three assessments on this page, each leaving its own dated record.

The assessments
  • Gap register, by provision

    Every applicable provision with its control, its evidence, and its status, kept current through authorisation and after it.

    • MiCA Art. 62
    • UK SI 2026/102
    • GENIUS Sec. 4
    • California DFAL 3701
    • MAS FSMA Part 9
    • SFC VATP
  • CSF 2.0 profile and roadmap

    Current and target tier per function, the controls behind each score, and the plan between them.

    • NIST CSF 2.0
    • ISO 27001
    • CCSS
    • NYDFS 500.9
    • FTC 314.4(b)
  • Business impact analysis and impact tolerances

    Your most important services, how much disruption each can absorb, and the recovery objectives that follow.

    • DORA Art. 11
    • FCA SYSC 15A.2.5R
    • PRA Op Res 2.1
    • MAS BCM 3.1
    • APRA CPS 230 para. 37
    • HKMA OR-2 4.1
    • ISO 22301 8.2.2
  • Dependency maps and third-party register

    The people, systems, providers and chain dependencies behind each service, and the register regulators ask for.

    • DORA Art. 28(3)
    • FCA SYSC 15A.4.1R
    • APRA CPS 230 para. 26(b)
    • MAS BCM 4.1
    • UK SUP 16.33.6R
    • VARA Rule IV.C.2.b
  • Scenario tests and timed recoveries

    Severe but plausible scenarios run, restores and key recoveries timed against objectives, and the lessons acted on.

    • DORA Art. 11(6), 12
    • FCA SYSC 15A.5
    • MAS FSM-N13 para. 6
    • APRA CPS 230 para. 42
    • NYDFS 500.16
    • SOC 2 A1.3
    • PFMI P17 KC6
  • Self-assessment and board pack

    The written self-assessment and annual attestations your board signs, with the evidence behind every statement in them.

    • FCA SYSC 15A.6.1R
    • PRA Op Res 6.1
    • MAS BCM 10.6
    • NYDFS 500.17
The regulatory map

The regimes we assess to, who enforces them, and the provisions we map.

Each regime is read for its technology, security, custody and resilience provisions: the part of the rulebook a Guardian assessment can test and evidence. Choose a jurisdiction to see the regulators behind each regime and the articles, sections and paragraphs your controls are mapped to.

European Union

4 regimes · 31 provisions mapped

Regulation (EU) 2023/1114; RTS (EU) 2025/299 and 2025/305

MiCA

Markets in Crypto-Assets Regulation

Status
Fully applicable since 30 December 2024. Every national transitional period ended by 1 July 2026, so every CASP in the EU now needs MiCA authorisation. ESMA's supervisory review of CASP custody resilience runs to mid-2027.
Applies to
Crypto-asset service providers (custody, trading platforms, exchange, transfer, execution and more) and issuers of asset-referenced and e-money tokens.
Regulators
  • ESMA
  • EBA
  • BaFin
  • AMF and ACPR
  • Central Bank of Ireland
  • CONSOB and Banca d'Italia
  • AFM and DNB
  • CSSF
  • MFSA
Assessed in
  • Readiness
  • Resilience
  • Maturity
  1. Art. 62(2)(j); RTS 2025/305 Art. 9
    ICT documentation for authorisation

    Technical documentation of ICT systems and security arrangements, and where available a third-party cybersecurity audit including penetration tests and a source code review of smart contracts.

  2. Art. 68(7); RTS 2025/299
    Continuity and regularity

    Resilient ICT systems under DORA, a business continuity policy with recovery time and point objectives, plans for disruption of a permissionless ledger, and tests at least annually.

  3. Art. 68(8)
    Data security

    Systems that safeguard the availability, authenticity, integrity and confidentiality of data, evaluated regularly.

  4. Art. 70
    Safekeeping of client assets

    Clients' ownership rights protected, including on insolvency, and client funds placed with a credit institution or central bank by the end of the next business day.

  5. Art. 75(3); RTS 2025/305 Art. 10
    Custody policy and key management

    A custody policy that minimises loss of crypto-assets or the means of access through fraud, cyber threats or negligence, and a described approval and safeguarding system for keys.

  6. Art. 75(7), 75(8)
    Segregation and liability

    Client crypto-assets held separately on the ledger and operationally segregated, with the custodian liable for losses from an incident attributable to it.

  7. Art. 73
    Outsourcing

    Full responsibility retained for outsourced functions, with contingency plans, exit strategies and supervisory access in written agreements.

  8. Art. 76(7)
    Trading platform systems

    Trading systems that are resilient, sized for peak volumes, fully tested and covered by business continuity arrangements.

  9. Art. 34(9) to (11), Art. 37
    Token issuer controls

    ICT continuity and risk controls under DORA for asset-referenced token issuers, and reserve assets held with a separate custodian within 5 working days.

Regulation (EU) 2022/2554; RTS (EU) 2024/1774, 2024/1772, 2025/301, 2025/1190

DORA

Digital Operational Resilience Act

Status
Applies since 17 January 2025. Registers of information are filed annually; the ESAs designated the first critical ICT third-party providers on 18 November 2025.
Applies to
Twenty kinds of financial entity, including banks, payment and e-money institutions, investment firms and, under Art. 2(1)(f), MiCA-authorised CASPs and asset-referenced token issuers.
Regulators
  • EBA
  • ESMA
  • EIOPA
  • European Central Bank
  • National competent authorities
  • BaFin
  • AMF and ACPR
  • Central Bank of Ireland
  • CSSF
Assessed in
  • Maturity
  • Resilience
  • Readiness
  1. Art. 5(2), 5(4)
    Management body accountability

    Ultimate responsibility for ICT risk sits with the management body, which approves the resilience strategy and trains regularly.

  2. Art. 6(5); RTS 2024/1774
    ICT risk management framework

    A documented framework reviewed at least yearly, covering asset management, encryption, network security, logging, access control, patching and the full lifecycle of cryptographic keys.

  3. Art. 9(4)
    Protection and prevention

    Least-privilege access, strong authentication, protection of cryptographic keys, change management and patching.

  4. Art. 11(6), Art. 12
    Continuity and backup

    Continuity and recovery plans tested at least yearly with cyber-attack and switchover scenarios, and backups restored periodically.

  5. Art. 19; RTS 2025/301
    Major incident reporting

    Initial notice within 4 hours of classification and 24 hours of awareness, an intermediate report within 72 hours, and a final report within one month.

  6. RTS 2024/1772 Arts. 8, 9
    Major incident criteria

    Classification thresholds such as 10% of clients affected, over 2 hours of critical service downtime, or successful malicious access.

  7. Arts. 24, 25
    Resilience testing programme

    Every system supporting a critical or important function tested at least yearly by independent testers, through scans, source code reviews and penetration tests.

  8. Art. 26; RTS 2025/1190
    Threat-led penetration testing

    Firms identified by their authority run TLPT on live production systems at least every 3 years.

  9. Art. 28(3), 28(8), Art. 30
    ICT third-party risk

    A register of every ICT contract reported yearly, exit strategies for critical services, and mandatory contract terms on security, testing, audit and access.

Directive (EU) 2022/2555

NIS2

Directive on a high common level of cybersecurity across the Union

Status
Transposition deadline 17 October 2024; national laws are still uneven. For financial entities in scope of DORA, DORA applies instead.
Applies to
Essential and important entities including digital infrastructure, cloud and managed security providers, and fintechs and technology suppliers outside DORA.
Regulators
  • National competent authorities and CSIRTs
  • BSI
  • ANSSI
  • ACN
  • Centre for Cybersecurity Belgium
  • ENISA
Assessed in
  • Maturity
  • Resilience
  1. Art. 20
    Management accountability and training

    Management bodies approve and oversee cybersecurity measures, can be held liable, and must be trained.

  2. Art. 21(2)(a), (f)
    Risk policy and effectiveness

    Policies on risk analysis and information system security, and on assessing whether the controls work.

  3. Art. 21(2)(b), (c)
    Incident handling and continuity

    Incident handling, backup management, disaster recovery and crisis management.

  4. Art. 21(2)(d)
    Supply chain security

    Security of supplier relationships, weighing each supplier's vulnerabilities and development practices.

  5. Art. 21(2)(e)
    Secure development

    Security in acquisition, development and maintenance, including vulnerability handling and disclosure.

  6. Art. 21(2)(h), (i), (j)
    Technical controls

    Cryptography and encryption, access control and asset management, and multi-factor authentication.

  7. Art. 23(4)
    Incident reporting

    An early warning within 24 hours, an incident notification within 72 hours, and a final report within one month.

Regulation (EU) 2016/679

GDPR

General Data Protection Regulation, security and breach provisions

Status
Applies since 25 May 2018. A 2025 proposal to move breach notice to 96 hours is not law; the 72-hour rule stands.
Applies to
Every controller and processor of personal data in the EU, including exchanges, wallets and fintechs that hold customer data.
Regulators
  • European Data Protection Board
  • CNIL
  • Data Protection Commission (Ireland)
  • Garante
  • AEPD
  • Autoriteit Persoonsgegevens
Assessed in
  • Maturity
  • Resilience
  1. Art. 32(1)(a), (b)
    Security of processing

    Measures matched to the risk, including encryption and the ongoing confidentiality, integrity, availability and resilience of systems.

  2. Art. 32(1)(c)
    Restoration

    The ability to restore access to personal data in a timely manner after an incident.

  3. Art. 32(1)(d)
    Regular testing

    A process for regularly testing, assessing and evaluating whether the security measures work.

  4. Art. 33
    Notify the authority

    Breaches notified to the supervisory authority within 72 hours where feasible, and every breach documented.

  5. Art. 34
    Notify individuals

    Data subjects told without undue delay when a breach is likely to create a high risk.

  6. Art. 28
    Processor guarantees

    Only processors giving sufficient guarantees, with Art. 32 security measures required by contract.

United Kingdom

6 regimes · 38 provisions mapped

SI 2026/102; FCA PS26/10 to PS26/13; FG26/6

UK cryptoasset regime

The Financial Services and Markets Act 2000 (Cryptoassets) Regulations 2026

Status
Regime goes live 25 October 2027. The FCA application window opened 30 September 2026 and closes 28 February 2027. Until then, exchanges and custodian wallet providers register under the Money Laundering Regulations 2017.
Applies to
Firms issuing qualifying stablecoins, safeguarding cryptoassets or the means of access to them, operating trading platforms, dealing, arranging or staking.
Regulators
  • Financial Conduct Authority (FCA)
  • Bank of England
  • HM Treasury
Assessed in
  • Readiness
  • Resilience
  • Maturity
  1. CASS 17.4.2R to 17.4.6R
    Key lifecycle security

    The means of access protected through generation, storage, sharding and destruction against inoperability, loss, fraud and irrecoverability, with key incidents promptly resolved.

  2. CASS 17.4.8R to 17.4.11R
    Means of access record

    A record of where each key is, how it is secured and who can use it, kept for 5 years.

  3. CASS 17.3.3R, 17.5.10R
    Trust and reconciliation

    Client cryptoassets held on trust, and internal records reconciled with on-chain holdings at least once each business day.

  4. CASS 17.5.13R
    Shortfalls

    Any shortfall made good no later than 24 hours after it is identified.

  5. CASS 17.6.3R
    Third-party custodians

    Sub-custodians appointed only after due diligence, under a written agreement, in jurisdictions that regulate resilience and key security.

  6. SYSC 15A (via PS26/13); FG26/6
    Operational resilience

    The full UK resilience regime applied to cryptoasset firms, with scenarios such as hot wallet compromise and oracle manipulation.

  7. FG26/6 para. 4.3
    Critical providers

    The FCA told before a firm relies on critical providers such as MPC or HSM custody and transaction signing infrastructure.

  8. CASS 16.4.9R, 16.6.8R
    Stablecoin backing assets

    Backing assets reconciled daily, held on statutory trust, with no more than 20% at intragroup custodians.

  9. CRYPTO 6.3.2R
    Trading platform systems

    Platform systems that are resilient, sized for peak volumes, fully tested and covered by continuity arrangements.

FCA Handbook SYSC 15A; PS21/3

FCA operational resilience

Operational resilience rules for FCA-regulated firms

Status
In force since 31 March 2022. The deadline to remain within impact tolerances passed on 31 March 2025. Extends to cryptoasset firms from 25 October 2027.
Applies to
Banks, payment and e-money institutions, enhanced scope SM&CR firms, insurers and recognised investment exchanges.
Regulators
  • Financial Conduct Authority (FCA)
Assessed in
  • Resilience
  1. SYSC 15A.2.1R
    Important business services

    Important business services identified and reviewed at least once a year.

  2. SYSC 15A.2.5R
    Impact tolerances

    An impact tolerance set for each important business service.

  3. SYSC 15A.2.9R
    Stay within tolerance

    The ability to stay within each tolerance through a severe but plausible disruption.

  4. SYSC 15A.4.1R
    Mapping

    The people, processes, technology, facilities and information behind each service documented and reviewed yearly.

  5. SYSC 15A.5.1R to 5.9R
    Scenario testing and lessons learned

    A testing plan against scenarios of varying severity, with lessons from tests and real disruptions acted on.

  6. SYSC 15A.6.1R, 15A.7.1R
    Self-assessment

    A written self-assessment, approved by the governing body and kept for at least 6 years.

  7. PSRs 2017 regs. 98, 99
    Payment firm risk and incidents

    An operational and security risk framework with an annual assessment to the FCA, and major incidents reported without undue delay.

PRA Rulebook, Operational Resilience Part; SS1/21; BoE FMI policy

PRA and Bank of England resilience

Operational resilience for PRA-regulated firms and financial market infrastructures

Status
In force since 31 March 2022; tolerance deadline passed 31 March 2025.
Applies to
UK banks, building societies, designated investment firms and insurers; CCPs, CSDs and recognised payment systems.
Regulators
  • Prudential Regulation Authority (PRA)
  • Bank of England
Assessed in
  • Resilience
  1. Op Res 2.1 to 2.4
    Services and tolerances

    Important business services identified, with tolerances set where disruption would threaten safety, soundness or stability.

  2. Op Res 2.5, 2.6
    Stay within tolerance

    Remain within tolerance in a severe but plausible disruption, including risks from the wider group.

  3. Op Res 4.1
    Mapping

    The resources each important business service depends on mapped.

  4. Op Res 5.1, 5.2
    Scenario testing

    Tests against a range of adverse scenarios.

  5. Op Res 6.1, 7.1
    Self-assessment and approval

    A self-assessment approved by the management body.

  6. BoE FMI policy
    FMI standard

    Infrastructure stays within tolerance in an extreme but plausible disruption.

PRA SS2/21; FCA SYSC 8; FCA PS26/2 and PRA PS7/26

UK third parties and incident reporting

Outsourcing and third-party risk, and the new operational incident and third-party reporting rules

Status
Outsourcing rules in force. Incident and third-party reporting rules are final and apply from 18 March 2027.
Applies to
PRA- and FCA-regulated firms, payment service providers and recognised investment exchanges; authorised cryptoasset firms from 25 October 2027.
Regulators
  • Prudential Regulation Authority (PRA)
  • Financial Conduct Authority (FCA)
Assessed in
  • Resilience
  • Maturity
  1. SS2/21 5.1, 5.14
    Material outsourcing

    Materiality assessed for every outsourcing, and the PRA notified before a material one is entered or changed.

  2. SS2/21 7.10, 7.11
    Data security

    Controls for data in transit, in memory and at rest, including encryption, key management and access management.

  3. SS2/21 8.3; SYSC 8.1.8R
    Audit and access rights

    Full access and audit rights for the firm, its auditors and the regulators in outsourcing contracts.

  4. SS2/21 10.1, 10.10
    Continuity and exit

    Continuity plans and documented, tested exit plans, including stressed exits.

  5. SUP 15.18.6R
    Initial incident report

    Incidents that cross a harm threshold reported within 24 hours of the threshold being met.

  6. SUP 15.18.9R
    Final incident report

    A final report within 30 working days of resolution.

  7. SUP 15.14.18DD
    Payment firm incidents

    Major operational or security incidents reported within 4 hours of first detection.

  8. SUP 16.33.6R
    Third-party register

    A register of material third-party arrangements submitted every year.

Banking Act 2009 Part 5; BoE policy statement, 22 June 2026

BoE systemic stablecoins

Regime for sterling-denominated systemic stablecoins

Status
Policy final since 22 June 2026; the Code of Practice is still in draft.
Applies to
Sterling stablecoin issuers that HM Treasury recognises as systemic. Non-systemic issuers are supervised by the FCA alone.
Regulators
  • Bank of England
  • Financial Conduct Authority (FCA)
  • HM Treasury
Assessed in
  • Readiness
  • Resilience
  1. Backing assets
    Composition

    In steady state, 70% short-term UK government debt and 30% unremunerated Bank of England deposits.

  2. Safeguarding
    Statutory trust

    Backing assets held on statutory trust for holders.

  3. Redemption
    Redemption at par

    Redemption within 24 hours of a full request.

  4. Operational resilience
    Shared supervision

    Operational resilience and outsourcing supervised jointly by the Bank and the FCA.

UK GDPR; Data Protection Act 2018

UK GDPR

UK General Data Protection Regulation, security and breach provisions

Status
In force. The Data (Use and Access) Act 2025 left Art. 32 and the 72-hour rule unchanged.
Applies to
Every controller and processor of personal data in the UK.
Regulators
  • Information Commission (ICO)
Assessed in
  • Maturity
  • Resilience
  1. Art. 32
    Security of processing

    Encryption, resilience, timely restoration and regular testing of controls.

  2. Art. 33
    Notify the regulator

    Breaches notified within 72 hours where feasible, and every breach documented.

  3. Art. 34
    Notify individuals

    Data subjects told of high-risk breaches without undue delay.

  4. Art. 28
    Processor contracts

    Processors give sufficient guarantees, with security and audit terms in the contract.

United States

7 regimes · 53 provisions mapped

Public Law 119-27; 12 U.S.C. 5901 et seq.; OCC 12 CFR Part 15

GENIUS Act

Guiding and Establishing National Innovation for U.S. Stablecoins Act

Status
Signed 18 July 2025; takes effect 18 January 2027. The OCC approved its final rule on 21 October 2026; FDIC, Federal Reserve, NCUA and Treasury rules are proposed.
Applies to
Permitted payment stablecoin issuers (bank subsidiaries, federal and state qualified issuers), foreign issuers, the digital asset service providers that offer their coins, and custodians of reserves and issuing keys.
Regulators
  • OCC
  • Federal Reserve Board
  • FDIC
  • NCUA
  • U.S. Treasury
  • FinCEN and OFAC
  • State regulators such as NYDFS
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. Sec. 4(a)(1), 4(a)(2)
    Reserves

    Identifiable reserves of at least 1:1 in listed assets, with no pledging or rehypothecation outside narrow exceptions.

  2. Sec. 4(a)(3)
    Monthly reserve examination

    Monthly published reserve composition, examined by a registered public accounting firm and certified by the CEO and CFO.

  3. Sec. 4(a)(4)(A)(iv)
    Operational and IT risk

    Principles-based operational, compliance and information technology risk management standards, tailored to each issuer.

  4. Sec. 4(a)(6)(B), 2(16)
    Lawful orders

    The technological capability to seize, freeze, burn or prevent the transfer of payment stablecoins when lawfully ordered.

  5. Sec. 4(a)(5)(A)(iv)
    Block and freeze

    Technical capabilities, policies and procedures to block, freeze and reject impermissible transactions.

  6. Sec. 10
    Custody

    Reserves, collateral and issuing private keys held only by regulated custodians, segregated as customer property.

  7. 12 CFR 15.13(b) (OCC)
    IT and security program

    A board-approved program covering asset inventory, validation that smart contracts and key systems operate as intended, independent testing, incident response, and private key management, backup and recovery.

  8. 12 CFR 15.12, 15.14 (OCC)
    Redemption and examination

    Redemption within two business days, 24-hour notice when redemptions exceed 10% of supply in a day, and a full-scope OCC exam every 12 months.

23 NYCRR Part 500, as amended November 2023

NYDFS Part 500

Cybersecurity Requirements for Financial Services Companies

Status
In force. The Second Amendment's phase-in completed on 1 November 2025 with MFA for all users and the asset inventory. Annual certification due 15 April.
Applies to
Every entity licensed or chartered by NYDFS, including BitLicensees, limited purpose trust companies, money transmitters and state banks. Class A companies carry extra duties.
Regulators
  • New York State Department of Financial Services (NYDFS)
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. 500.2, 500.3
    Program and policy

    A risk-based cybersecurity program and written policies approved annually, with independent audits for Class A companies.

  2. 500.4
    Governance

    A CISO who reports in writing to the senior governing body at least annually.

  3. 500.5
    Vulnerability management

    Penetration testing from inside and outside by a qualified party at least annually, automated scans, and risk-prioritised remediation.

  4. 500.7
    Access privileges

    Least privilege, annual access reviews and prompt deprovisioning; privileged access management and blocked common passwords for Class A.

  5. 500.9
    Risk assessment

    A written risk assessment updated at least annually and on material change.

  6. 500.11
    Third-party service providers

    Written policies for assessing providers, minimum security practices and contract terms covering MFA, encryption and incident notice.

  7. 500.12, 500.13
    MFA and asset inventory

    MFA for any individual accessing any information system, and an asset inventory with owner, classification and recovery time objective.

  8. 500.14, 500.15, 500.16
    Monitoring, encryption, IR and BCDR

    Training and monitoring, encryption at rest and in transit, and incident response and BCDR plans tested annually, including restores from protected backups.

  9. 500.17
    Notices to the superintendent

    Cybersecurity incidents reported within 72 hours, extortion payments within 24 hours, and an annual compliance certification by 15 April.

23 NYCRR Part 200; NYDFS guidance of 8 June 2022, 15 November 2023 and 30 September 2025

NYDFS BitLicense

Virtual Currencies regulation and its custody, stablecoin and listing guidance

Status
In force since 24 June 2015. Custody guidance replaced on 30 September 2025.
Applies to
Virtual currency business activity involving New York or its residents: transmission, custody, exchange and issuance; the custody guidance also covers limited purpose trust companies.
Regulators
  • New York State Department of Financial Services (NYDFS)
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. 200.9
    Custody and protection of customer assets

    Virtual currency of the same type and amount owed to customers, never sold, lent or encumbered except at their direction.

  2. 200.16(a), (b)
    Cyber security program

    A program across identify, protect, detect, respond and recover, with a board-approved policy that covers changes to core protocols the licensee does not control.

  3. 200.16(c), (d)
    CISO and annual report

    A qualified CISO and an annual CISO report to NYDFS.

  4. 200.16(e)
    Testing and audit trail

    Penetration testing at least annually, vulnerability assessment at least quarterly, and tamper-protected audit trails that reconstruct every transaction.

  5. 200.17
    Business continuity and disaster recovery

    A BCDR plan with off-site backups, tested at least annually by independent staff or a qualified third party.

  6. Custody guidance, 2025
    Segregation and sub-custody

    Assets segregated on-chain and in ledgers, prior approval for any new sub-custodian, and reconciliation of books to chain demonstrable at any time.

  7. Stablecoin guidance, 2022
    Reserves and attestation

    Full reserves measured daily, redemption within T+2, monthly CPA examination and an annual controls attestation.

  8. Listing guidance, 2023
    Coin risk assessment

    A cybersecurity risk assessment of each coin and its underlying blockchain before listing.

16 CFR Part 314

FTC Safeguards Rule

Standards for Safeguarding Customer Information under the Gramm-Leach-Bliley Act

Status
Amended rule in force since 9 June 2023; breach notification to the FTC since 13 May 2024.
Applies to
Non-bank financial institutions under FTC jurisdiction, including many fintechs and crypto firms not supervised by a banking agency or the SEC.
Regulators
  • Federal Trade Commission (FTC)
Assessed in
  • Maturity
  • Readiness
  • Resilience
  1. 314.4(a)
    Qualified Individual

    One qualified individual responsible for the information security program.

  2. 314.4(b)
    Written risk assessment

    Written criteria for assessing risks to confidentiality, integrity and availability, repeated periodically.

  3. 314.4(c)(1), (c)(5)
    Access control and MFA

    Least-privilege access, and MFA for any individual accessing any information system.

  4. 314.4(c)(3), (c)(4), (c)(8)
    Encryption, development, logging

    Encryption in transit and at rest, secure development practices, and logging of authorised users' activity.

  5. 314.4(d)(2)
    Testing

    Without continuous monitoring, annual penetration tests and vulnerability assessments every six months.

  6. 314.4(f)
    Service providers

    Capable providers, safeguards required by contract, and periodic reassessment.

  7. 314.4(h), (i)
    Incident response and board report

    A written incident response plan, and an annual written report to the board.

  8. 314.4(j)
    FTC notification

    The FTC notified within 30 days of discovering an event affecting 500 or more consumers.

17 CFR 248.30, as amended May 2024; Form 8-K Item 1.05; Regulation S-K Item 106

SEC Regulation S-P and cyber disclosure

Safeguarding of customer information, and public company cybersecurity disclosure

Status
Regulation S-P amendments apply to all covered firms since 3 June 2026. Disclosure rules in force since December 2023.
Applies to
Broker-dealers, funding portals, investment advisers, investment companies and transfer agents (S-P); every SEC reporting company (Items 1.05 and 106).
Regulators
  • U.S. Securities and Exchange Commission (SEC)
Assessed in
  • Resilience
  • Readiness
  • Maturity
  1. 248.30(a)(3)
    Incident response program

    Procedures to detect, respond to and recover from unauthorised access to customer information.

  2. 248.30(a)(4)
    Customer notice

    Affected individuals notified as soon as practicable and within 30 days of becoming aware.

  3. 248.30(a)(5)
    Service providers

    Oversight of providers, who must report a breach to the firm within 72 hours.

  4. 8-K Item 1.05
    Material incident disclosure

    A material cybersecurity incident disclosed within 4 business days of determining it is material.

  5. S-K Item 106(b)
    Risk management

    Processes for assessing and managing material cyber risk, including outside assessors and third-party oversight, described annually.

  6. S-K Item 106(c)
    Governance

    Board oversight and management's role and expertise described annually.

12 CFR 30 App. B, 208 App. D-2, 364 App. B; 12 CFR 53, 225.300, 304.21

Federal banking agencies

Information security standards, incident notification, third-party risk and crypto-asset safekeeping

Status
In force. Third-party guidance of June 2023 still applies, with a proposed replacement out for comment since 11 September 2026. The FFIEC Cybersecurity Assessment Tool was retired on 31 August 2025 in favour of NIST CSF 2.0 and similar frameworks.
Applies to
National and state banks, savings associations and bank holding companies, including those offering crypto custody, and their bank service providers.
Regulators
  • OCC
  • Federal Reserve Board
  • FDIC
Assessed in
  • Maturity
  • Resilience
  • Readiness
  1. App. B, II.A and III.A
    Information security program

    A comprehensive written program approved and overseen by the board.

  2. App. B, III.C.3
    Independent testing

    Key controls tested regularly by independent third parties or independent staff.

  3. App. B, III.D
    Service providers

    Due diligence, contract terms and monitoring, including review of providers' audits and test results.

  4. 12 CFR 53.3, 225.302, 304.23
    Incident notification

    The primary regulator notified no later than 36 hours after determining a notification incident occurred.

  5. 12 CFR 53.4, 225.303, 304.24
    Service provider notification

    Bank service providers notify the bank when an incident disrupts covered services for four hours or more.

  6. Interagency guidance, June 2023
    Third-party relationships

    A full lifecycle from due diligence to termination, with audit rights, business continuity and subcontractor terms.

  7. Joint statement, July 2025
    Crypto-asset safekeeping

    Control such that no one else can move the asset alone, secure key generation, plans for lost or compromised keys, and smart contracts governed through their lifecycle.

  8. OCC IL 1183, IL 1184
    Crypto custody activities

    Custody and sub-custody permitted with sound risk management and third-party oversight of sub-custodians' controls.

California Financial Code Division 1.25, sections 3101 et seq.

California DFAL

Digital Financial Assets Law

Status
Licence required since 1 July 2026, unless a completed application was filed by then. SB 97 (30 June 2026) removed the stablecoin chapter.
Applies to
Anyone exchanging, transferring or storing digital financial assets with or for California residents, and kiosk operators.
Regulators
  • California Department of Financial Protection and Innovation (DFPI)
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. 3701(a)(1) to (3)
    Required programs

    Written information security and operational security, business continuity and disaster recovery programs, created before applying.

  2. 3701(e)
    Security safeguards

    Administrative, physical and technical safeguards for customer information and every digital financial asset.

  3. 3701(h)
    Responsible individual

    A responsible individual with the authority to enforce each program; DFPI evaluates programs against NIST CSF 2.0.

  4. 3503
    Custody

    Enough of each asset under control to cover every customer entitlement, held in statutory trust and outside the licensee's estate.

  5. 3505(a)(1)(C)
    Listing risk assessment

    A certified risk assessment of each asset before listing, covering cybersecurity, theft and code or protocol defects.

  6. 3211(b)(3)(D)
    Annual report

    Material data security breaches and cybersecurity events described in the annual report.

Singapore

6 regimes · 39 provisions mapped

MAS Notices FSM-N05, FSM-N13, FSM-N30

MAS Technology Risk Management Notices

Notice on Technology Risk Management, issued under section 29 of the Financial Services and Markets Act 2022

Status
In force since 10 May 2024 for banks; 6 November 2024 for DPT service providers; 30 June 2025 for DTSPs. Amendments consulted on in 2026 (P012-2026) are not yet final.
Applies to
Banks (FSM-N05), digital payment token service providers and designated payment systems (FSM-N13), and licensed digital token service providers (FSM-N30).
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Readiness
  • Resilience
  1. Para. 4
    Critical systems

    A framework and process to identify critical systems.

  2. Para. 5
    Availability

    Unscheduled downtime of each critical system no more than 4 hours in any 12 months.

  3. Para. 6
    Recovery time objective

    An RTO of no more than 4 hours for each critical system, with recovery tested and documented at least every 12 months.

  4. Para. 7
    Incident notification

    MAS notified as soon as possible, and no later than 1 hour after discovering a relevant incident.

  5. Para. 8
    Root cause report

    A root cause and impact analysis report within 14 days of discovery.

  6. Para. 9
    Customer information

    IT controls that protect customer information from unauthorised access or disclosure.

MAS Notices FSM-N06, FSM-N14, FSM-N31

MAS Cyber Hygiene Notices

Notice on Cyber Hygiene, issued under section 29 of the Financial Services and Markets Act 2022

Status
In force since 10 May 2024 for banks and payment services licensees, and 30 June 2025 for DTSPs. They replace Notice 655 and PSN06.
Applies to
Banks (FSM-N06), every payment services licensee including DPT service providers (FSM-N14), and licensed DTSPs (FSM-N31).
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Readiness
  • Maturity
  1. Para. 4.1
    Administrative accounts

    Every administrative account on operating systems, databases, applications, security appliances and network devices secured against unauthorised access.

  2. Para. 4.2
    Security patches

    Patches applied within a timeframe matched to the risk, with compensating controls where no patch exists.

  3. Para. 4.3
    Security standards

    Written security standards for every system, and systems that conform to them.

  4. Para. 4.4
    Network perimeter defence

    Perimeter controls that restrict all unauthorised network traffic.

  5. Para. 4.5
    Malware protection

    Malware protection on every system where it can be implemented.

  6. Para. 4.6
    Multi-factor authentication

    MFA for all administrative accounts on critical systems and for every account that reaches customer information over the internet.

MAS Technology Risk Management Guidelines, January 2021

MAS TRM Guidelines

Guidelines on Risk Management Practices: Technology Risk

Status
Issued 18 January 2021 and current. Guidelines, but observance is weighed in supervision.
Applies to
Banks, insurers, capital markets firms, payment institutions, designated payment systems and licensed DTSPs.
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Maturity
  • Resilience
  1. Sec. 3.1.7
    Board responsibilities

    The board ensures a technology risk framework and function, approves technology risk appetite, and ensures independent audit.

  2. Sec. 3.4
    Third-party services

    Technology risk at a third party assessed before contracting and monitored for confidentiality, integrity and resilience.

  3. Sec. 6.1.6, 6.1.7
    Application security testing

    Static, dynamic and interactive testing, with major defects fixed before production.

  4. Sec. 8.2, 8.3
    Recovery objectives and DR testing

    An RTO and RPO for each system, and disaster recovery tested against them regularly.

  5. Sec. 9.1.1, 9.2.1
    Access and privileged access

    Never alone, segregation of duties and least privilege, with privileged accounts granted on need and their activity logged and reviewed.

  6. Sec. 10.2
    Cryptographic key management

    A key management policy from generation to expiry, with sensitive keys held in hardened, tamper-resistant systems such as an HSM.

  7. Sec. 13.2
    Penetration testing

    Blackbox and greybox testing of online services, and internet-facing systems tested at least yearly or after major change.

  8. Sec. 13.4
    Adversarial attack simulation

    Red team exercises that validate cyber defence and response.

MAS Guidelines on Business Continuity Management, June 2022

MAS BCM Guidelines

Guidelines on Business Continuity Management

Status
Issued 6 June 2022, with firms expected to comply within 12 months.
Applies to
All MAS-regulated financial institutions, including payment institutions and licensed DTSPs.
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Resilience
  1. Para. 2.3
    Critical business services

    Critical business services and functions identified by impact on safety and soundness, customers and other institutions.

  2. Para. 3.1, 3.2
    Service recovery time objectives

    An SRTO for each critical business service, with dependency RTOs that can meet it.

  3. Para. 4.1 to 4.4
    End-to-end dependency mapping

    People, processes, technology and third parties mapped for each critical service, and third parties shown to meet the SRTO.

  4. Para. 5.1, 5.2
    Concentration risk

    Concentration of people, technology or providers in one site or one provider addressed.

  5. Para. 7.2, 7.3
    Scenario testing

    Regular testing against severe but plausible scenarios, with results documented and gaps reported to senior management.

  6. Para. 8.2, 8.3
    BCM audit

    An independent audit of the BCM framework and each critical service at least once every three years.

  7. Para. 9.6, 10.6
    Notification and attestation

    MAS notified within 1 hour of a severe disruption, and an annual attestation on BCM preparedness to the board.

Payment Services Regulations 2019, regs 18A to 18J; Guidelines PS-G03

MAS DPT safeguarding

Safeguarding of customer assets by digital payment token service providers

Status
Regulations in force since 4 October 2024; PS-G03 fully in effect from 19 June 2025.
Applies to
Payment services licensees that provide digital payment token services, including custody.
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Readiness
  • Maturity
  1. Reg. 18B
    Trust account

    Customer assets placed in a designated trust account, separate from the licensee's own, no later than the next business day.

  2. Reg. 18F
    Customer records

    A separate book entry for each customer's assets.

  3. Reg. 18G(a), (b)
    Safeguarding systems

    Adequate systems and controls, and all reasonable measures to keep keys secure and intact.

  4. Reg. 18G(c) to (e)
    Independent safeguarding

    Segregation of duties, so safeguarding is never directed by people who trade or make investment decisions.

  5. Reg. 18H
    Daily computation

    Assets held in trust computed against the amount required every business day, with results kept for 5 years.

  6. PS-G03 para. 3.4.2
    Never alone

    No single person can authorise the movement of customer assets.

  7. PS-G03 para. 3.4.4
    Cold storage

    Keys for at least 90% of customer assets held in cold wallets at all times.

  8. PS-G03 para. 3.4.5
    MPC key shares

    Where MPC is used, key shares held by different parties so no single party can move assets.

Financial Services and Markets Act 2022, Part 9

MAS DTSP regime

Licensing of digital token service providers

Status
In force since 30 June 2025, with no transition period. MAS has said licences will be granted only in extremely limited circumstances.
Applies to
Singapore firms and individuals providing digital token services only outside Singapore.
Regulators
  • Monetary Authority of Singapore (MAS)
Assessed in
  • Readiness
  1. s. 137
    Licence

    A licence is required to carry on the business, with criminal penalties for operating without one.

  2. FSM-N30
    Technology risk

    The same availability, 4 hour RTO, 1 hour notification and 14 day root cause rules as other licensees.

  3. FSM-N31
    Cyber hygiene

    The six cyber hygiene measures, including MFA.

  4. MAS response, para. 8.1
    Guidelines that apply

    The TRM, Business Continuity, Outsourcing and Fit and Proper guidelines all apply to licensed DTSPs.

Hong Kong

4 regimes · 28 provisions mapped

SFC Guidelines for VATP Operators, G.N. 3121 of 2023

SFC VATP Guidelines

Guidelines for Virtual Asset Trading Platform Operators

Status
In force since 1 June 2023, with custody minimum standards added by circular 25EC44 (15 August 2025) and phishing-resistant login required by 8 July 2027 under 26EC35.
Applies to
SFC-licensed virtual asset trading platforms and their associated custody entity, and applicants for a licence.
Regulators
  • Securities and Futures Commission (SFC)
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. Para. 10.1
    Custody through an associated entity

    Client assets held on trust only through a wholly owned Hong Kong custody subsidiary that conducts no other business.

  2. Para. 10.6(c)
    Cold storage

    98% of client virtual assets held in cold storage unless the SFC permits otherwise.

  3. Para. 10.8
    Private key management

    Keys generated offline in a certified HSM where practicable, no single person with access to full seeds or keys, distributed backups, and keys stored in Hong Kong.

  4. Para. 10.7, 10.10
    Deposits and withdrawals

    Whitelisted client addresses with proof of ownership, velocity limits, and destination addresses that cannot be modified before signing.

  5. Para. 10.22
    Compensation arrangement

    Cover for 50% of client assets in cold storage and 100% of those in hot and other storage, checked daily.

  6. Para. 12.12
    Security controls

    Two-factor client login, yearly access review, layered firewalls, patches within a month, EDR, real-time IDS and SIEM, and a SOC.

  7. Para. 12.13
    Independent cybersecurity assessment

    Before launch, on modification and periodically, including penetration testing and source code review of custody systems.

  8. Para. 12.17 to 12.19
    Contingency planning

    A written contingency plan with cyber scenarios and a backup facility, both tested at least yearly.

  9. Para. 7.10
    Smart contract audit

    An independent smart contract audit before a token is admitted for trading.

Stablecoins Ordinance (Cap. 656)

Stablecoins Ordinance

Licensing regime for fiat-referenced stablecoin issuers

Status
In force since 1 August 2025. First licences granted 10 April 2026.
Applies to
Anyone issuing a fiat-referenced stablecoin in Hong Kong, or one that references the Hong Kong dollar from anywhere.
Regulators
  • Hong Kong Monetary Authority (HKMA)
Assessed in
  • Readiness
  • Resilience
  1. s. 24
    Ongoing minimum criteria

    A licensee meets the Schedule 2 minimum criteria at all times, not only at licensing.

  2. s. 27
    Change of circumstances

    The Monetary Authority told as soon as practicable of any material change affecting the criteria or the business.

  3. Sch. 2 s. 5
    Reserve assets

    A segregated reserve pool per stablecoin, at or above par, with independent attestation, audit and public disclosure.

  4. Sch. 2 s. 6
    Redemption at par

    Valid redemption requests honoured at par as soon as practicable, without unduly burdensome conditions.

  5. Sch. 2 s. 9
    Risk management

    Data security and integrity, fraud detection, robust and proven contingency arrangements, and operational and security safeguards.

  6. Sch. 2 s. 16
    Recovery and wind-down

    Plans to restore critical functions after significant operational disruption, and for an orderly wind-down.

HKMA Guideline under s. 171(4) of Cap. 656, August 2025

HKMA Stablecoin Issuer Guideline

Guideline on Supervision of Licensed Stablecoin Issuers

Status
Effective 1 August 2025.
Applies to
Stablecoin issuers licensed under the Stablecoins Ordinance.
Regulators
  • Hong Kong Monetary Authority (HKMA)
Assessed in
  • Readiness
  • Maturity
  • Resilience
  1. Para. 6.5.3, 6.5.4
    Token operations

    Mint, burn, upgrade, pause and freeze mapped to authorisation levels, multi-signature so no single party performs high-risk operations, and velocity limits, timelocks and simulation before broadcast.

  2. Para. 6.5.5
    Smart contract audit

    Token contracts audited by a qualified third party at least annually and on every deployment or upgrade.

  3. Para. 6.5.7
    Wallet and key management

    Certified HSMs, significant keys generated offline and air-gapped, multi-signature keys stored apart, and full lifecycle logs.

  4. Para. 6.5.17, 6.5.19
    Testing and cyber

    Penetration testing and source code review of major projects, plus vulnerability scanning and intelligence-led attack simulation.

  5. Para. 6.5.22, 6.6
    Technology providers

    Critical technology outsourced only after an independent assessment of the provider, shared with the HKMA.

  6. Para. 6.8
    Incidents and continuity

    Incident triggers including smart contract exploits and loss of key access, and a BCP with RTO and RPO tested at least annually.

  7. Para. 2.7
    Reserve reporting

    Daily statements, weekly reporting, independent attestation, and immediate reporting of unresolved reconciliation gaps.

HKMA Supervisory Policy Manual TM-G-1 and OR-2

HKMA TM-G-1 and OR-2

General Principles for Technology Risk Management, and Operational Resilience

Status
TM-G-1 current. OR-2 resilience deadline passed on 31 May 2026.
Applies to
Authorized institutions (banks), including a bank that is itself a licensed stablecoin issuer.
Regulators
  • Hong Kong Monetary Authority (HKMA)
Assessed in
  • Maturity
  • Resilience
  1. TM-G-1 3.3.3, 3.4.1
    Security operations

    Incident response with timely reporting to the HKMA, baseline security, timely patching and tamper-protected logs.

  2. TM-G-1 7.1.1
    Technology outsourcing

    An independent assessment of a critical provider's IT controls, annual review, and contingency and exit plans.

  3. OR-2 3.3, 4.1
    Critical operations and tolerance

    The board approves critical operations and a time-based tolerance for disruption to each, reviewed annually.

  4. OR-2 5.1
    Mapping

    People, processes, technology, information, facilities and third parties mapped for each critical operation.

  5. OR-2 7.1 to 7.4
    Scenario testing

    Regular tests against severe but plausible scenarios, with formal reports reviewed by senior management.

  6. TM-C-1 3.5.1
    Cyber resilience assessment

    Inherent risk and maturity assessed under C-RAF, with intelligence-led testing (iCAST) for medium and high risk banks.

United Arab Emirates

6 regimes · 43 provisions mapped

VARA Technology and Information Rulebook, 19 May 2025

VARA Technology & Information

Dubai Virtual Assets Regulatory Authority, Technology and Information Rulebook

Status
Current version in force since 19 June 2025. Binding for every VARA licensee; Schedule 1 is guidance.
Applies to
Every virtual asset service provider licensed by VARA in Dubai, including the free zones outside the DIFC.
Regulators
  • Dubai Virtual Assets Regulatory Authority (VARA)
Assessed in
  • Maturity
  • Resilience
  • Readiness
  1. Rule I.A
    Technology governance framework

    A technology governance and risk assessment framework with defence-in-depth controls, reviewed and tested periodically.

  2. Rule I.B
    Cybersecurity policy

    Submitted to VARA at licensing and reviewed by the CISO at least annually, covering smart contract validation and audit (I.B.3.f) and incident response.

  3. Rule I.I
    CISO

    A Chief Information Security Officer responsible for the rulebook, separate from the Compliance Officer.

  4. Rule I.D
    Cryptographic keys and wallets

    No single point of failure, separately located backups, an audit log of every change of access to keys, and a quarterly internal audit of access removal.

  5. Rule I.E.1
    Independent testing

    Vulnerability assessments and penetration tests by a qualified independent party at least annually and before any new system, including smart contract audits where relevant.

  6. Rule I.E.5 to I.E.8
    Threat-led penetration testing

    Where VARA requires it, run by an accredited external tester carrying professional indemnity insurance.

  7. Rule I.H
    Business continuity and disaster recovery

    A BCDR plan tested and updated annually, with an alternative site and DLT-specific risks such as key storage.

  8. Rule I.K.1
    Incident reporting

    Material cybersecurity events reported to VARA within 72 hours of detection.

VARA Custody Services Rulebook, 19 May 2025

VARA Custody Services

Dubai Virtual Assets Regulatory Authority, Custody Services Rulebook

Status
Current version in force since 19 June 2025. A VARA circular of 6 October 2026 sets the minimum scope of reserve assets audits.
Applies to
VARA licensees providing custody, including staking from custody and collateral wallet services.
Regulators
  • Dubai Virtual Assets Regulatory Authority (VARA)
Assessed in
  • Readiness
  • Maturity
  1. Rule III.B.2, III.B.3
    Segregation

    No rehypothecation even with consent, and each client's assets held in wallets that hold only that client's assets.

  2. Rule III.B.5
    A separate custodian

    Custody run by a separate legal entity from other group virtual asset businesses, with a dedicated custody team.

  3. Rule III.C.1
    Hot, warm and cold storage

    Wallet types chosen by documented risk analysis, with transfer mechanisms between them under internal controls and independent audit.

  4. Rule III.C.2
    Key generation, storage and backup

    Industry-best key generation, backups encrypted as strongly as the primary and stored apart, and seed phrases split into at least two parts.

  5. Rule III.C.2.d, III.C.2.e
    Multi-signature and collusion

    Risk-tiered multi-signature with documented and audited procedures, and collusion risk mitigated.

  6. Rule III.C.3
    Lost or stolen keys

    Policies for key recovery, client communication, law enforcement cooperation and wind-down.

  7. Rule III.D
    Reconciliation and records

    A register of each client's positions, monthly statements, and a full transaction audit trail kept for at least 8 years.

VARA Company Rulebook, 19 May 2025

VARA Company Rulebook

Dubai Virtual Assets Regulatory Authority, Company Rulebook (outsourcing, insurance and wind-down)

Status
Current version in force since 19 June 2025.
Applies to
All VARA-licensed virtual asset service providers.
Regulators
  • Dubai Virtual Assets Regulatory Authority (VARA)
Assessed in
  • Resilience
  • Readiness
  1. Rule II.B
    Segregation of duties

    Dealing, settlement and safekeeping kept apart, and review functions separate from operations.

  2. Rule IV.B
    Outsourcing risk and due diligence

    Each outsourcing assessed before it starts and at least annually, and each provider reviewed at least annually.

  3. Rule IV.C.2.b
    Outsourcing register

    A register of every outsourcing arrangement, flagging material outsourcing and personal data.

  4. Rule IV.D
    Mandatory contract terms

    Information security obligations, tested contingency plans, audit rights, insurance and data location written into outsourcing contracts.

  5. Rule IV.H.3
    Notifying VARA

    VARA told in advance of any new or materially changed material outsourcing.

  6. Rule VI.D.1.c
    Hot wallet insurance

    Commercial crime or similar insurance covering virtual assets held in hot wallets.

  7. Rule VII.A.1
    Wind-down plan

    A wind-down plan covering system redundancy and record retention.

ADGM General Rulebook GEN 3.3 and GEN 3.5

ADGM Cyber Risk Management

Financial Services Regulatory Authority of ADGM, Systems and Controls and Cyber Risk Management rules

Status
GEN 3.5 in force since 31 January 2026.
Applies to
Every firm authorised by the FSRA in or from Abu Dhabi Global Market, including virtual asset firms.
Regulators
  • Financial Services Regulatory Authority (FSRA) of ADGM
Assessed in
  • Maturity
  • Resilience
  • Readiness
  1. GEN 3.5.1, 3.5.3
    Cyber risk management framework

    A written framework approved by the governing body, which sets cyber risk tolerance, reviewed at least annually.

  2. GEN 3.5.4
    Asset inventory and risk assessment

    An ICT asset inventory, with cyber risk assessed at least annually.

  3. GEN 3.5.7, 3.5.8
    Access and authentication

    Least-privilege access, and multi-factor authentication for internet-accessible and privileged access.

  4. GEN 3.5.14
    Resilience testing

    A testing programme that tests internet-facing systems at least annually, such as penetration tests, red team exercises and bug bounties.

  5. GEN 3.5.16, 3.5.17
    Incident response plan

    A cyber incident response plan tested regularly and reviewed at least annually.

  6. GEN 3.5.18
    Incident reporting

    Material cyber incidents reported to the FSRA immediately, and within 24 hours at the latest.

  7. GEN 3.3.31, 3.3.32
    Outsourcing

    The firm stays responsible for outsourced functions and informs the FSRA of material outsourcing.

  8. GEN 3.3.33
    Business continuity

    Continuity and disaster recovery arrangements kept current and tested regularly.

ADGM COBS Chapter 17, VA Guidance VER07 (10 June 2025)

ADGM Virtual Assets

FSRA Conduct of Business rules and Guidance on the Regulation of Virtual Asset Activities

Status
COBS 17 current text dated 16 September 2026. The guidance is not binding but sets the FSRA's expectations.
Applies to
ADGM firms dealing, arranging, managing, providing custody or operating a trading facility in virtual assets or fiat-referenced tokens.
Regulators
  • Financial Services Regulatory Authority (FSRA) of ADGM
Assessed in
  • Readiness
  • Maturity
  1. COBS 17.5.1(a), (b)
    Wallet and key procedures

    Documented wallet setup, backup and recovery, and key generation, storage, backup, destruction and access.

  2. COBS 17.5.1(d), (e)
    Security and risk plans

    A security plan covering data, networks, cloud and facilities, and a risk plan that covers technology and hacking risk.

  3. COBS 17.8.3
    Custody reconciliation

    Client virtual assets reconciled at least weekly, with monthly statements to retail clients.

  4. COBS 17.8.5
    Third-party custodians

    Any third-party custodian assessed against the custody and technology rules before it is used.

  5. Guidance para. 61
    Annual third-party review

    Core systems verified by a third party at least annually; trading facilities and custodians also commission an annual infrastructure review.

  6. Guidance paras. 64 to 67
    Security architecture

    Layered security with no single point of failure, and key cryptographic functions performed only in modules meeting the highest recognised standards.

  7. Guidance para. 33
    Smart contract review

    Smart contracts behind an accepted virtual asset should have had an independent, non-conflicted security review.

CBUAE Circular No. 2 of 2024

CBUAE Payment Token Services

Central Bank of the UAE, Payment Token Services Regulation

Status
In force since 31 August 2024, with a one-year transition period.
Applies to
Payment token issuers and service providers licensed onshore in the UAE, outside the financial free zones.
Regulators
  • Central Bank of the UAE (CBUAE)
Assessed in
  • Readiness
  • Maturity
  1. Art. 35(3), 35(5)
    Technology and cyber risk framework

    A framework that meets at least the UAE Information Assurance Standards.

  2. Art. 35(8)
    Independent technology audit

    Governance that includes an independent technology audit function.

  3. Art. 35(17)
    Penetration testing

    A regular, risk-based assessment of the need for penetration and cyber-attack simulation testing.

  4. Art. 35(18)
    Multi-factor authentication

    Multi-factor authentication required.

  5. Art. 35(25)
    Incident reporting

    Major security incidents reported to the CBUAE immediately.

  6. Art. 22(8)
    Reserve reconciliation

    Daily reconciliation of reserve assets and a monthly external audit.

Australia

3 regimes · 23 provisions mapped

APRA Prudential Standard CPS 234, F2018L01745

APRA CPS 234

Prudential Standard CPS 234 Information Security

Status
In force since 1 July 2019, unamended. Companion guide CPG 234 is current.
Applies to
Banks and other ADIs, insurers and superannuation trustees, and through them the third parties that manage their information assets.
Regulators
  • Australian Prudential Regulation Authority (APRA)
Assessed in
  • Maturity
  • Readiness
  1. Para. 13 to 14
    Board responsibility

    The board is ultimately responsible for information security, with defined roles for management and individuals.

  2. Para. 15 to 17
    Information security capability

    Capability matched to the threats, kept current, and assessed for any third party managing the entity's information assets.

  3. Para. 20
    Asset classification

    All information assets, including those managed by third parties, classified by criticality and sensitivity.

  4. Para. 21 to 22
    Implementation of controls

    Timely controls matched to the threat and the asset, and the design of third parties' controls evaluated.

  5. Para. 23 to 26
    Incident management

    Detection and response for plausible incidents, escalation to the board, and response plans reviewed and tested annually.

  6. Para. 27 to 31
    Testing control effectiveness

    A systematic, risk-based testing program run by skilled and functionally independent testers, reviewed at least annually.

  7. Para. 32 to 34
    Internal audit

    Internal audit reviews the design and operating effectiveness of controls, including third parties'.

  8. Para. 35
    Incident notification

    Material information security incidents notified to APRA within 72 hours of becoming aware.

  9. Para. 36
    Control weakness notification

    A material control weakness that cannot be fixed in time notified within 10 business days.

APRA Prudential Standard CPS 230, F2026L00475

APRA CPS 230

Prudential Standard CPS 230 Operational Risk Management

Status
First applied 1 July 2025. Remade with targeted amendments, in force from 1 July 2026; paragraph numbers below are the current ones.
Applies to
APRA-regulated banks, insurers and superannuation trustees, and their material service providers through contract terms and APRA access rights.
Regulators
  • Australian Prudential Regulation Authority (APRA)
Assessed in
  • Resilience
  • Readiness
  1. Para. 19 to 21
    Board oversight

    The board approves the business continuity plan, tolerance levels and service provider policy.

  2. Para. 23 to 24
    Technology risk

    Sound IT capability, monitoring of the age and health of information assets, and compliance with CPS 234.

  3. Para. 26(b)
    Mapping critical operations

    The people, technology, information, facilities and service providers behind each critical operation, and how they depend on each other.

  4. Para. 32
    Incident notification

    Operational risk incidents with material impact notified to APRA within 72 hours.

  5. Para. 37
    Tolerance levels

    For each critical operation, the maximum period of disruption, maximum data loss and minimum service levels.

  6. Para. 41
    Disruption notification

    A disruption to a critical operation outside tolerance notified within 24 hours.

  7. Para. 42 to 45
    Business continuity testing

    An annual business continuity exercise under severe but plausible scenarios, including the failure of a material service provider.

  8. Para. 46 to 54
    Material service providers

    A register of material service providers submitted annually, with due diligence and agreements that grant APRA access.

Corporations Amendment (Digital Assets Framework) Act 2026, ASIC RG 133

Digital asset platforms

Digital Assets Framework Act and ASIC custody guidance

Status
Act received Royal Assent 8 April 2026 and commences 8 April 2027, with a six-month transition. ASIC standards are in draft under CP 392.
Applies to
Operators of digital asset platforms and tokenised custody platforms, who will need an Australian financial services licence.
Regulators
  • Australian Securities and Investments Commission (ASIC)
  • The Treasury
Assessed in
  • Readiness
  • Maturity
  1. Corporations Act s912BB
    Comply with ASIC standards

    Platform operators must meet ASIC's asset-holding and transactional and settlement standards; a civil penalty provision.

  2. s912BE
    Asset-holding standards

    Standards on safeguarding underlying assets, records, reconciliation and reporting; pooled wallets allowed if records identify each client's tokens.

  3. RG 133.141
    Crypto custody infrastructure

    Specialist custody infrastructure, on-chain segregation, keys in cold storage with hot storage minimised, and independently verified controls.

  4. RG 133.142 to 133.144
    Key and signing controls

    Keys protected online and offline, multi-signature or sharding over a single key, and no single party controlling the whole instruction process.

  5. RG 133.147
    Third-party custodian assurance

    An independent controls audit of any custody provider obtained and considered.

  6. Draft standards s16, s20
    Safeguarding and wallet records

    Proposed: protection against loss or unauthorised transfer, and a quarterly wallet and address report to ASIC.

Standards & frameworks

9 standards · 60 provisions mapped

NIST Cybersecurity Framework 2.0, 26 February 2024

NIST CSF 2.0

The NIST Cybersecurity Framework

Status
Current. Named by the FFIEC and California's DFPI as a baseline after the FFIEC Cybersecurity Assessment Tool was retired in 2025.
Used for
The common profile every Guardian maturity score is expressed in, and the crosswalk most regulators and examiners already read.
Published by
  • National Institute of Standards and Technology (NIST)
Assessed in
  • Maturity
  1. Tiers 1 to 4
    Partial to Adaptive

    Four tiers, Partial, Risk Informed, Repeatable and Adaptive, describing how rigorous the risk management behind the program is.

  2. GV.RR-01, GV.OC-01
    Govern

    Leadership accountable for cybersecurity risk, and the mission understood and used to drive it.

  3. GV.SC-07
    Supply chain

    Risks from suppliers and other third parties understood, recorded, prioritised, assessed, responded to and monitored.

  4. ID.AM-01, ID.RA-08
    Identify

    Inventories of hardware, software and services, and a process for receiving and responding to vulnerability disclosures.

  5. PR.AA-03, PR.AA-05
    Protect: identity and access

    Users, services and hardware authenticated, and access governed by least privilege.

  6. PR.PS-06, PR.DS-11
    Protect: platform and data

    Secure development practices across the lifecycle, and backups created, protected and tested.

  7. DE.CM-01
    Detect

    Networks and services monitored for potentially adverse events.

  8. RS.MA-01, RC.RP-01
    Respond and Recover

    Incident response executed with third parties, and recovery executed from the incident response process.

ISO/IEC 27001:2022, Annex A

ISO/IEC 27001

Information security management systems

Status
Current edition. The transition from the 2013 edition closed on 31 October 2025.
Used for
Certifiable management system; Annex A is the control set most bank partners and exchanges ask about.
Published by
  • ISO and IEC
  • Accredited certification bodies
Assessed in
  • Maturity
  • Readiness
  1. Annex A, 93 controls
    Four themes

    37 organisational, 8 people, 14 physical and 34 technological controls, each assessed for design and operation.

  2. A.5.9
    Asset inventory

    An inventory of information and associated assets, with owners.

  3. A.5.19 to A.5.23
    Suppliers and cloud

    Security across supplier relationships, agreements, the ICT supply chain, monitoring and cloud services.

  4. A.5.24 to A.5.30
    Incidents and continuity

    Incident planning, response and learning, and ICT readiness for business continuity.

  5. A.8.2, A.8.5
    Privileged access and authentication

    Restricted privileged access rights and secure authentication.

  6. A.8.8
    Technical vulnerabilities

    Information about vulnerabilities obtained, exposure evaluated, and measures taken.

  7. A.8.24
    Use of cryptography

    Rules for cryptography, including key management.

  8. A.8.25, A.8.29, A.8.32
    Development, testing and change

    A secure development lifecycle, security testing in development and acceptance, and change management.

AICPA 2017 Trust Services Criteria, revised points of focus 2022

SOC 2

Trust Services Criteria for security, availability, processing integrity, confidentiality and privacy

Status
Current. A SOC 2 report is issued by a licensed CPA firm; Guardian prepares the controls and the evidence it tests.
Used for
Service organisations whose customers, banks or exchanges ask for an independent report on their controls.
Published by
  • American Institute of CPAs (AICPA)
Assessed in
  • Maturity
  • Readiness
  1. CC4.1
    Monitoring of controls

    Ongoing and separate evaluations that confirm controls are present and functioning.

  2. CC6.1, CC6.2
    Logical access

    Logical access security over protected assets, and credentials issued only to registered, authorised users.

  3. CC6.6
    Boundary protection

    Logical access measures against threats from outside the system boundary.

  4. CC7.1, CC7.2
    Vulnerability detection and monitoring

    Detection of configuration changes and new vulnerabilities, and monitoring for anomalies that indicate malicious acts.

  5. CC7.4
    Incident response

    A defined program to understand, contain, remediate and communicate security incidents.

  6. CC8.1
    Change management

    Changes authorised, designed, tested, approved and implemented.

  7. CC9.2
    Vendor risk

    Risks from vendors and business partners assessed and managed.

  8. A1.2, A1.3
    Availability

    Backup and recovery infrastructure, and recovery plan procedures that are tested.

CryptoCurrency Security Standard v9.0

CCSS

The CryptoCurrency Security Standard

Status
Version 9.0 current. Systems, not whole companies, are certified at Level I, II or III.
Used for
Any system that generates, stores or uses cryptocurrency keys: exchanges, custodians, issuers and treasuries.
Published by
  • CryptoCurrency Certification Consortium (C4)
Assessed in
  • Maturity
  • Readiness
  1. 1.01, 1.02
    Key and wallet generation

    Key material generated confidentially from unpredictable randomness, by the actor who will use it.

  2. 1.03
    Key material storage

    Keys and backups stored to resist loss, theft and single points of compromise.

  3. 1.04, 1.05
    Key access and usage

    Who can reach key material, and the controls on every signing operation.

  4. 1.06
    Data sanitization

    Keys and seed material destroyed from retired devices and media, including steel backups.

  5. 2.01
    Security tests and audits

    Independent security testing and audit of the system.

  6. 2.02
    Log and monitor

    Logging and monitoring of key management activity.

  7. 2.03
    Governance and risk

    Keyholder grant and revoke, policies, and risk management around the system.

  8. 2.04
    Key compromise

    A documented, rehearsed response to suspected key compromise.

CIS Critical Security Controls v8.1

CIS Controls

CIS Critical Security Controls

Status
Version 8.1 current. Named by the FFIEC among the replacements for its retired assessment tool.
Used for
A prioritised technical baseline, in three implementation groups, for teams without a mature program yet.
Published by
  • Center for Internet Security (CIS)
Assessed in
  • Maturity
  1. Controls 1, 2
    Inventory

    Inventory and control of enterprise and software assets.

  2. Controls 5, 6
    Accounts and access

    Account management and access control management, including MFA.

  3. Control 7
    Continuous vulnerability management

    Vulnerabilities continuously assessed and remediated.

  4. Controls 8, 13
    Logging and monitoring

    Audit log management and network monitoring and defence.

  5. Control 11
    Data recovery

    Recovery practices that restore assets to a trusted state.

  6. Controls 15, 16
    Providers and applications

    Service provider management and application software security.

  7. Controls 17, 18
    Incident response and testing

    An incident response program and penetration testing.

PCI DSS v4.0.1

PCI DSS

Payment Card Industry Data Security Standard

Status
Version 4.0.1 current; its future-dated requirements became mandatory on 31 March 2025.
Used for
Fintechs, on-ramps and card programs that store, process or transmit cardholder data.
Published by
  • PCI Security Standards Council
  • Card brands and acquirers
Assessed in
  • Readiness
  • Maturity
  1. Req. 6.4.3, 11.6.1
    Payment page integrity

    Scripts on payment pages authorised and inventoried, and unauthorised changes to those pages detected.

  2. Req. 8.4.2
    MFA into the CDE

    Multi-factor authentication for all access into the cardholder data environment.

  3. Req. 11.3
    Vulnerability scans

    Internal and external vulnerability scans at least once every three months.

  4. Req. 11.4
    Penetration testing

    Internal and external penetration testing at least once every 12 months and after significant change.

  5. Req. 12.8
    Third-party service providers

    Providers that could affect cardholder data managed, monitored and contracted for security.

  6. Req. 12.10
    Incident response

    An incident response plan ready to activate immediately, and tested.

ISO 22301:2019

ISO 22301

Security and resilience: business continuity management systems

Status
Current edition.
Used for
A certifiable continuity system, and the vocabulary behind most impact tolerance and recovery objective work.
Published by
  • International Organization for Standardization (ISO)
Assessed in
  • Resilience
  1. Cl. 8.2.2
    Business impact analysis

    Prioritised activities, their dependencies, and the time frames within which disruption becomes unacceptable.

  2. Cl. 8.2.3
    Risk assessment

    Risks of disruption to prioritised activities identified and assessed.

  3. Cl. 8.3, 8.4
    Strategies and plans

    Continuity strategies and documented plans and procedures for responding to disruption.

  4. Cl. 8.5
    Exercise programme

    Plans exercised and tested against their objectives, with results reported.

BCBS d516 and d515, March 2021; third-party principles, December 2025

Basel Committee principles

Principles for Operational Resilience, and for the Sound Management of Operational Risk

Status
Current guidelines; they carry legal force only once a national regulator adopts them. Third-party risk principles finalised 10 December 2025.
Used for
Internationally active banks, and the baseline national bank regulators build their resilience rules on.
Published by
  • Basel Committee on Banking Supervision (BCBS)
  • Bank for International Settlements
Assessed in
  • Resilience
  • Maturity
  1. OR Principle 1
    Governance

    The board approves the resilience approach and the tolerance for disruption to critical operations.

  2. OR Principles 3, 4
    Continuity and mapping

    Continuity plans exercised under severe but plausible scenarios, and the dependencies behind each critical operation mapped.

  3. OR Principle 5
    Third-party dependencies

    Due diligence, equivalent resilience at the third party, and exit strategies.

  4. OR Principles 6, 7
    Incidents and ICT

    Incident management across the full lifecycle, and regularly tested ICT and cyber protection, detection, response and recovery.

  5. PSMOR Principle 10
    ICT risk management

    ICT and cyber risk identified and mitigated, monitored with regular tests, and privileged users managed.

  6. PSMOR Principle 11
    Business continuity planning

    Business impact analysis, recovery time and point objectives, and periodic testing with key providers.

CPMI-IOSCO PFMI (2012), Principle 17; Cyber Guidance (2016)

PFMI Principle 17

Principles for financial market infrastructures: operational risk, and cyber resilience guidance

Status
Current. Applies to stablecoin arrangements that perform a systemically important transfer function, per the 2022 guidance.
Used for
Payment systems, settlement systems, central counterparties, and systemic stablecoin arrangements.
Published by
  • CPMI
  • IOSCO
Assessed in
  • Resilience
  • Maturity
  1. P17 KC1, KC2
    Framework and testing

    A robust operational risk framework, reviewed, audited and tested periodically and after significant change.

  2. P17 KC5
    Security policies

    Physical and information security policies covering all potential vulnerabilities and threats.

  3. P17 KC6
    Two-hour recovery

    Critical IT systems able to resume within two hours, with settlement completed by end of day.

  4. P17 KC7
    Interdependencies

    Risks from key participants, other infrastructures and service providers managed.

  5. Cyber Guidance
    Cyber resilience framework

    Governance, identification, protection, detection, and response and recovery, supported by testing, situational awareness and learning.

ScopeReviewed against primary sources in October 2026 and kept current. Guardian assesses the security, technology, custody and resilience provisions of each regime and produces the evidence for them. We are not a law firm: licensing perimeter, AML programs and legal interpretation stay with your counsel, and we work alongside them.

Bring the regime that worries you.

Tell us where you operate, what you hold for clients, and which licence you are working towards. An hour with your architecture is usually enough to say which provisions apply and where the largest gap sits.

Scope an assessment