EU Digital Operational Resilience Act (2022/2554) — SP 800-53 Coverage
How well do NIST SP 800-53 Rev 5 controls address each EU DORA requirement? This analysis maps from framework clauses back to SP 800-53, with expert coverage weightings and gap identification.
Clause-by-Clause Analysis
Sorted by clauseArt.5(1) Governance and organisation — management body responsibility
Rationale
AC-01, CA-01, PL-01 establish policies and planning. PM-01 program plan and PM-02 senior information security role provide governance structure. PL-09 (new in Rev 5) central management enables unified governance of security controls across the organisation, partially addressing management body oversight. However, SP 800-53 addresses organisational policy structures rather than board-level governance accountability.
Gaps
DORA requires the management body to define, approve, oversee, and be ultimately responsible for ICT risk management. SP 800-53 establishes policy ownership but lacks specific board/management body accountability, personal liability, and fiduciary duty requirements of DORA Art. 5. PL-09 improves central governance but does not create board-level accountability.
Art.5(2) Governance and organisation — management body approval of digital operational resilience strategy
Rationale
CA-06 provides security authorisation. PL-09 (new in Rev 5) central management establishes organisational oversight of security controls that could support a resilience strategy, but does not mandate a specific digital operational resilience strategy requiring board approval.
Gaps
DORA mandates explicit board approval of a digital operational resilience strategy. SP 800-53 has no equivalent concept of a board-approved resilience strategy document. The authorisation concept in CA-06 is system-level, not enterprise resilience-level. PL-09 improves central management but does not create the specific resilience strategy artifact DORA requires.
Art.5(4) Governance and organisation — ICT risk management training for management body
Rationale
AT-01 through AT-03 provide security awareness and training. AT-06 (new in Rev 5) training feedback measures training effectiveness, supporting DORA's requirement to maintain competence. PS-09 (new in Rev 5) position descriptions incorporates security responsibilities into role definitions, which supports linking training to management body roles. PS-01 through PS-08 cover personnel security. PL-04 rules of behaviour.
Gaps
DORA requires management body members to maintain sufficient knowledge and skills to understand and assess ICT risk, including regular specific training. SP 800-53 training controls are aimed at general personnel, not specifically at board-level competence requirements. AT-06 and PS-09 improve training measurement and role-based accountability but do not mandate board-level ICT risk training.
Art.6(1) ICT risk management framework — establishment and maintenance
Rationale
AC-01, CA-01, CA-06, PL-01, PL-02, PL-06, RA-01, SA-02 provide comprehensive policy, planning, risk assessment, and authorisation frameworks. PL-09 (new in Rev 5) central management enables unified framework governance. PL-10 (new in Rev 5) baseline selection and PL-11 (new in Rev 5) baseline tailoring provide systematic framework establishment aligned with risk. RA-07 (new in Rev 5) risk response adds explicit risk treatment actions to the framework lifecycle.
Gaps
DORA requires an ICT risk management framework that is documented, reviewed annually, and improved based on lessons learned and audit findings. SP 800-53 covers most elements. PL-09/10/11 and RA-07 strengthen the framework lifecycle. Minor gap: DORA requires the specific annual review cycle and explicit link to digital operational resilience strategy.
Art.6(2) ICT risk management framework — risk assessment and documentation
Rationale
PL-02, PL-05, PT-06, RA-01, RA-03 address system security plans, privacy impact assessments, and risk assessments comprehensively. RA-07 (new in Rev 5) risk response provides explicit risk treatment decision documentation. RA-09 (new in Rev 5) criticality analysis identifies critical components and functions, directly supporting DORA's requirement to assess risk to critical business functions.
Gaps
Minor gap: DORA requires ICT risk management to support the digital operational resilience strategy with continuous evolution. SP 800-53 risk assessment is strong and RA-07/RA-09 improve risk response and criticality identification, but the explicit link to operational resilience strategy is not present.
Art.6(4) ICT risk management framework — review and audit
Rationale
CA-05 plan of action and milestones; PL-03 system security plan update; RA-04 risk assessment update. CA-02 security assessments and CA-07 continuous monitoring support ongoing review. CA-09 (new in Rev 5) internal system connections adds authorisation and monitoring of internal connections, supporting framework review completeness.
Gaps
DORA requires periodic audits of the ICT risk management framework by internal auditors or external firms. SP 800-53 provides review mechanisms and CA-09 extends internal monitoring. However, it does not mandate formal internal audit of the risk management framework itself as DORA requires.
Art.6(5) ICT risk management framework — formal reporting to management body
Rationale
AU-01 audit policies; PL-05 privacy assessment; RA-03 and RA-04 risk assessment and update produce reports. RA-07 (new in Rev 5) risk response generates documented risk treatment decisions that could form part of management reporting.
Gaps
DORA mandates formal reporting to the management body on ICT risk at least annually, including ICT risk findings and recommendations. SP 800-53 has no specific requirement for management body reporting on ICT risk. RA-07 improves documentation of risk decisions but does not mandate board-level reporting.
Art.6(8) ICT risk management framework — documentation and review availability
Rationale
AU-01 audit policy documentation; PT-01 PII processing policies provide documentation requirements.
Gaps
DORA requires the ICT risk management framework documentation to be available to competent authorities on request. SP 800-53 does not address regulatory reporting obligations or making frameworks available to financial supervisors.
Art.7(1) ICT systems, protocols and tools — reliability and capacity
Rationale
CM-01, CM-02, CM-06, CM-07 configuration management; MA-01 through MA-06 maintenance; SA-01, SA-03, SA-08 system acquisition and engineering; SI-01 system integrity. MA-07 (new in Rev 5) field maintenance addresses off-site equipment servicing for reliability. SI-13 (new in Rev 5) predictive maintenance enables proactive failure prevention through monitoring component reliability and predicting failures, directly supporting DORA's requirement for system reliability and capacity adequacy.
Gaps
Minor: DORA specifically requires systems to be resilient, have sufficient capacity, and be technologically up to date. SP 800-53 addresses these comprehensively. SI-13 predictive maintenance and MA-07 field maintenance strengthen reliability coverage. Remaining gap is DORA's specific language around technological currency and capacity adequacy for financial services.
Art.7(2) ICT systems, protocols and tools — keep systems up to date 85%
Rationale
SI-02 flaw remediation directly addresses keeping systems current through patching and updates.
Gaps
Minimal gap. DORA's requirement to keep ICT systems up to date is well covered by SI-02 flaw remediation.
Mapped Controls
Art.8(1) Identification — ICT asset identification and classification
Rationale
AC-15, AC-16 automated marking and labelling; CM-08 component inventory; MP-03 media labelling; RA-02 security categorisation; SA-05 documentation; SI-12 information handling. CM-12 (new in Rev 5) information location identifies where sensitive data resides, directly supporting DORA's asset-to-function mapping. CM-13 (new in Rev 5) data action mapping documents data processing flows across assets, strengthening the link between ICT assets and business functions.
Gaps
Minor: DORA requires identification of all ICT-supported business functions, roles, and information/ICT assets. SP 800-53 now provides strong asset inventory, classification, and data location tracking. CM-12/CM-13 close the previous gap on business function mapping. Remaining minor gap: DORA's explicit requirement to map all ICT-supported business functions is broader than data-centric mapping.
Art.8(4) Identification — ICT asset register and classification
Rationale
AC-16 automated labelling; CM-08 component inventory; RA-02 security categorisation; SA-05 documentation. CM-12 (new in Rev 5) information location tracks where data resides supporting asset register accuracy. RA-09 (new in Rev 5) criticality analysis identifies critical components and functions, supporting DORA's requirement to distinguish assets supporting critical functions.
Gaps
DORA requires maintaining an up-to-date register of all ICT assets and their classification. CM-08, RA-02, CM-12, and RA-09 cover most of this. RA-09 criticality analysis addresses DORA's specific requirement to identify assets supporting critical or important functions. Minor gap: DORA requires the register format to be reportable to competent authorities.
Art.8(5) Identification — ICT risk assessment on legacy systems
Rationale
SA-03 life cycle support and SA-10 developer configuration management address system lifecycle. SA-22 unsupported system components directly addresses managing components no longer supported by developers, which is central to legacy system risk.
Gaps
DORA specifically requires risk assessment of legacy ICT systems and their interactions with other systems. SA-22 addresses unsupported components but SP 800-53 has no specific legacy system risk assessment requirement. SA-03 addresses lifecycle generally. The specific DORA focus on identifying and managing risks from outdated/legacy ICT systems and documenting their risk profile is not fully addressed.
Art.9(1) Protection and prevention — ICT security policies
Rationale
CM-01, CM-02, CM-06, CM-07 configuration management; MA-01 maintenance; PE-01 through PE-03 physical protection; SA-01, SA-08 system acquisition; SC-01 system protection; SI-01 integrity. Comprehensive protection policy coverage.
Gaps
Minor: DORA requires protection and prevention measures to ensure resilience, continuity, and availability of ICT systems. SP 800-53 covers the technical controls well but does not frame them in the specific context of digital operational resilience for financial entities.
Art.9(2) Protection and prevention — ICT system resilience and availability
Rationale
SC-05 denial of service protection; SC-06 resource priority; SC-14 public access protections address availability and resilience. SC-24 (new in Rev 5) fail in known state ensures systems fail to a secure, defined state preserving operational integrity, directly supporting DORA's resilience requirements. SI-13 (new in Rev 5) predictive maintenance enables proactive availability management through failure prediction.
Gaps
DORA requires specific measures to minimise the impact of ICT risk and ensure availability including performance and capacity management. SC-24 and SI-13 significantly improve resilience coverage. Remaining gap: DORA's specific requirements for financial entity ICT availability targets and performance metrics.
Art.9(3) Protection and prevention — data integrity, confidentiality, and availability safeguards
Rationale
IA-05, IA-07 authenticator and cryptographic module management; RA-05 vulnerability scanning; SC-08 transmission integrity; SC-12 through SC-17 cryptographic protections and PKI; SC-23 session authenticity; SC-28 protection of information at rest. Comprehensive cryptographic and data protection coverage.
Gaps
Minimal gap. SP 800-53 provides comprehensive data protection controls that align well with DORA's requirements for data integrity, confidentiality, and availability.
Art.9(4)(a) Protection and prevention — network security management
Rationale
AC-04 information flow; AC-17 through AC-19 remote, wireless, and mobile access; CA-03 system connections; MA-04 remote maintenance; MP-01, MP-04, MP-05 media protection; SC-01 through SC-03 system protection and isolation; SC-07 boundary protection; SC-08 transmission integrity; SC-15, SC-20 through SC-22 collaborative computing and DNS protections. SC-46 (new in Rev 5) cross-domain policy enforcement strengthens network boundary controls. SC-47 (new in Rev 5) alternate communications safeguards provides resilient communication paths for network management.
Gaps
Minimal gap. SP 800-53 provides comprehensive network security controls. SC-46/SC-47 improve cross-domain and resilient communications coverage. DORA's network security management requirements are well addressed.
Art.9(4)(b) Protection and prevention — data leakage, malware, and media protection
Rationale
MP-01, MP-02, MP-04 through MP-06 media protection; SC-04 information remnance; SI-03 malicious code protection; SI-07 software integrity; SI-08 spam protection. MP-08 (new in Rev 5) media downgrading adds controlled procedures for declassifying media, preventing data leakage through media reuse.
Gaps
Minimal gap. SP 800-53 comprehensively covers malware protection and data leakage prevention. MP-08 adds media downgrading controls.
Art.9(4)(c) Protection and prevention — access control and authentication
Rationale
AC-01 through AC-12, AC-14, AC-17, AC-19 comprehensive access control; CM-05 change access restrictions; IA-01 through IA-06 identification and authentication; MA-04 remote maintenance; PS-04, PS-05 personnel termination and transfer; SC-10 network disconnect. Extremely comprehensive access control and authentication coverage.
Gaps
Negligible. SP 800-53 access control and identification families provide thorough coverage of DORA's access control and authentication requirements.
Art.9(4)(d) Protection and prevention — strong authentication and identity management
Rationale
AC-02 account management; AC-05, AC-06 separation of duties and least privilege; IA-01 through IA-05 identification and authentication policies, user/device authentication, identifier and authenticator management. IA-08 identification and authentication of non-organisational users and IA-12 identity proofing strengthen coverage for external user authentication and identity verification.
Gaps
Minor: DORA emphasises strong authentication mechanisms and robust identity management. SP 800-53 IA family provides strong coverage including external user identity proofing. Minor gap: DORA's specific requirements for financial entity authentication standards may require supplementary financial sector guidance.
Art.9(4)(e) Protection and prevention — change management and software security
Rationale
CM-03 through CM-05 change control and access restrictions; MA-03 maintenance tools; SA-06, SA-07 software usage restrictions; SA-10 developer configuration management; SC-18 mobile code; SI-02 flaw remediation; SI-07 software integrity; SI-10, SI-11 input validation and error handling. CM-14 (new in Rev 5) signed components verifies integrity of software/firmware changes through cryptographic signatures, directly supporting DORA's change management and software security requirements.
Gaps
Minor: DORA requires robust ICT change management including testing in separate environments. SP 800-53 change management is comprehensive and CM-14 adds cryptographic change integrity. Remaining gap: DORA specifically mandates separation of test and production environments.
Art.10(1) Detection — anomalous activities and ICT-related incidents
Rationale
AC-09 previous logon notification; AU-02 through AU-12 comprehensive audit and accountability; CA-07 continuous monitoring; SI-04 information system monitoring; SI-05 security alerts; SI-06 security functionality verification. SI-16 (new in Rev 5) memory protection prevents exploitation of memory corruption vulnerabilities that could mask anomalous activity. SI-20 (new in Rev 5) tainting tracks data provenance through system execution, supporting detection of anomalous data flows.
Gaps
Minor: DORA requires detection of anomalous activities specifically in the context of ICT-related incidents and digital operational resilience. SP 800-53 audit and monitoring controls are comprehensive. SI-16 and SI-20 add depth to detection. DORA's specific financial services framing is the only remaining gap.
Art.10(2) Detection — multiple layers of control and alert thresholds
Rationale
AU-02 auditable events; AU-05 response to audit failures; AU-06 audit monitoring and analysis; CA-07 continuous monitoring; SI-04 system monitoring; SI-06 security functionality verification.
Gaps
Minor: DORA requires multiple layers of control including defined alert thresholds and criteria to trigger detection and response. SP 800-53 provides layered monitoring but does not prescribe DORA's specific multi-layer approach with defined thresholds.
Art.11(1) Response and recovery — ICT business continuity policy
Rationale
CP-01 contingency planning policy; CP-02 contingency plan; CP-10 system recovery. CP-12 safe mode enables degraded operation maintaining essential functions. CP-13 alternative security mechanisms provides fallback controls during disruption. Both support DORA's continuity and resilience requirements.
Gaps
DORA requires a comprehensive ICT business continuity policy as part of the overall business continuity policy. SP 800-53 CP family addresses IT contingency well. CP-12/CP-13 improve resilient operations. Remaining gap: DORA requires explicit integration with broader business continuity and operational resilience at the financial entity level.
Art.11(2) Response and recovery — recovery time and point objectives
Rationale
CP-10 system recovery addresses recovery and reconstitution. RA-09 (new in Rev 5) criticality analysis identifies critical system components and functions, supporting prioritised recovery objective definition for critical functions.
Gaps
DORA requires entities to set specific recovery time objectives (RTOs) and recovery point objectives (RPOs) for each critical function. CP-10 addresses recovery generally and RA-09 helps identify what is critical. However, SP 800-53 does not mandate specific RTO/RPO definition for each function as DORA does.
Art.11(3) Response and recovery — impact analysis of ICT disruption scenarios
Rationale
CP-01, CP-02 contingency policy and planning; CP-07 alternate processing site; CP-08 telecommunications services address disruption scenarios. RA-09 (new in Rev 5) criticality analysis supports impact analysis by identifying components critical to mission/business functions.
Gaps
DORA requires business impact analysis (BIA) specifically assessing the impact of severe ICT disruption scenarios. SP 800-53 CP-02 includes BIA concepts and RA-09 improves criticality assessment. Gap: DORA specifically requires scenario-based impact analysis for severe ICT disruptions in financial services context.
Art.11(4) Response and recovery — ICT response and recovery plans
Rationale
CP-02 contingency plan and CP-10 system recovery and reconstitution directly address response and recovery planning. SC-24 (new in Rev 5) fail in known state ensures systems fail to a secure, defined state, supporting recovery plan predictability and reducing recovery complexity.
Gaps
Minor: DORA requires dedicated ICT response and recovery plans including for scenarios of severe operational disruption. SP 800-53 contingency planning covers this well and SC-24 improves fail-safe behaviour. Remaining gap: DORA requires these plans to be specifically tested for ICT scenarios in financial services.
Art.11(6) Response and recovery — testing of ICT business continuity plans
Rationale
CP-03 contingency training; CP-04 contingency plan testing; CP-05 contingency plan update. Comprehensive testing and maintenance of continuity plans.
Gaps
Minor: DORA requires testing of ICT business continuity plans at least annually and after substantive changes. SP 800-53 CP-04 addresses testing but does not mandate the specific annual minimum or post-change testing frequency.
Art.11(7) Response and recovery — crisis communication plans
Rationale
CP-04 contingency plan testing provides a testing framework. IR-06 incident reporting and IR-07 incident response assistance provide communication mechanisms during incidents.
Gaps
DORA requires financial entities to have crisis communication plans covering responsible staff disclosure, communication with clients, and internal escalation. SP 800-53 IR-06/IR-07 cover incident reporting and assistance but do not address DORA's specific crisis communication plan requirements including client notification, media handling, and designated communication staff.
Art.12(1) Backup policies and recovery — backup policy development
Rationale
CP-01 contingency planning policy; CP-02 contingency plan; CP-09 system backup. Comprehensive backup policy coverage.
Gaps
Minor: DORA requires the backup policy to specify the scope of data subject to backup and the minimum frequency. SP 800-53 CP-09 covers backup comprehensively but DORA requires specific scope and frequency documentation.
Art.12(2) Backup policies and recovery — restoration and recovery from backups
Rationale
CP-06 alternate storage; CP-07 alternate processing; CP-08 telecommunications; CP-09 system backup. SC-24 (new in Rev 5) fail in known state supports predictable recovery from backup by ensuring systems reach a defined state before restoration begins.
Gaps
Minor: DORA requires testing backup restoration at least annually. CP-09 addresses backup and SC-24 improves fail-safe recovery. The specific annual restoration testing requirement is a DORA-specific mandate.
Art.12(3) Backup policies and recovery — backup data integrity and confidentiality
Rationale
CP-09 system backup with integrity protections; SI-12 information output handling and retention.
Gaps
Minor: DORA specifically requires integrity, confidentiality, and recoverability of backed-up data. SP 800-53 CP-09 addresses backup protection but DORA specifically requires verification of backup data integrity.
Art.12(5) Backup policies and recovery — geographically separated backup site
Rationale
CP-06 alternate storage site; CP-07 alternate processing site; CP-09 system backup. CP-06 and CP-07 address geographic separation of storage and processing sites.
Gaps
DORA requires secondary processing sites with a geographic distance ensuring immediate takeover. CP-06 and CP-07 address alternate sites but DORA's specific requirement for geographic distance based on risk profile of the financial entity and immediate takeover capability is more prescriptive.
Art.13(1) Learning and evolving — gathering information on vulnerabilities and cyber threats
Rationale
SI-05 security alerts and advisories provides threat intelligence. PM-16 threat awareness program. RA-05 vulnerability scanning. SI-21 (new in Rev 5) information refresh ensures information used for threat analysis is current and refreshed at appropriate intervals, supporting DORA's continuous learning requirement.
Gaps
DORA requires financial entities to gather information on vulnerabilities, cyber threats, and ICT-related incidents from multiple sources and integrate lessons learned. SI-05, PM-16, and SI-21 improve coverage. Gap: DORA requires systematic multi-source threat intelligence gathering and integration more comprehensively than SP 800-53.
Art.13(6) Learning and evolving — ICT security awareness and training programmes
Rationale
AT-01 through AT-05 security awareness and training; CP-03 contingency training; IR-02 incident response training. AT-06 (new in Rev 5) training feedback measures training effectiveness and captures lessons learned, supporting DORA's requirement for ongoing competence development.
Gaps
Minor: DORA requires compulsory ICT security awareness programmes and digital operational resilience training for all staff. SP 800-53 training controls are comprehensive. AT-06 improves training effectiveness measurement. Remaining gap: DORA specifically mandates training tailored to the entity's ICT risk profile including digital operational resilience concepts.
Art.14 Communication — policies for internal and external communication on ICT-related incidents
Rationale
IR-06 incident reporting and IR-07 incident response assistance provide general reporting and assistance frameworks but do not address DORA's specific communication requirements.
Gaps
DORA Art. 14 requires policies for communicating ICT-related incidents to clients, counterparts, and the public, including responsible communication staff and media handling. SP 800-53 does not address external stakeholder communication policies for ICT incidents. IR-06/IR-07 cover internal reporting but not DORA's client and public communication requirements.
Art.15 Simplified ICT risk management framework — proportionality for smaller entities 0%
Rationale
No SP 800-53 controls address proportionality or simplified frameworks for smaller entities.
Gaps
DORA Art. 15 provides a simplified ICT risk management framework for certain smaller financial entities (e.g., small investment firms, payment institutions). SP 800-53 has no concept of entity-size-based proportionality. The low/moderate/high baseline approach is system-based, not entity-based.
Art.16 Further harmonisation of ICT risk management tools, methods, processes, and policies 0%
Rationale
No SP 800-53 controls address EU regulatory harmonisation mandates.
Gaps
DORA Art. 16 empowers ESAs to develop regulatory technical standards for further harmonisation of ICT risk management. This is a regulatory harmonisation provision with no SP 800-53 equivalent.
Art.17(1) ICT-related incident management process — establishment
Rationale
IR-01 incident response policy; IR-04 incident handling; IR-08 incident response plan. IR-09 (new in Rev 5) information spillage response adds specific handling for data breach/spillage incidents, a critical incident category for financial entities under DORA.
Gaps
Minor: DORA requires an ICT-related incident management process that includes early warning indicators, procedures to identify, track, log, categorise, and report incidents. SP 800-53 IR family covers incident handling well. IR-09 adds spillage-specific response. Remaining gap: DORA requires specific integration with regulatory reporting and early warning.
Art.17(2) ICT-related incident management process — indicators and procedures
Rationale
IR-01 incident response policy and procedures; IR-03 incident response testing. IR-09 (new in Rev 5) information spillage response adds specific detection indicators and procedures for data spillage incidents.
Gaps
DORA requires early warning indicators and procedures to identify and respond to ICT-related incidents. SP 800-53 provides policy and testing frameworks. IR-09 adds spillage indicators. DORA's specific early warning indicator requirements for all incident types remain more prescriptive.
Art.17(3) ICT-related incident management process — response procedures
Rationale
IR-01 incident response policy; IR-04 incident handling directly address response procedures. IR-09 (new in Rev 5) information spillage response adds specific response procedures for data breach scenarios.
Gaps
Minor: DORA requires procedures including containment, appropriate response, communication, and reporting. SP 800-53 IR-04 is comprehensive for incident handling and IR-09 adds data breach response. Minor gap: DORA's communication and regulatory reporting procedures during response.
Art.17(3)(c) ICT-related incident management process — incident monitoring 85%
Rationale
IR-05 incident monitoring directly addresses continuous monitoring of ICT-related incidents.
Gaps
Minimal gap. SP 800-53 IR-05 provides good coverage of incident monitoring as required by DORA.
Mapped Controls
Art.17(3)(d) ICT-related incident management process — training and communication
Rationale
IR-02 incident response training; IR-07 incident response assistance.
Gaps
Minor: DORA requires staff training on incident detection and response plus communication protocols. SP 800-53 covers training and assistance but DORA requires specific communication procedures to clients and counterparts during incidents.
Art.18(1) Classification of ICT-related incidents — classification criteria
Rationale
IR-04 incident handling; IR-05 incident monitoring provide frameworks for incident handling.
Gaps
DORA requires classification of ICT-related incidents based on specific criteria including number of clients affected, duration, geographic spread, data losses, criticality of services affected, and economic impact. SP 800-53 does not prescribe these specific classification criteria.
Art.18(2) Classification of ICT-related incidents — major incident determination 60%
Rationale
IR-04 incident handling provides incident categorisation capability.
Gaps
DORA requires specific criteria for determining when an ICT-related incident is 'major' with mandatory reporting. SP 800-53 does not define 'major incident' thresholds or link incident classification to regulatory reporting obligations.
Mapped Controls
Art.19(1) Reporting of major ICT-related incidents — notification to competent authority
Rationale
IR-06 incident reporting; SR-08 notification agreements. These provide general incident reporting frameworks.
Gaps
DORA requires specific reporting to competent financial authorities using prescribed forms and timelines (initial notification, intermediate report, final report). SP 800-53 IR-06 covers reporting but not DORA's specific financial regulatory reporting timelines, formats, and authorities.
Art.19(4) Reporting of major ICT-related incidents — incident report content and timelines
Rationale
AU-11 audit record retention; IR-06 incident reporting. Basic reporting capabilities exist.
Gaps
DORA mandates specific reporting timelines (initial notification within 4 hours, intermediate report within 72 hours, final report within one month) and specific content requirements. SP 800-53 does not prescribe EU financial regulatory reporting timelines or content formats.
Art.20(1) Harmonisation of reporting content and templates 35%
Rationale
IR-06 incident reporting provides a general reporting framework.
Gaps
DORA Art. 20 requires harmonised reporting templates and procedures defined by ESAs. SP 800-53 has no concept of standardised EU regulatory incident report templates. This is fundamentally a regulatory harmonisation requirement outside SP 800-53 scope.
Mapped Controls
Art.22(1) Supervisory feedback on incident reports 30%
Rationale
IR-07 incident response assistance provides some feedback mechanism.
Gaps
DORA Art. 22 requires competent authorities to provide feedback and guidance on reported incidents. SP 800-53 does not address the regulatory feedback loop between supervised entities and financial authorities. This is a regulatory relationship requirement.
Mapped Controls
Art.24(1) Digital operational resilience testing — programme establishment
Rationale
CA-01 assessment policy; CA-02 security assessments; CA-04 security certification; CA-07 continuous monitoring; IR-03 incident response testing. CA-08 penetration testing provides a testing foundation for resilience testing programmes.
Gaps
DORA requires a comprehensive digital operational resilience testing programme with specific scope and frequency requirements. SP 800-53 provides assessment and testing controls including penetration testing via CA-08. Remaining gap: DORA frames these as a unified operational resilience testing programme rather than separate assessment activities.
Art.24(2) Digital operational resilience testing — proportionality and risk-based approach
Rationale
CA-02 security assessments provide risk-based assessment capability. PL-10 (new in Rev 5) baseline selection and PL-11 (new in Rev 5) baseline tailoring provide systematic risk-based control selection that could inform proportionate testing.
Gaps
DORA's proportionality principle allows smaller entities a simplified testing regime while requiring comprehensive testing for significant entities. SP 800-53 applies uniformly based on system categorisation (low/moderate/high). PL-10/PL-11 improve risk-based tailoring but have no concept of proportionality based on entity size, risk profile, or systemic importance.
Art.25(1) Testing of ICT tools and systems — scope and methods
Rationale
CA-02 security assessments; CA-04 security certification; CM-04 monitoring configuration changes; RA-05 vulnerability scanning; SA-11 developer security testing. CA-08 penetration testing. RA-06 (new in Rev 5) technical surveillance countermeasures addresses one specialised testing methodology relevant to DORA's comprehensive testing requirements.
Gaps
DORA requires testing to include vulnerability assessments, open-source analyses, network security assessments, gap analyses, physical security reviews, software composition analysis, and source code reviews. SP 800-53 covers many of these. CA-08 adds penetration testing and RA-06 adds surveillance countermeasures. Remaining gap: DORA's specific list of required testing methodologies is more prescriptive.
Art.25(2) Testing of ICT tools and systems — developer testing
Rationale
SA-11 developer security testing directly addresses testing by developers. SA-20 (new in Rev 5) customized development of critical components requires bespoke development and testing for high-assurance components.
Gaps
DORA requires that critical ICT systems and applications are tested before and after deployment, during changes, and regularly. SA-11 covers developer testing and SA-20 adds critical component development/testing. DORA's specific testing lifecycle requirements (pre-deployment, post-deployment, change-driven, periodic) are more prescriptive.
Art.26 Advanced testing — threat-led penetration testing (TLPT)
Rationale
CA-08 penetration testing provides general penetration testing capability. RA-06 (new in Rev 5) technical surveillance countermeasures provides one specialised assessment methodology.
Gaps
DORA Art. 26 mandates threat-led penetration testing (TLPT) based on the TIBER-EU framework for significant financial entities. SP 800-53 CA-08 provides penetration testing but does not require threat intelligence-led testing, red team exercises, or TIBER-EU methodology. RA-06 adds a specialised test type but is not TLPT. This remains a major gap.
Art.27 Requirements for TLPT testers — qualifications and independence 10%
Rationale
No SP 800-53 controls address tester qualification or independence requirements for penetration testing.
Gaps
DORA Art. 27 requires TLPT testers to be certified, have professional indemnity insurance, and be accredited by financial authorities. SP 800-53 has no requirements for tester qualifications, accreditation, or independence. This is entirely outside SP 800-53 scope.
Art.28(1)(a) ICT third-party risk management — general principles and responsibility
Rationale
AC-20 use of external systems; SA-04 acquisitions; SA-09 external services; SR-01 supply chain policy. Good foundation for third-party risk.
Gaps
DORA requires financial entities to remain fully responsible for compliance even when using ICT third-party services. SP 800-53 provides supply chain controls but does not establish the specific non-delegable responsibility for third-party ICT risk as DORA does.
Art.28(2) ICT third-party risk management — proportionate risk management strategy
Rationale
SA-09 external services; SR-01 supply chain policy; SR-03 supply chain controls and processes.
Gaps
DORA requires a proportionate strategy for ICT third-party risk management accounting for the nature, scale, complexity, and importance of ICT dependencies. SP 800-53 provides supply chain controls but does not address DORA's proportionality or the specific focus on ICT dependencies for financial entities.
Art.28(4) ICT third-party risk management — register of ICT third-party arrangements
Rationale
SR-01 supply chain policy; SR-02 supply chain risk management plan. CM-08 component inventory and CM-12 (new in Rev 5) information location help identify where third-party services are used and what data they process.
Gaps
DORA requires a complete register of all contractual arrangements with ICT third-party service providers, distinguishing those supporting critical or important functions. CM-08 and CM-12 improve identification of third-party dependencies but SP 800-53 does not require the specific contractual register DORA mandates.
Art.28(5) ICT third-party risk management — due diligence and risk assessment before contracting
Rationale
AC-20 use of external systems; MA-05 maintenance personnel; PS-07 third-party personnel; SA-09 external services; SR-02 supply chain plan; SR-04 provenance; SR-05 acquisition strategies; SR-07 supply chain operations security; SR-11 component authenticity. SA-21 (new in Rev 5) developer screening adds personnel vetting for development teams at third-party providers.
Gaps
DORA requires specific pre-contractual due diligence including assessing whether contracting would increase concentration risk, whether the provider is established in a third country, and information security considerations. SA-21 improves developer vetting. SP 800-53 supply chain controls are comprehensive but do not address DORA's specific financial sector due diligence criteria.
Art.28(6) ICT third-party risk management — monitoring and audit rights
Rationale
SR-06 supplier assessments and reviews; SR-10 inspection of systems or components.
Gaps
DORA requires contractual audit and access rights over ICT third-party providers, including on-site inspections. SP 800-53 SR-06 and SR-10 cover assessments and inspections but DORA requires specific contractual guarantees of these rights.
Art.28(7) ICT third-party risk management — incident notification by providers 55%
Rationale
SR-08 notification agreements addresses notification requirements between supply chain partners.
Gaps
DORA requires ICT third-party providers to notify the financial entity of ICT security incidents. SP 800-53 SR-08 provides notification agreements but DORA requires specific contractual obligations for incident notification within defined timescales.
Mapped Controls
Art.28(8) ICT third-party risk management — exit strategies 30%
Rationale
SR-12 component disposal addresses component end-of-life.
Gaps
DORA requires financial entities to have exit strategies for ICT third-party arrangements, including transition plans and data migration. SP 800-53 SR-12 covers disposal but not the comprehensive exit strategy, data portability, and transition planning that DORA mandates.
Mapped Controls
Art.29(1) ICT concentration risk — preliminary assessment
Rationale
SR-03 supply chain controls and processes. RA-09 (new in Rev 5) criticality analysis identifies critical components and their supply chain dependencies, partially supporting concentration risk assessment by highlighting where critical functions depend on specific providers.
Gaps
DORA Art. 29 requires specific assessment of ICT concentration risk — whether too many critical functions depend on the same provider or a small number of providers. RA-09 improves criticality identification but SP 800-53 has no specific concept of ICT concentration risk assessment. This is unique to financial regulation.
Art.30(2) Key contractual provisions — minimum requirements for ICT service contracts
Rationale
SA-04 acquisitions; SA-09 external services; SR-03 supply chain controls. General acquisition and contractual controls.
Gaps
DORA Art. 30 mandates specific contractual provisions including service levels, data locations, access rights, security measures, subcontracting conditions, and cooperation with authorities. SP 800-53 SA-04 and SA-09 address acquisitions and external services generally but do not prescribe DORA's specific contractual requirements for financial entities.
Art.30(2)(a) Key contractual provisions — service descriptions and SLAs
Rationale
PS-07 third-party personnel security; SR-04 provenance; SR-05 acquisition strategies; SR-07 supply chain operations security; SR-11 component authenticity.
Gaps
DORA requires detailed contractual service descriptions, quantitative and qualitative SLAs, and binding performance targets. SP 800-53 supply chain controls cover vetting and assessment but do not mandate specific SLA structures or performance metrics in contracts.
Art.30(2)(g) Key contractual provisions — termination and data return 30%
Rationale
SR-12 component disposal addresses end-of-life considerations.
Gaps
DORA requires contractual provisions for termination, including transition periods, data return, secure deletion, and transfer assistance. SP 800-53 SR-12 covers disposal but not the comprehensive termination, data return, and transition provisions DORA mandates.
Mapped Controls
Art.30(3) Key contractual provisions — critical or important functions
Rationale
SA-04 acquisitions; SA-09 external services; SR-06 supplier assessments and reviews. RA-09 (new in Rev 5) criticality analysis supports identifying which functions are critical, informing enhanced contractual provisions.
Gaps
DORA requires enhanced contractual provisions when ICT third-party services support critical or important functions, including full service level descriptions, notice periods, reporting obligations, and exit plans. RA-09 helps identify critical functions but SP 800-53 does not differentiate contractual requirements based on function criticality as DORA does.
Art.45(1) Information-sharing arrangements — voluntary sharing of cyber threat intelligence
Rationale
AT-05 contacts with security groups and associations; PM-15 contacts with security groups and associations; PM-16 threat awareness program. Together these provide information sharing and threat intelligence capabilities.
Gaps
DORA encourages voluntary sharing of cyber threat information among financial entities within trusted communities. SP 800-53 AT-05, PM-15, and PM-16 cover security group contacts and threat awareness but do not address DORA's specific framework for trusted information-sharing arrangements within the financial sector, including safeguards for shared information and legal protections for participants.
Methodology and Disclaimer
This coverage analysis maps from EU DORA clauses/requirements back to NIST SP 800-53 Rev 5 controls, assessing how well the SP 800-53 control set addresses each framework requirement.
Coverage weighting represents an informed estimate based on control-objective alignment, not a definitive compliance determination. Weightings consider whether SP 800-53 controls address the intent of each framework requirement, even where terminology and structure differ.
This analysis should be validated by qualified assessors for use in compliance or audit activities. The authoritative source for any compliance determination is always the framework itself.