Crypto Compliance Evidence Workbook
The security and resilience requirements a crypto firm has to evidence under DORA, MiCA and NYDFS Part 500, each mapped to a control, a test and the artifact a reviewer will ask for. 94 rows, each citing its article.
Start here
How to use the workbook
DORA, MiCA and Part 500 overlap more than they differ. One yearly pentest, one asset inventory or one incident runbook can serve all three if it is scoped once, to the strictest rule.
Each row gives the article, the requirement in the text's own terms (shall, may, expects), who it binds, and a suggested control, test and evidence artifact.
This workbook explains the technical and security side of DORA, MiCA and NYDFS Part 500. It is not legal advice; confirm how they apply to you with counsel.
- Scope first. The Scope rows settle which texts and carve-outs apply to each entity: DORA microenterprise, NYDFS Class A, the 500.19(a) exemption, BitLicense.
- Filter. Pick a regulation or a control area, or search for an article such as 500.12 or 24(6).
- Assign. In the spreadsheet, name an owner for each row and track it in the Status column.
- Collect once. The cross-reference shows where one control and one evidence pack satisfy several rules.
- Re-check. The mapping is as of November 10, 2026. Technical standards and DFS guidance change.
Requirements, articles and the scope notes paraphrase the primary texts. Controls, tests, evidence and suggested frequencies are Guardian's practical suggestions, not text of the rules.
Take it with you: the Excel workbook has a README, one sheet per regulation, a cross-reference sheet and a Status column, or get every row as CSV.
European Union · 42 rows
DORA
Regulation (EU) 2022/2554, applying since January 17, 2025, with its technical standards on ICT risk, incidents, the register of information and TLPT. It covers CASPs authorized under MiCA and issuers of asset-referenced tokens (Art. 2(1)(f)).
Scope and proportionality
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| DORA-01 Art. 2(1)(f); Art. 64 |
DORA applies to crypto-asset service providers authorized under MiCA and to issuers of asset-referenced tokens (Art. 2(1)(f)). It "shall apply from 17 January 2025" (Art. 64). Applies to: MiCA-authorized CASPs and ART issuers. EMT issuers are covered through their own license as credit or e-money institutions (Art. 2(1)(a) and (d); MiCA Art. 48(1)). Note: Microenterprise status (DORA-02) and the Art. 16 list (DORA-03) change what applies. |
Scoping memo per legal entity: license held, DORA status, and which articles and carve-outs apply. Test: Counsel checks the memo against each entity's authorization and the ESMA register. |
Signed scoping memo; authorization decision for each EU entity. | On authorization and on any license change. |
| DORA-02 Art. 3(60); Art. 4(1) |
A microenterprise employs fewer than 10 persons and has an annual turnover and/or balance sheet total of at most EUR 2 million (Art. 3(60)). Chapter II "shall" be applied in proportion to size and risk profile (Art. 4(1)). Applies to: All financial entities. Trading venues, CCPs, trade repositories and CSDs cannot be microenterprises. Note: Rows below flag the duties DORA lifts for microenterprises, such as Art. 6(4), 6(6), 24 and 28(2). |
Size determination per entity, listing each microenterprise carve-out relied on. Test: Check headcount and financial statements against Art. 3(60). |
Size determination memo with HR and finance figures; list of carve-outs used. | No fixed frequency (suggested: each financial year end). |
| DORA-03 Art. 16(1); RTS 2024/1774, Arts 28 to 41 |
Articles 5 to 15 "shall not apply" to the entities listed in Art. 16(1). Those entities follow the simplified ICT risk management framework of Art. 16 and RTS 2024/1774 Title III instead. Applies to: Only Art. 16(1) entities: small and non-interconnected investment firms, exempted payment and e-money institutions, certain institutions exempted under Directive 2013/36/EU, and small IORPs. CASPs and ART issuers are not listed. Note: A small CASP gets relief through the microenterprise carve-outs, not through Art. 16. |
Scoping memo states that the full framework (Arts 5 to 15, RTS 2024/1774 Title II) applies. Test: Counsel confirms the entity type against the Art. 16(1) list. |
Scoping memo section on the ICT risk management framework. | On authorization. |
ICT risk management (Articles 5 to 16, RTS 2024/1774)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| DORA-04 Art. 5(2) |
The management body "shall define, approve, oversee and be responsible for" all arrangements of the ICT risk management framework, and bears "the ultimate responsibility" for ICT risk, including the ICT risk tolerance. Applies to: All in-scope financial entities Note: Art. 13(5) also requires senior ICT staff to report to the management body at least yearly. |
Board-approved ICT risk framework, risk tolerance and resilience strategy, with ICT risk as a standing board item. Test: Review a year of board minutes for approvals and ICT risk reporting. |
Board minutes and approval records; ICT roles and responsibilities matrix. | Ongoing; approvals refreshed with the yearly framework review (Art. 6(5)). |
| DORA-05 Art. 6(1), (5); RTS 2024/1774, Art. 27 |
Shall have a sound, comprehensive and well-documented ICT risk management framework, reviewed at least once a year, after major ICT-related incidents, and after supervisory instructions or testing and audit conclusions. A review report goes to the authority on request. Applies to: All. Microenterprises review "periodically" instead of yearly. Note: RTS Art. 27 requires the report in a searchable electronic format. |
Versioned framework document; yearly review report in the RTS 2024/1774 Art. 27 format. Test: Check review dates against the year's major incidents and test findings. |
Framework; review report with the management body's approval date. | At least yearly; after each major ICT-related incident. |
| DORA-06 Art. 6(4), (6), (7) |
Shall assign ICT risk to a control function with appropriate independence, segregate ICT risk, control and internal audit functions, subject the framework to regular internal audit, and follow up critical audit findings formally. Applies to: Control function and internal audit: not microenterprises. Follow-up process (Art. 6(7)): all. |
Second-line ICT risk function separate from IT operations; ICT audit plan; findings tracker with deadlines. Test: Sample critical ICT audit findings and verify closure evidence. |
Org chart and function charter; ICT audit plan and reports; remediation tracker. | Audit frequency "commensurate to the ICT risk" (Art. 6(6)). |
| DORA-07 Art. 6(8) |
The framework shall include a digital operational resilience strategy: ICT risk tolerance, information security objectives with KPIs and key risk metrics, the ICT reference architecture, detection mechanisms, testing and an incident communication strategy. Applies to: All in-scope financial entities |
Written resilience strategy with tolerance levels and a KPI dashboard reported to the board. Test: Trace each KPI to a data source and a reporting date. |
Approved strategy; KPI and key risk metric reports. | Reviewed with the framework (suggested: yearly). |
| DORA-08 Art. 5(4); Art. 13(6) |
Management body members shall keep their knowledge of ICT risk current, including through regular training. ICT security awareness and resilience training shall be compulsory for all employees and senior management. Applies to: All in-scope financial entities Note: Where appropriate, ICT third-party providers join the training (Art. 13(6)). |
Yearly training with role modules for engineers, signers and the board; phishing simulations. Test: Check completion rates and board attendance. |
Training materials and completion records. | Regular (suggested: yearly). |
| DORA-09 Art. 8(1), (4), (6); RTS 2024/1774, Art. 4(2)(b) |
Shall identify, classify and document ICT-supported business functions and the information and ICT assets behind them, map critical assets and their interdependencies, and keep inventories current. RTS Art. 4 lists the fields to keep per asset. Applies to: All in-scope financial entities Note: Guardian's reading: wallets, signers, nodes and contracts are ICT assets under Art. 3(7). |
Asset inventory covering wallets, signing systems (HSM or MPC), nodes, RPC endpoints, smart contracts, cloud and SaaS, each mapped to the functions it supports. Test: Reconcile the inventory with cloud accounts, the wallet list and deployed contract addresses. |
Inventory export with ID, location, classification, owner, functions, RTO and RPO, internet exposure, dependencies and end of support dates. | Classification reviewed at least yearly; inventories updated at every major change. |
| DORA-10 Art. 8(2), (3), (7); RTS 2024/1774, Art. 3 |
Shall continuously identify sources of ICT risk and assess cyber threats and vulnerabilities, review risk scenarios at least yearly, and assess risk at each major change and on legacy systems. Applies to: All. Change-triggered (Art. 8(3)) and legacy (Art. 8(7)) assessments: not microenterprises. Note: RTS Art. 3 requires accepted residual risks to be reviewed at least once a year. |
ICT risk register with a documented methodology; a risk assessment step in the change process. Test: Sample major changes and confirm a risk assessment came first. |
Methodology; risk register; residual risk acceptances; change-linked assessments. | Continuous; scenarios at least yearly; each major change. |
| DORA-11 Art. 9(4)(c), (d); RTS 2024/1774, Art. 21 |
Shall limit access to what legitimate functions require, on need-to-know and least privilege principles, and use strong authentication for remote access, privileged access, assets supporting critical or important functions and publicly accessible assets. Applies to: All in-scope financial entities |
Single sign-on with phishing-resistant MFA; least privilege roles for custody, cloud, CI/CD and admin consoles; dedicated admin accounts. Test: Attempt privileged and remote logins without a second factor; review role grants on signing systems. |
Access control policy; identity provider MFA enforcement report; role matrix. | Ongoing |
| DORA-12 RTS 2024/1774, Art. 21(e) |
Account procedures shall grant privileged, emergency and admin access on a need-to-use or ad hoc basis, withdraw access without undue delay, and update access rights at least every 6 months for systems supporting critical or important functions. Applies to: All in-scope financial entities |
Six-monthly access recertification for custody, signing, cloud and production systems; leaver workflow tied to HR. Test: Compare admin and signer lists with the HR roster; check leavers' accounts are disabled. |
Signed access review records; leaver tickets with disable timestamps. | At least every 6 months (critical or important functions); at least yearly (other systems). |
| DORA-13 RTS 2024/1774, Art. 6 |
Shall have an encryption policy, based on data classification and ICT risk assessment, with rules for data at rest and in transit, data in use where necessary, internal network connections, traffic with external parties, and key management. Applies to: All in-scope financial entities |
Encryption standard naming approved algorithms and TLS settings; encryption at rest for databases, backups and key material. Test: Scan external and internal endpoints for weak TLS; sample storage for encryption at rest. |
Encryption policy; TLS scan results; storage encryption settings. | Ongoing; updated as cryptanalysis develops (Art. 6(4)). |
| DORA-14 RTS 2024/1774, Art. 7(1) to (3) |
Shall manage cryptographic keys through their whole lifecycle, from generation to destruction, protect them against loss, unauthorized access, disclosure and modification, and implement methods to replace keys that are lost, compromised or damaged. Applies to: All in-scope financial entities Note: Guardian's reading: wallet signing keys and MPC key shares are cryptographic keys under this Article. |
Key ceremony and rotation procedures for HSM or MPC signing; a tested runbook to replace a compromised signer or key share. Test: Observe a key generation or rotation; tabletop a signer compromise and time the replacement. |
Key management procedure; ceremony logs; key replacement test record. | Ongoing (suggested: replacement tested yearly). |
| DORA-15 RTS 2024/1774, Art. 10(2) |
Vulnerability procedures shall include automated vulnerability scanning and assessments, at least weekly for ICT assets supporting critical or important functions, tracking of third-party and open-source libraries, and verified remediation. Applies to: All in-scope financial entities |
Weekly authenticated scans of critical assets; dependency inventory for services and contracts; remediation deadlines by severity. Test: Check scan schedules and the last 8 weeks of reports; trace a critical finding to its fix. |
Scanner schedule and reports; dependency inventory; remediation tracker. | At least weekly (critical or important functions). |
| DORA-16 Art. 9(4)(f); RTS 2024/1774, Art. 10(4) |
Shall have documented patch management: patches identified with automated tools where possible, emergency procedures, testing before deployment, and deadlines with escalation when they are missed. Applies to: All in-scope financial entities |
Patch deadlines by severity, an emergency patch path and an exceptions register. Test: Sample critical patches and compare release, test and deploy dates against the deadline. |
Patch policy; deployment records; exception and escalation log. | Deadlines set by the entity (RTS Art. 10(4)(d)). |
| DORA-17 RTS 2024/1774, Art. 11(2)(b); Art. 13(h), (i) |
Shall set and regularly verify secure configuration baselines, check firewall rules at least every 6 months for systems supporting critical or important functions, and review network architecture and security design once a year. Applies to: All. Microenterprises review network architecture "periodically". |
Hardening baselines for cloud, hosts and containers; six-monthly firewall and security group review; yearly network architecture review. Test: Configuration review against the baseline; diff firewall rules against approved changes. |
Baseline standard; configuration scan results; firewall review sign-offs; architecture review report. | Firewall rules: at least every 6 months (critical). Network architecture: yearly. |
| DORA-18 RTS 2024/1774, Art. 16(2), (3), (8) |
ICT systems shall be tested and approved before use and after maintenance, including source code reviews with static and dynamic testing and security testing of internet-exposed systems. Proprietary software and, where feasible, third-party and open-source code shall be analyzed and tested before production. Applies to: All in-scope financial entities Note: DORA Art. 25(1) also lists "source code reviews where feasible" among the tests. |
Security gate before release: static and dynamic analysis in CI, manual review of security-critical code, an independent audit of smart contracts, and review of third-party code. Test: Independent code review or smart contract audit at the release commit, with a fix review. |
Code review and audit reports; CI scan results; action plan for findings (RTS Art. 16(3)). | Before each deployment and after maintenance. |
| DORA-19 Art. 9(4)(e); RTS 2024/1774, Art. 17(1) |
Changes to software, hardware, firmware, systems or security parameters shall be recorded, tested, assessed, approved, implemented and verified in a controlled manner, with approval independent of whoever requests and implements them. Applies to: All in-scope financial entities Note: Multisig and timelock are Guardian suggestions, not text of the RTS. |
Change approval with segregation of duties; for contract upgrades, multisig approval by independent signers and a timelock where used. Test: Sample production and contract changes for independent approval and a fallback plan. |
Change tickets with approvals; emergency change log with after-the-fact review. | Every change |
| DORA-20 Art. 10(1), (2); RTS 2024/1774, Art. 23 |
Shall have mechanisms to promptly detect anomalous activities, with multiple layers of control, alert thresholds and automatic alerts, at least for assets supporting critical or important functions. Detection mechanisms shall be regularly tested. Applies to: All in-scope financial entities |
Around-the-clock monitoring of infrastructure and onchain activity (privileged calls, upgrades, large movements) with an on-call engineer. Test: Fire test alerts or run a detection exercise and measure time to triage. |
Detection rule catalog; alert test records; on-call rota and response metrics. | Continuous; detection tested regularly (Art. 10(1)). |
| DORA-21 RTS 2024/1774, Art. 12 |
Logging procedures shall set the events to log and their retention, log access, capacity, change, operations and network traffic, protect logs against tampering and deletion, detect logging failures and synchronize clocks. Applies to: All in-scope financial entities |
Central log platform with immutable storage, retention per log class and alerts when a log source stops. Test: Stop a test log source and confirm an alert; check clock synchronization. |
Logging standard; log source inventory; retention and immutability settings. | Continuous |
| DORA-22 Art. 11(1), (2), (5) |
Shall have an ICT business continuity policy, carried out through documented plans that keep critical or important functions running, contain incidents and recover, based on a business impact analysis. Applies to: All in-scope financial entities |
ICT continuity policy and business impact analysis covering custody, withdrawals, trading and client access. Test: Check each critical function has an impact analysis entry, RTO and RPO and a plan owner. |
Continuity policy; business impact analysis; ICT response and recovery plans. | Reviewed regularly, using test results (Art. 11(6)). |
| DORA-23 Art. 11(6); RTS 2024/1774, Art. 25 |
Shall test ICT continuity and response and recovery plans at least yearly and after substantive changes to systems supporting critical or important functions, including cyber-attack and switchover scenarios and failure of ICT third-party providers. Applies to: All. Cyber-attack and switchover scenarios: not microenterprises. Note: The scenarios are Guardian suggestions; the RTS requires severe but plausible ones. |
Yearly exercise program: key compromise, hot wallet drain, cloud region loss, custody or RPC provider outage. Test: Run the exercise; time recovery against RTO and RPO; report gaps to the management body. |
Exercise plans and reports; deficiencies reported to the management body (RTS Art. 25(5)). | At least yearly; after substantive changes. |
| DORA-24 Art. 12(1) to (3), (6) |
Shall document backup policies and restoration procedures, restore onto systems physically and logically segregated from the source, test backup and restoration periodically, and set recovery time and point objectives per function. Applies to: All. Redundant ICT capacity (Art. 12(4)): not microenterprises. |
Encrypted, segregated backups of databases, configuration and key backups; restore drills into an isolated environment. Test: Restore a production backup into a segregated environment and verify integrity. |
Backup policy; restore test records with timings; RTO and RPO register. | Testing "periodically" (Art. 12(2)); suggested at least yearly. |
| DORA-25 Art. 14(1), (3) |
Shall have crisis communication plans for responsible disclosure of major incidents or vulnerabilities to clients, counterparts and the public, and task at least one person with the incident communication strategy and the media function. Applies to: All in-scope financial entities |
Crisis communication plan with prepared client notices and a named spokesperson. Test: Include a client notice step in the yearly incident exercise. |
Crisis communication plan; spokesperson designation; exercise record. | Tested under Art. 11(6)(b). |
Incidents, reporting and threat sharing (Articles 17 to 23, 45)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| DORA-26 Art. 17(1) to (3) |
Shall define, establish and implement an ICT-related incident management process, record all ICT-related incidents and significant cyber threats, set early warning indicators, roles and communication plans, and report major incidents to senior management and the management body. Applies to: All in-scope financial entities |
Incident response procedure with severity levels, an incident register and an escalation matrix. Test: Walk a recent incident through the register and check each required step happened. |
Incident procedure; incident and threat register; management body incident reports. | Every incident |
| DORA-27 Art. 18(1); RTS 2024/1772, Arts 8 and 9 |
Shall classify ICT-related incidents. An incident is major if it affects critical services and either involves successful, malicious and unauthorized access that may cause data losses, or meets two or more other materiality thresholds. Applies to: All. The monthly check for recurring incidents (RTS Art. 8(2)) does not apply to microenterprises. Note: Guardian's reading: a drained hot wallet will usually meet the unauthorized access test. |
Classification worksheet in the incident tool with the RTS thresholds: over 10% of a service's clients or over 100,000 clients, over 2 hours of downtime on critical services, losses over EUR 100,000. Test: Tabletop: classify a hot wallet drain and a signer compromise against the thresholds. |
Classification record with timestamps for each incident. | Every incident; recurring incidents assessed monthly. |
| DORA-28 Art. 19(1), (4); RTS 2025/301, Art. 5 |
Shall report major ICT-related incidents to the competent authority: initial notification within 4 hours of classification and no later than 24 hours after awareness; intermediate report within 72 hours of it; final report within one month of the latest intermediate report. Applies to: All in-scope financial entities Note: A deadline on a weekend or bank holiday may move to noon the next working day (RTS Art. 5(4)), unless Art. 5(5) or (6) applies. |
Reporting runbook with prefilled templates, a named submitter and a clock that starts at classification. Test: Dry run: produce an initial notification from a tabletop incident inside 4 hours. |
Submitted notifications and reports with timestamps; runbook. | Every major incident |
| DORA-29 Art. 19(3) |
Where a major incident affects clients' financial interests, shall inform clients without undue delay of the incident and the measures taken. Applies to: All in-scope financial entities |
Client notice templates per incident type, approved in advance. Test: Include a client notice in the reporting dry run. |
Client notices sent, with timestamps. | Every major incident with client impact |
| DORA-30 Art. 13(2); Art. 17(2) |
Shall run post-incident reviews after a major ICT-related incident disrupts core activities, identifying causes and required improvements, and shall identify, document and address root causes. Applies to: All. Sending the resulting changes to the authority on request: not microenterprises. |
Post-incident review template with root cause, timeline and an owner per improvement. Test: Check the last major incident's review and the status of its actions. |
Post-incident review reports; improvement tracker. | After each major incident |
| DORA-31 Art. 19(2); Art. 45(1), (3) |
May notify significant cyber threats to the authority on a voluntary basis, and may share threat intelligence within trusted communities. Shall notify the authority on joining or leaving a sharing arrangement. Applies to: All in-scope financial entities (voluntary) Note: Voluntary: the text says "may" in Art. 19(2) and Art. 45(1). |
Decision record on threat sharing; register of sharing memberships. Test: Check an authority notification exists for each membership change. |
Membership notifications; voluntary threat notifications sent. | On joining or leaving an arrangement |
Resilience testing (Articles 24 to 27, RTS 2025/1190)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| DORA-32 Art. 24(1), (3) to (5) |
Shall run a risk-based digital operational resilience testing program, with tests by independent internal or external parties, and procedures to prioritize, classify and remedy every issue found, validating that each is fully addressed. Applies to: Not microenterprises |
Written test program mapping each critical or important function to its tests, testers and retest rule. Test: Check tester independence and that every finding has a validated closure. |
Test program; independence statements; remediation and retest records. | Reviewed regularly (Art. 24(1)). |
| DORA-33 Art. 24(6); Art. 25(1), (3) |
Shall ensure, at least yearly, appropriate tests on all ICT systems and applications supporting critical or important functions, such as vulnerability scans, network security assessments, source code reviews where feasible, scenario-based tests and penetration testing. Applies to: Not microenterprises. Microenterprises test on a risk-based plan (Art. 25(3)). Note: The scope list is Guardian's suggestion; the text requires all systems supporting critical or important functions. |
Yearly pentests of custody and signing services, withdrawal flows, client apps and APIs, and cloud; audits of the smart contracts the services rely on. Test: Independent pentest and code review scoped to critical or important functions, with retests. |
Test reports with scope mapped to functions; retest results; remediation records. | At least yearly |
| DORA-34 Art. 26(1), (8); RTS 2025/1190, Art. 2 |
Entities their authority identifies shall carry out threat-led penetration testing (TLPT) at least every 3 years; the authority may raise or lower the frequency. RTS Art. 2(2) lists entities required by default. Applies to: Only entities the TLPT authority identifies; never Art. 16(1) entities or microenterprises. CASPs are not on the default list but can be identified under RTS Art. 2(1). |
Track TLPT status with the authority; keep the critical function map ready for scoping. Test: None until notified (suggested: confirm status yearly). |
Authority notification, or a record that none was received. | At least every 3 years, if identified |
| DORA-35 Art. 26(2); RTS 2025/1190, Art. 9 |
Each TLPT shall cover several or all critical or important functions on live production systems. After the authority's notification, initiation documents are due within 3 months and a scope specification, approved by the management body, within 6 months. Applies to: Entities identified for TLPT |
Named control team lead; project charter and scope document templates prepared. Test: Check submission dates against the notification date. |
Project charter; scope specification document; management body approval. | Per TLPT |
| DORA-36 Art. 27; Art. 26(8); RTS 2025/1190, Art. 7 |
TLPT testers shall meet Art. 27: suitability, expertise, certification or codes of conduct, independent assurance and indemnity insurance. External testers give at least five references. Internal testers need approval, and an external tester is used every third test. Applies to: Entities identified for TLPT |
Tester due diligence file against Art. 27 and RTS Art. 7, completed before contracting. Test: Check the file against each requirement before consulting the test managers. |
CVs, certifications, references, insurance certificates, independence declarations. | Per TLPT |
| DORA-37 Art. 26(6), (7); RTS 2025/1190, Arts 11 to 13 |
Active red team testing shall last at least 12 weeks. The red team report is due within 4 weeks of its end, the blue team report and replay within 10 weeks, and the summary and remediation plans within 8 weeks of the authority's notice that the reports are complete. Applies to: Entities identified for TLPT Note: The remediation plan gives a root cause analysis for each finding (RTS Art. 13(2)(c)). |
TLPT timeline tracker with every RTS deadline; remediation plan template with a root cause per finding. Test: Check each deliverable date against the RTS clock. |
Red and blue team reports; summary report; remediation plan; authority attestation. | Per TLPT |
ICT third-party risk (Articles 28 to 30)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| DORA-38 Art. 28(1)(a), (2); RTS 2024/1773 |
The entity remains "fully responsible" for compliance when it uses ICT services, and shall adopt and regularly review a strategy on ICT third-party risk, with a policy on services supporting critical or important functions. Applies to: Responsibility: all. Strategy and policy: not Art. 16(1) entities or microenterprises. |
Third-party risk strategy and policy approved by the management body. Test: Check the policy covers each contract lifecycle stage in RTS 2024/1773. |
Approved strategy and policy; management body review record. | Reviewed regularly (Art. 28(2)). |
| DORA-39 Art. 28(3); ITS 2024/2956, Art. 3 |
Shall maintain and update a register of information on all ICT service contracts, in the ITS templates, report new arrangements to the authority at least yearly, provide the register on request, and tell the authority in time about planned contracts for critical or important functions. Applies to: All in-scope financial entities Note: Guardian's reading: custody and MPC providers, node and RPC providers, cloud, KYC and blockchain analytics vendors all belong in it. |
Register in the ITS 2024/2956 format, with an LEI or EUID for each provider and the subcontractors behind critical services. Test: Reconcile the register with accounts payable and the asset inventory. |
Register of information file; submission confirmation to the authority. | Ongoing; reporting at least yearly, on the date the authority sets. |
| DORA-40 Art. 28(4), (5); Art. 29 |
Before contracting, shall assess whether a service supports a critical or important function, identify risks including concentration risk, run due diligence on the provider and check conflicts of interest. May only contract providers that meet appropriate information security standards. Applies to: All in-scope financial entities |
Pre-contract risk assessment and security due diligence questionnaire for each ICT provider. Test: Sample recent contracts for an assessment dated before signature. |
Pre-contract risk assessments; due diligence files; concentration risk analysis. | Before each new contract |
| DORA-41 Art. 30(2), (3) |
ICT contracts shall include the minimum terms of Art. 30(2). Contracts for critical or important functions shall also include full service levels, security and continuity testing duties, TLPT participation, unrestricted access, inspection and audit rights, and exit strategies. Applies to: All. A microenterprise may agree to delegate its audit rights to an independent third party (Art. 30(3)). |
Clause checklist per contract, with gaps tracked to renegotiation. Test: Check critical function contracts clause by clause. |
Clause checklist per contract; signed amendments. | At contracting and renewal |
| DORA-42 Art. 28(8) |
Shall put in place exit strategies for ICT services supporting critical or important functions, with documented exit plans that are sufficiently tested and reviewed periodically. Applies to: All in-scope financial entities |
Exit plan per critical provider (custody, cloud, RPC), naming the alternative and the transfer steps. Test: Tabletop or partial migration test of the exit plan for the most critical provider. |
Exit plans; exit test records. | Tested and reviewed periodically |
European Union · 21 rows
MiCA
Regulation (EU) 2023/1114, applying in full since December 30, 2024, and the authorization RTS, Delegated Regulation (EU) 2025/305. The transitional period for existing CASPs ended on July 1, 2026 at the latest. For ICT, MiCA points to DORA.
Scope and the authorization file (Articles 59, 62, 143, RTS 2025/305)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| MICA-01 Art. 59(1); Art. 143(3) |
Crypto-asset services in the EU require CASP authorization or an Art. 60 notification (Art. 59(1)). CASPs active under national law before December 30, 2024 "may continue to do so until 1 July 2026", or until authorized or refused, whichever is sooner. Applies to: All providers of crypto-asset services to EU clients. Member States could shorten or disapply the transitional period. Note: ESMA (April 17, 2026): after July 1, 2026, serving EU clients without a MiCA license is a breach of EU law. |
Authorization status confirmed for each EU entity and service; unauthorized entities wound down. Test: Check each entity and service against the ESMA register. |
Authorization decision; ESMA register extract; wind-down and client migration records. | Deadline passed: July 1, 2026. |
| MICA-02 Art. 62(2)(j); RTS 2025/305, Art. 9(a), (d) |
The application shall contain technical documentation of the ICT systems and security arrangements, with a non-technical description. The RTS asks how the applicant complies with DORA: ICT risk framework, ICT services for critical or important functions (in-house and third-party, with contracts), and security and incident management. Applies to: CASP applicants under Art. 62. Art. 60 entities notify the same ICT documentation under Art. 60(7)(c). |
ICT documentation pack: architecture and data flow diagrams, the DLT infrastructure relied on, DORA control descriptions, critical third-party contracts. Test: Gap review of the pack against RTS Art. 9(a)(i) to (iii) before filing. |
ICT technical documentation; non-technical summary; copies of critical ICT contracts. | With the application (suggested: kept current after authorization). |
| MICA-03 RTS 2025/305, Art. 9(b)(i) to (iv), (c) |
If available, a description of a cybersecurity audit by a sufficiently experienced third-party auditor, covering "ideally": organizational and physical security and secure development; vulnerability scans and network assessments; configuration reviews; and black, gray and white box pentests of assets supporting critical and important functions. Applies to: CASP applicants Note: "If available" and "ideally": not a stand-alone pentest mandate. Point (iv) cites DORA Art. 3(17), the TLPT definition; point (iii) cites Art. 3(22). The yearly test duty is DORA Art. 24(6). |
Third-party audit before filing: pentests in all three box approaches, configuration review and secure development review, on critical or important functions. Test: Pentest of client apps, APIs, custody and withdrawal systems and cloud, with retest. |
Audit and pentest reports; description of the audit for the file; retest results. | With the application |
| MICA-04 RTS 2025/305, Art. 9(b)(v) |
Where the applicant uses or develops smart contracts, the described audit covers, ideally, "a cybersecurity source code review of them". Applies to: CASP applicants that use or develop smart contracts Note: Same "if available" framing as the rest of Art. 9(b). |
Independent smart contract audit of every contract the services rely on, at the deployed commit, with a fix review. Test: Smart contract audit; verify deployed bytecode matches the audited commit. |
Audit reports; fix review; deployed address to commit mapping. | With the application (suggested: again on material contract changes). |
| MICA-05 Art. 62(2)(i); RTS 2025/305, Art. 5 |
Applicants shall describe the business continuity plan in detail, proving it is appropriate and maintained and periodically tested, covering failure of critical functions run by third parties and the death of a key person. Applies to: CASP applicants Note: The key holder scenario is a Guardian suggestion. |
Continuity plan covering third-party failure and key person loss, including signer key holders. Test: Yearly continuity exercise with a key holder unavailability scenario. |
Continuity plan; test records; succession arrangements for key people. | With the application; plan tested periodically. |
| MICA-06 RTS 2025/305, Art. 10(1)(a) to (c) |
Applicants holding client assets shall describe how client wallets differ from their own, the approval system for cryptographic keys and their safeguarding, including multi-signature wallets, and segregation inside omnibus wallets. Applies to: CASP applicants that hold client crypto-assets, keys or funds |
Signer inventory, approval policies (quorums and roles) and a key safeguarding description that match the live setup. Test: Custody and key management review: compare documented quorums with the onchain and MPC configuration. |
Wallet and signer inventory; approval policy; key safeguarding description. | With the application (suggested: on each signer change). |
Organizational requirements for CASPs (Articles 68, 70, 73)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| MICA-07 Art. 68(7) |
Shall take all reasonable steps to ensure continuity and regularity of services, using resilient and secure ICT systems as DORA requires, with a business continuity policy that includes ICT continuity and response and recovery plans under DORA Arts 11 and 12. Applies to: All CASPs Note: MiCA points to DORA for the ICT content, so one program can serve both. |
One continuity program serving MiCA and DORA (DORA-22 to DORA-24). Test: As DORA-23 |
As DORA-22 to DORA-24 | Ongoing |
| MICA-08 Art. 68(6), (8) |
The management body shall assess and periodically review the effectiveness of policies and procedures. CASPs shall have the mechanisms, systems and procedures DORA requires, evaluate them regularly, and safeguard the availability, authenticity, integrity and confidentiality of data under DORA. Applies to: All CASPs |
Yearly control effectiveness review presented to the management body. Test: Internal audit or independent review of control effectiveness. |
Effectiveness review report; management body minutes; remediation plan. | "Periodically" and "on a regular basis" (suggested: yearly). |
| MICA-09 Art. 68(9); RTS 2025/1140 |
Shall keep records of all crypto-asset services, activities, orders and transactions, sufficient for supervision, for five years, or up to seven if the authority asks. RTS 2025/1140 specifies the records. Applies to: All CASPs |
Append-only record store with retention locks and tested retrieval. Test: Retrieve a sample of old records; check the integrity controls. |
Retention settings; retrieval test record. | Retention: five years (up to seven on request). |
| MICA-10 Art. 70(1) |
CASPs holding clients' crypto-assets or the means of access shall make adequate arrangements to safeguard clients' ownership rights, especially in insolvency, and to prevent use of clients' crypto-assets for their own account. Applies to: CASPs holding client crypto-assets or keys |
Segregated client wallets; daily reconciliation of onchain balances with the client ledger. Test: Reconcile onchain balances to the ledger on a sample date; review movement approvals. |
Wallet segregation map; reconciliation reports; exceptions log. | Ongoing (suggested: daily reconciliation). |
| MICA-11 Art. 73(1) to (3) |
CASPs that outsource operational functions shall avoid additional operational risk and remain fully responsible, shall have an outsourcing policy with contingency plans and exit strategies, and shall set rights and obligations in a written agreement with a right to terminate. Applies to: All CASPs that outsource |
Outsourcing policy aligned with the DORA register and exit plans (DORA-39, DORA-42). Test: Check each outsourcing contract for the Art. 73(1) conditions and a termination right. |
Outsourcing policy; contracts; exit plans. | At contracting (suggested: policy reviewed yearly). |
Custody and administration (Article 75)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| MICA-12 Art. 75(3); RTS 2025/305, Art. 12(b), (d) |
Custodians shall have a custody policy that ensures safekeeping or control of crypto-assets or the means of access, and minimizes the risk of loss "due to fraud, cyber threats or negligence". A summary is given to clients on request. Applies to: CASPs providing custody and administration |
Custody policy covering key generation, storage, signing, transaction approval, backups and recovery, with the operational and ICT risk analysis RTS Art. 12(b) asks for. Test: Observe a key ceremony; test recovery from backup material; review who can move assets. |
Custody policy and client summary; ceremony records; recovery test record. | Ongoing (suggested: reviewed yearly). |
| MICA-13 Art. 75(2), (7) |
Shall keep a register of positions per client and segregate client holdings from own holdings, with client crypto-assets held separately on the ledger and operationally segregated. Applies to: CASPs providing custody and administration |
Separate onchain addresses for client and house funds; register of positions reconciled to the chain. Test: Trace a sample of client positions to onchain addresses. |
Register of positions; address map; reconciliation reports. | Movements recorded "as soon as possible" (Art. 75(2)). |
| MICA-14 Art. 75(1)(d), (e); Art. 82(1)(c) |
Custody agreements shall describe the means of communication, including the client's authentication system, and the security systems used. Transfer service agreements shall also describe the security systems used. Applies to: CASPs providing custody or transfer services |
Client terms with an accurate security section, reviewed at each material change. Test: Compare the agreement text with the deployed authentication and security controls. |
Client agreements; change history of the security section. | At each material change (suggested). |
| MICA-15 Art. 75(8) |
Custodians shall be liable for loss of crypto-assets or means of access from an incident attributable to them, capped at market value at the time of loss. Events shown to be independent of the service, such as a problem inherent in a ledger the CASP does not control, are not attributable. Applies to: CASPs providing custody and administration Note: The logging control is Guardian's suggestion for showing whether an incident was attributable. |
Forensic-grade logs of signing and custody operations, so the cause of a loss can be shown. Test: Incident exercise: reconstruct a simulated loss from the logs alone. |
Signing and approval logs; incident reconstruction record. | Ongoing |
| MICA-16 Art. 75(9) |
Custodians that use other custody providers shall only use CASPs authorized under Art. 59, and shall inform clients. Applies to: CASPs providing custody that use sub-custodians Note: ESMA (April 17, 2026) notes MiCA prohibits delegating custody to entities not authorized as CASPs. |
Sub-custodian list checked against the ESMA register. Test: Check each sub-custodian's authorization. |
Register extracts; client disclosures. | Before appointment (suggested: re-checked yearly). |
Trading platforms and transfers (Articles 76, 82)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| MICA-17 Art. 76(7) |
Trading platform operators shall have effective systems so trading systems are resilient, handle peak volumes, stay orderly under severe stress, reject erroneous or out-of-threshold orders, are fully tested, have continuity arrangements, and resist market abuse and money laundering. Applies to: CASPs operating a trading platform |
Load and failover testing of the matching engine; pre-trade price and volume checks. Test: Peak-load test above record volume; erroneous order rejection tests. |
Capacity and stress test reports; pre-trade control test results. | "Fully tested": no fixed frequency (suggested: before major releases and yearly). |
| MICA-18 RTS 2025/305, Art. 17(b), (c) |
Transfer service applicants shall describe their arrangements and ICT and human resources to address risks promptly, including operational failures and cybersecurity risks, and, where available, insurance covering cyber detriment to client assets. Applies to: CASP applicants providing transfer services |
Withdrawal controls: address allowlists, velocity limits, approval thresholds and monitoring. Test: Pentest of withdrawal flows, including approval bypass and address substitution. |
Withdrawal control description; pentest report; insurance policy where held. | With the application |
Issuers of asset-referenced tokens (Articles 34, 37)
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| MICA-19 Art. 34(6), (9) to (11) |
ART issuers shall keep systems and security access protocols in line with appropriate Union standards, have a business continuity policy and plans, internal controls for ICT systems as DORA requires, and systems safeguarding data under DORA and the GDPR. Applies to: Issuers of asset-referenced tokens |
The DORA program (DORA-04 to DORA-42) applied to issuance, redemption and reserve systems. Test: As the matching DORA rows |
As the matching DORA rows | Ongoing |
| MICA-20 Art. 34(5)(d) to (f) |
ART issuers shall establish policies and procedures on the issuance and redemption mechanism, the protocols for validating transactions, and the functioning of their proprietary DLT where they or a third party operate it. Applies to: Issuers of asset-referenced tokens |
Documented mint, burn and role controls; independent smart contract audit of the token and issuance contracts. Test: Smart contract audit with a privileged role map; test of mint and redeem authorization. |
Audit report; privileged role map; issuance procedure. | Before launch and on each contract change (suggested). |
| MICA-21 Art. 37(1), (3) to (5) |
ART issuers shall have custody policies so reserve assets are unencumbered, promptly accessible and not concentrated, held within five working days by an eligible custodian (a CASP for crypto-asset reserves) chosen with due skill, care and diligence. Applies to: ART issuers; also issuers of significant e-money tokens (Art. 58(1)(a)). |
Reserve custodian due diligence covering safekeeping procedures and key management. Test: Review the custodian's key management and access controls; confirm segregation. |
Custodian due diligence file; custody agreement; reserve reconciliation. | Custodian appointments reviewed "on a regular basis" (Art. 37(5)). |
New York · United States · 31 rows
NYDFS Part 500
23 NYCRR Part 500, DFS's cybersecurity regulation, as amended effective November 1, 2023; every phase-in had ended by November 1, 2025. BitLicense holders also follow Part 200's own cybersecurity sections, 200.16 and 200.17, shown where they differ.
Scope, exemptions and phase-in
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-01 500.1(e) |
A covered entity is any person operating under, or required to operate under, a license, registration, charter or similar authorization under the Banking Law, Insurance Law or Financial Services Law. Applies to: BitLicense holders, trust companies chartered under the Banking Law, and other DFS licensees Note: DFS (August 2, 2022): "All virtual currency companies licensed in New York State are subject to the same" cybersecurity regulations as traditional financial services companies. |
Scoping memo listing each DFS license and the Part 500 and Part 200 sections that apply. Test: Counsel review against the license list. |
Scoping memo; license certificates. | On licensing and any change. |
| NYDFS-02 500.1(d) |
A Class A company has at least $20 million in gross annual revenue in each of the last two fiscal years (its own operations plus affiliates' New York operations) and either over 2,000 employees or over $1 billion in group revenue. Applies to: All covered entities, to establish status. Class A adds duties in 500.2(c), 500.7(c) and 500.14(b). |
Yearly Class A determination applying the affiliate rule in 500.1(d). Test: Check two years of revenue and headcount, counting only affiliates that share systems or the program. |
Class A determination memo with figures. | No fixed frequency (suggested: yearly). |
| NYDFS-03 500.19(a), (f), (h) |
Entities with fewer than 20 employees and contractors, under $7.5 million revenue in each of the last three fiscal years, or under $15 million in year-end assets are exempt from 500.4, 500.5, 500.6, 500.8, 500.10, 500.14(a)(1), (a)(2) and (b), 500.15 and 500.16, and shall file a notice of exemption. Applies to: Covered entities meeting any one 500.19(a) test Note: Part 200.16 and 200.17 contain no exemption of their own, and 500.19(a) lists only Part 500 sections. BitLicensees should confirm with counsel. |
Yearly exemption test; notice filed; the remaining sections still implemented. Test: Check the figures, with affiliates as defined, against each test. |
Exemption determination; notice of exemption confirmation. | Notice within 30 days of the determination; 180 days to comply after ceasing to qualify. |
| NYDFS-04 500.21(b); 500.22(d) |
The second amendment took effect November 1, 2023. Its last transitional periods, for universal MFA (500.12) and the asset inventory (500.13(a)), ended November 1, 2025. Applies to: All covered entities Note: 500.22(d) also set 30-day, one-year and 18-month periods for other sections; all have passed. |
Gap register with every phased requirement closed. Test: Confirm each phased section is implemented. |
Gap register with closure evidence. | All phase-ins complete since November 1, 2025. |
Governance, policy and risk assessment
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-05 500.2(a), (b) |
Shall maintain a cybersecurity program, based on the risk assessment, designed to identify, protect, detect, respond, recover and meet regulatory reporting obligations. Applies to: All covered entities |
Program charter mapping each core function to its controls and owners. Test: Trace each core function to an operating control with evidence. |
Program charter; control map. | Ongoing |
| NYDFS-06 500.2(c) |
Each Class A company shall design and conduct independent audits of its cybersecurity program based on its risk assessment. Applies to: Class A companies |
Independent cybersecurity program audit by internal audit or an external firm. Test: Check the auditor's independence (500.1(h)) and the audit scope against the risk assessment. |
Audit plan and report; management responses. | No fixed frequency (suggested: yearly). |
| NYDFS-07 500.3 |
Shall implement written cybersecurity policies, approved at least annually by a senior officer or the senior governing body, covering the 15 listed areas, from information security to vulnerability management. Applies to: All covered entities Note: BitLicensees also need board approval of a 13-area policy under 200.16(b) (NYDFS-09). |
Policy set mapped to areas (a) to (o), with yearly approval. Test: Check each area has a policy section and the approval is under 12 months old. |
Policy set; approval record. | Approved at least annually |
| NYDFS-08 500.4(a) to (d) |
Shall designate a CISO, who reports in writing at least annually to the senior governing body and reports material issues in good time. The senior governing body shall exercise oversight, including confirming sufficient resources. Applies to: Covered entities without the 500.19(a) exemption Note: A CISO employed by an affiliate or third party is allowed, under the conditions in 500.4(a)(1) to (3). |
CISO designation; yearly written CISO report covering 500.4(b)(1) to (6); board minutes showing oversight. Test: Check the report covers each listed item and that the board reviewed it. |
CISO designation; annual CISO report; board minutes. | CISO report at least annually |
| NYDFS-09 200.16(b) to (d) |
BitLicensees shall have a written cyber security policy, approved by the board at least annually, covering 13 areas including changes to core protocols they do not control; designate a qualified employee as CISO; and submit an annual CISO report to DFS. Applies to: BitLicense holders Note: Part 200 says "qualified employee" for the CISO; Part 500 also allows an affiliate or third-party CISO. |
Policy section on core protocol changes such as forks and chain upgrades; CISO report filed with DFS. Test: Check the board approval date and the DFS submission of the CISO report. |
Board-approved policy; CISO report and its DFS submission record. | At least annually |
| NYDFS-10 500.9 |
Shall conduct a documented risk assessment, under written policies, reviewed and updated at least annually and whenever a business or technology change materially changes cyber risk. Applies to: All covered entities Note: DFS guidance (September 10, 2026): the Department "expects" entities to show how the assessment informed controls and risk acceptance. |
Risk assessment method covering all assets, third parties and NPI flows, linked to control decisions. Test: Pick three controls and trace each to the risk it treats. |
Risk assessment report; methodology; risk acceptance records. | At least annually; on material change |
| NYDFS-11 500.10; 500.14(a)(3); 200.16(g) |
Shall use qualified cybersecurity personnel kept current through training, and shall provide at least annual cybersecurity awareness training, including social engineering, to all personnel. Applies to: Awareness training: all. 500.10: not the 500.19(a) exemption. 200.16(g): BitLicensees. |
Yearly awareness training with social engineering; role training for security staff. Test: Check completion rates; run a phishing simulation. |
Training records; simulation results. | Awareness training at least annually |
Pentesting, vulnerabilities and application security
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-12 500.5(a)(1) |
Vulnerability management shall ensure penetration testing of information systems from both inside and outside their boundaries, by a qualified internal or external party, at least annually. Applies to: Covered entities without the 500.19(a) exemption |
Yearly internal and external pentest of exchange, wallet and admin systems, APIs and cloud. Test: Independent pentest from an external and an assumed-internal position, with retests of fixes. |
Pentest reports showing both positions; tester qualifications; retest results. | At least annually |
| NYDFS-13 500.5(a)(2), (b), (c) |
Shall run automated scans, and manually review systems the scans miss, at a frequency set by the risk assessment and promptly after material system changes; monitor for new vulnerabilities; and remediate in good time by risk. Applies to: Covered entities without the 500.19(a) exemption |
Scan schedule set in the risk assessment; a scan step in the change process; remediation deadlines. Test: Check scans ran after the last three material changes; review missed deadlines. |
Scan schedule and reports; change-linked scans; remediation metrics. | Risk-based; promptly after material changes |
| NYDFS-14 200.16(e)(1) |
BitLicensees "shall conduct penetration testing of its electronic systems, at least annually, and vulnerability assessment of those systems, at least quarterly." Applies to: BitLicense holders |
The 500.5 pentest scoped to all electronic systems; quarterly vulnerability assessments. Test: Check four quarterly assessments and one pentest in the last 12 months. |
Quarterly assessment reports; annual pentest report. | Pentest at least annually; vulnerability assessment at least quarterly |
| NYDFS-15 500.8; 200.16(f) |
Shall have written secure development procedures for in-house applications and procedures to evaluate or test external applications, reviewed by the CISO at least annually. BitLicensees cover all applications they use. Applies to: 500.8: not the 500.19(a) exemption. 200.16(f): BitLicensees. Note: Smart contract audits are Guardian's suggestion where the application is a contract. |
Secure development standard, with independent smart contract audits and code review of wallet and exchange services. Test: Sample releases for security review evidence; check the CISO's yearly review. |
Secure development procedures; CISO review sign-off; code review and audit reports. | CISO review at least annually |
Access, MFA and encryption
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-16 500.7(a), (b) |
Shall limit user and privileged access to what each job requires, use privileged accounts only when needed, review all access at least annually, secure remote control protocols, promptly end leavers' access, and keep a password policy meeting industry standards. Applies to: All covered entities |
Least privilege roles; yearly access review (six-monthly on critical systems, which also meets DORA); leaver automation. Test: Compare privileged accounts with job roles; check leavers' removal dates. |
Access review records; privileged account inventory; password policy. | Access review at least annually |
| NYDFS-17 500.7(c) |
Each Class A company shall monitor privileged access activity and implement a privileged access management solution and automated blocking of commonly used passwords, or CISO-approved compensating controls reviewed annually. Applies to: Class A companies |
Privileged access management for admin, cloud and signing infrastructure; banned password list in the identity provider. Test: Attempt a common password; review session logs for a sample of admins. |
PAM settings and logs; password blocking setting; CISO approvals, if any. | Ongoing; compensating controls approved at least annually |
| NYDFS-18 500.12 |
Multi-factor authentication "shall be utilized for any individual accessing any information systems". Under the 500.19(a) exemption, MFA covers remote access, third-party apps holding NPI and privileged accounts. A CISO may approve compensating controls in writing. Applies to: All covered entities; narrower scope under the 500.19(a) exemption Note: In full force since November 1, 2025 (500.22(d)(4)). |
MFA enforced in the identity provider for every user and system, phishing-resistant for admins and signers. Test: Export users without MFA; attempt access to internal tools without a second factor. |
MFA coverage report; CISO compensating control approvals. | Ongoing; compensating controls reviewed at least annually |
| NYDFS-19 500.15 |
Shall implement a written policy requiring encryption meeting industry standards for NPI in transit over external networks and at rest. Where encryption at rest is infeasible, CISO-approved compensating controls may be used, reviewed at least annually. Applies to: Covered entities without the 500.19(a) exemption |
One encryption standard shared with DORA (DORA-13). Test: TLS scan of external endpoints; sample data stores for encryption at rest. |
Encryption policy; scan results; CISO approvals for any exceptions. | Compensating controls reviewed at least annually |
Asset inventory, audit trail and monitoring
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-20 500.13(a) |
Shall maintain a complete, accurate and documented asset inventory of information systems, tracking owner, location, classification or sensitivity, support expiration date and recovery time objective, with a set frequency to update and validate it. Applies to: All covered entities |
One inventory serving DORA and Part 500 (DORA-09), including wallets, signers and contracts. Test: Reconcile the inventory to cloud accounts and endpoint management. |
Inventory export with the 500.13(a)(1) fields; validation records. | As the policy sets (500.13(a)(2)); in force since November 1, 2025 |
| NYDFS-21 500.6 |
Shall securely maintain systems that can reconstruct material financial transactions, and audit trails designed to detect and respond to material cybersecurity events, keeping those records for at least five and three years respectively. Applies to: Covered entities without the 500.19(a) exemption |
Immutable transaction and security log stores with retention locks. Test: Reconstruct a sample transaction end to end; check retention settings. |
Retention settings; reconstruction test. | Retention: 5 years (transactions), 3 years (audit trails) |
| NYDFS-22 200.16(e)(2) |
BitLicensees shall maintain audit trail systems that reconstruct all financial transactions and accounting, protect audit data and hardware from tampering, and log access to the audit systems and all system administrator functions. Applies to: BitLicense holders Note: Part 200 covers all financial transactions; 500.6 covers material ones. |
Tamper-evident audit logging that covers admin actions on wallets and ledgers. Test: Attempt to alter an audit record as an admin and confirm it is detected. |
Audit trail design; admin action logs; tamper test record. | Ongoing; books and records kept at least seven years (200.12) |
| NYDFS-23 500.14(a)(1), (2), (b) |
Shall monitor authorized users' activity to detect unauthorized access to or tampering with NPI, and protect against malicious code. Class A companies shall also run endpoint detection and response and centralized logging and alerting, unless the CISO approves compensating controls. Applies to: (a)(1) and (a)(2): not the 500.19(a) exemption. (b): Class A companies. |
User activity monitoring, email and web filtering, EDR on all endpoints, a central SIEM. Test: Detection test for lateral movement and a malicious attachment. |
EDR and SIEM coverage reports; detection test results. | Ongoing |
Third-party service providers
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-24 500.11 |
Shall have written policies on third-party service providers: identification and risk assessment, minimum cybersecurity practices, due diligence and periodic assessment, with guidelines on access controls and MFA, encryption, incident notice, and representations and warranties. Applies to: All covered entities |
One vendor program serving DORA and Part 500: register, security due diligence and contract clauses. Test: Sample providers with NPI access for due diligence and contract terms. |
Provider register; due diligence files; contract clause checklist. | Periodic assessment based on risk |
Incident response and business continuity
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-25 500.16(a)(1) |
Shall have a written incident response plan covering goals, internal processes, roles and decision authority, communications, remediation, documentation, recovery from backups, root cause analysis and plan updates, including for ransomware. Applies to: Covered entities without the 500.19(a) exemption Note: The playbooks are Guardian suggestions. |
Incident response plan with crypto playbooks: key compromise, hot wallet drain, front end or DNS hijack. Test: Yearly tabletop with management (500.16(d)). |
Incident response plan; playbooks; tabletop report. | Tested at least annually |
| NYDFS-26 500.16(a)(2), (b), (c), (e) |
Shall have a BCDR plan identifying essential data, systems, people and third parties, with communication and recovery procedures; make it accessible and train the staff who run it; and keep backups protected from unauthorized alteration or destruction. Applies to: Covered entities without the 500.19(a) exemption |
BCDR plan shared with the DORA continuity program; immutable backups. Test: Check backup immutability; confirm staff can reach the plan during an outage. |
BCDR plan; distribution and training records; backup settings. | Ongoing |
| NYDFS-27 500.16(d) |
Shall test, at least annually, the incident response and BCDR plans with all critical staff and management, and the ability to restore critical data and systems from backups. Applies to: Covered entities without the 500.19(a) exemption |
Yearly exercise and restore test, shared with DORA-23 and DORA-24. Test: Run the exercise; restore critical systems from backup and time it. |
Exercise report; restore test record; plan revisions. | At least annually |
| NYDFS-28 200.17 |
BitLicensees shall keep a written BCDR plan, distribute it and train staff on it, promptly notify the superintendent of any disruption that may affect regulatory obligations or significantly harm the licensee, counterparties or the market, and have the plan tested at least annually by qualified, independent personnel or a qualified third party. Applies to: BitLicense holders |
Independent tester for the yearly BCDR test; disruption notice procedure. Test: Confirm the tester's independence and qualifications. |
Independent BCDR test report; disruption notices sent. | Tested at least annually; notice promptly |
Notices and the annual certification
| Row and article | Requirement and scope | Suggested control and test | Evidence to keep | Frequency or deadline |
|---|---|---|---|---|
| NYDFS-29 500.17(a); 500.1(g) |
Shall notify the superintendent as promptly as possible, and no later than 72 hours after determining that a cybersecurity incident occurred at the entity, an affiliate or a third-party service provider, then supply requested information and updates. Applies to: All covered entities Note: 500.1(g) defines a cybersecurity incident, including events that require notice to another regulator, are reasonably likely to cause material harm, or deploy ransomware in a material part of systems. |
A determination step in the incident runbook that starts the 72-hour clock, run alongside the DORA clocks. Test: Dry run from detection to a drafted DFS notice. |
Notices filed through the DFS portal, with timestamps; determination record. | Within 72 hours of determining an incident |
| NYDFS-30 500.17(c) |
After an extortion payment connected to a cybersecurity event, shall notify the superintendent within 24 hours, and within 30 days explain why payment was necessary, the alternatives and diligence considered, and the sanctions compliance checks made. Applies to: All covered entities |
Extortion decision procedure with OFAC screening and a 24-hour notice step. Test: Tabletop a ransom demand through to the notice. |
24-hour notice and 30-day report; OFAC diligence record. | 24 hours and 30 days after any payment |
| NYDFS-31 500.17(b) |
By April 15 each year, shall submit either a certification of material compliance for the prior calendar year or an acknowledgment of noncompliance listing the sections and a remediation timeline, signed by the highest-ranking executive and the CISO, and keep the supporting records for five years. Applies to: All covered entities Note: In 2022 DFS found that Robinhood Crypto's 2019 certifications "should not have been made". |
Evidence binder built from this workbook through the year; certification review in March. Test: Mock certification: check each section's evidence covers the full calendar year. |
Filed certification or acknowledgment; supporting evidence kept five years. | Annually by April 15 |
One control, several rules · 15 rows
Cross-reference
Where one control and one evidence pack can satisfy rows in more than one regulation. Scope it to the strictest rule and you build it once.
Shared controls (Guardian suggestions)
| Shared control | Rows it satisfies | Strictest requirement to design for | One evidence pack |
|---|---|---|---|
| XR-01 One yearly pentest program, scoped once for every rule |
DORA-33, NYDFS-12, NYDFS-14, MICA-03 | Yearly. Cover all systems supporting critical or important functions (DORA), all electronic systems (Part 200), inside and outside the boundaries (500.5), in black, gray and white box (RTS 2025/305). Note: Run by an independent party to meet DORA Art. 24(4) and the "qualified" party in 500.5. |
One report set a year with a scope matrix mapping each system to the rows it serves, plus retest results. |
| XR-02 Weekly automated scanning of critical assets |
DORA-15, NYDFS-13, NYDFS-14, MICA-03 | Weekly on assets supporting critical or important functions (RTS 2024/1774 Art. 10), which also covers Part 200's quarterly assessment, plus a scan after each material change (500.5). | Scanner schedule, weekly reports, change-linked scans and a remediation tracker. |
| XR-03 Independent review of code and smart contracts before release |
DORA-18, DORA-33, MICA-04, MICA-20, NYDFS-15 | Before each deployment (RTS 2024/1774 Art. 16), with the CISO reviewing the procedures yearly (500.8). | Audit and code review reports at the release commit, fix reviews and the CISO's sign-off. |
| XR-04 Access recertification |
DORA-12, NYDFS-16, NYDFS-17 | Every 6 months on systems supporting critical or important functions (RTS 2024/1774 Art. 21), yearly elsewhere (both texts). | Signed review records with removals, plus privileged access logs for Class A companies. |
| XR-05 MFA for every user, phishing-resistant for admins and signers |
DORA-11, NYDFS-18, MICA-14 | Every individual on every information system (500.12, since November 1, 2025). Note: MiCA asks custody agreements to describe the client's authentication system. |
Identity provider MFA coverage report and any written compensating control approvals. |
| XR-06 One asset inventory |
DORA-09, NYDFS-20, MICA-02 | DORA's field list (RTS 2024/1774 Art. 4) covers 500.13(a)'s, adding unique ID, functions supported, RPO, internet exposure and dependencies. | Inventory export with the combined field set and validation records. |
| XR-07 One incident runbook with parallel clocks |
DORA-27, DORA-28, DORA-29, NYDFS-28, NYDFS-29, NYDFS-30 | DORA: 4 hours after classification and 24 hours after awareness. DFS: 72 hours after determination; 24 hours after any extortion payment. Part 200: prompt notice of disruptions. Note: Each clock starts at a different event; record all of them. |
Timestamped classification, determination and every notice filed. |
| XR-08 One yearly resilience exercise run by an independent party |
DORA-23, DORA-24, NYDFS-27, NYDFS-28, MICA-05, MICA-07 | Yearly, by qualified independent personnel or a third party (200.17(e)), with cyber-attack and switchover scenarios (DORA) and a restore from backups (500.16(d)). | Exercise report, restore test record, and deficiencies reported to the management body. |
| XR-09 One vendor register and due diligence file |
DORA-38, DORA-39, DORA-40, NYDFS-24, MICA-11, MICA-16 | DORA's register in the ITS 2024/2956 templates, reported at least yearly, with 500.11's security guidelines in the due diligence. | Register of information, due diligence files and contract clause checklists. |
| XR-10 Key management and custody controls |
DORA-14, MICA-06, MICA-10, MICA-12, MICA-21 | Whole-lifecycle key management with tested replacement (RTS 2024/1774 Art. 7) inside a custody policy that minimizes the risk of loss (MiCA Art. 75(3)). | Custody policy, signer inventory, ceremony logs and key replacement and recovery tests. |
| XR-11 Tamper-protected logs and audit trails |
DORA-21, NYDFS-21, NYDFS-22, MICA-09 | All financial transactions (Part 200), kept at least seven years for BitLicensees (200.12) and at least five years elsewhere (MiCA Art. 68(9), 500.6), with tamper protection (RTS 2024/1774 Art. 12). | Retention and immutability settings, plus a reconstruction test. |
| XR-12 One yearly CISO report to the board |
DORA-04, DORA-05, NYDFS-08, NYDFS-09, MICA-08 | Yearly, with a copy to DFS for BitLicensees (200.16(d)); DORA adds the framework review report (Art. 6(5)). | CISO report, board minutes and the DORA review report. |
| XR-13 One training program |
DORA-08, NYDFS-11 | At least annual awareness training with social engineering for all personnel (500.14(a)(3)), compulsory for staff and senior management (DORA Art. 13(6)). | Training records and phishing simulation results. |
| XR-14 One risk assessment |
DORA-10, NYDFS-10 | At least yearly and on each major or material change (both texts). | Risk assessment report, methodology and risk acceptance records. |
| XR-15 One encryption standard |
DORA-13, NYDFS-19 | Data at rest and in transit, with data in use where necessary and internal traffic (RTS 2024/1774 Art. 6). | Encryption policy, TLS scans and CISO-approved exceptions. |
Where Guardian fits
Tests Guardian runs against these rows
Guardian provides technical security assessments and evidence. Your legal and compliance advisers determine licensing and legal interpretation.
- Yearly testing (DORA-33, NYDFS-12, NYDFS-14, MICA-03). Guardian's application and infrastructure pentests cover web apps, APIs, cloud and internal networks, in black, gray or white box as the scope requires. Each report includes retest results.
- Code review (DORA-18, MICA-04, MICA-20, NYDFS-15). Guardian's smart contract audit puts two independent teams on one scope: Team A's manual review with the fuzzing suite, and Team B running Helix. Only human-verified findings reach the report, and the invariant suite stays with you.
- Custody and keys (DORA-14, MICA-06, MICA-12). Guardian's custody and key management review covers key generation, storage, signing permissions, transaction approval, backups and recovery. You receive a wallet and signer inventory and tested recovery procedures.
- Continuity exercises (DORA-23, NYDFS-27, NYDFS-28). Guardian runs incident tabletops and recovery exercises and reviews critical cloud, custody, RPC and other third-party dependencies.
- Detection (DORA-20, NYDFS-23). Managed Security monitors contracts on every block for privileged calls, role and ownership changes, upgrades, multisig transactions and large fund movements. When something fires, a Guardian engineer responds.
Primary texts
Sources
Every row links to its article. These are the texts the mapping was read from on November 10, 2026.
- EUR-Lex: Regulation (EU) 2022/2554, Digital Operational Resilience Act (DORA) (December 27, 2022)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1774, RTS on the ICT risk management framework and the simplified ICT risk management framework (June 25, 2024)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1772, RTS on classification of ICT-related incidents and cyber threats (June 25, 2024)
- EUR-Lex: Commission Delegated Regulation (EU) 2025/301, RTS on the content and time limits of major ICT-related incident reports (February 20, 2025)
- EUR-Lex: Commission Implementing Regulation (EU) 2024/2956, ITS on the standard templates for the register of information (December 2, 2024)
- EUR-Lex: Commission Delegated Regulation (EU) 2024/1773, RTS on the policy for ICT services supporting critical or important functions (June 25, 2024)
- EUR-Lex: Commission Delegated Regulation (EU) 2025/1190, RTS on threat-led penetration testing (TLPT) (June 18, 2025)
- EUR-Lex: Regulation (EU) 2023/1114, Markets in Crypto-Assets (MiCA) (June 9, 2023)
- EUR-Lex: Commission Delegated Regulation (EU) 2025/305, RTS on the information in an application for authorisation as a crypto-asset service provider (March 31, 2025)
- EUR-Lex: Commission Delegated Regulation (EU) 2025/1140, RTS on records to be kept of all crypto-asset services, activities, orders and transactions (June 10, 2025)
- ESMA: ESMA, Statement on the End of Transitional Periods under MiCA (ESMA75-113276571-1679) (April 17, 2026)
- New York State Department of Financial Services: 23 NYCRR Part 500, Cybersecurity Requirements for Financial Services Companies, as amended by the Second Amendment (effective November 1, 2023)
- Cornell Legal Information Institute: 23 NYCRR Part 200 (Virtual Currencies), sections 200.12, 200.16 and 200.17 (effective June 24, 2015)
- New York State Department of Financial Services: DFS Industry Letter: Guidance on How to Conduct and Use Risk Assessments Required by the DFS Cybersecurity Regulation (September 10, 2026)
- New York State Department of Financial Services: DFS Announces $30 Million Penalty on Robinhood Crypto (August 2, 2022)
- Cornell Legal Information Institute: N.Y. Comp. Codes R. & Regs. Tit. 23, Part 500 and sections 200.12, 200.16 and 200.17 (read November 10, 2026)
No rows match that filter.
Turn the workbook into evidence
Guardian tests the systems behind these rows and organizes findings, retests and documentation against the requirements in scope.