Menu
Join my newsletter

2. Robust ICT Risk Management Framework
Including Secure SDLC (Security by Design)
The Digital Operational Resilience Act (DORA) mandates financial entities to implement a comprehensive ICT risk management framework that ensures security, resilience, and operational continuity. This guide provides detailed guidance on building an effective framework that incorporates both risk management principles and security by design.

by Sylvan Ravinet

The StratOps way to accelerate DORA
This guide on Robust ICT Risk Management Framework can help you achieve DORA compliance. Faster. Part of my 12-capabilities cyber framework.
Before continuing, make sure you are subscribed to StratOps!
Get weekly insights in your email
My StratOps newsletter helps cybersecurity experts achieve more, faster.
It's Free! For now.
Have feedback? Connect with me on Linkedin
1. Overview of DORA Requirements for a Robust ICT Risk Management Framework
DORA establishes that financial entities must:
  • Implement a comprehensive and systematic approach to identifying, managing, and mitigating ICT risks across all levels of the organization
  • Incorporate "security by design" principles into the entire lifecycle of ICT systems, processes, and software development
  • Continuously monitor and evaluate risks to ensure timely detection and mitigation of vulnerabilities
Key Objectives:
  • Proactive Risk Management: Identify ICT risks before they materialize
  • Integrated Secure SDLC: Embed security considerations into every phase of system development
  • Ongoing Resilience: Ensure ICT systems remain operational even in the face of attacks or disruptions
2. Key Components of a Robust ICT Risk Management Framework
2.1 Risk Identification and Assessment
Entities must continuously assess ICT risks across all systems, networks, and applications, identifying potential vulnerabilities and threats.
Requirements Include:
  • Regular risk assessments that account for the evolving threat landscape
  • Identification of dependencies on third-party providers (see TP(S)RM Guide)
Practical Steps for Compliance:
  • Use a risk management methodology, such as ISO/IEC 31000 or FAIR (Factor Analysis of Information Risk), to evaluate ICT risks
  • Maintain a dynamic risk register to track vulnerabilities and mitigation actions
  • Perform threat modeling to identify attack vectors against critical systems
2.2 Risk Mitigation and Controls
DORA requires entities to implement risk mitigation measures that align with the principle of proportionality (i.e., based on the criticality of systems and the severity of risks).
Requirements Include:
  • Network segmentation to isolate critical systems
Practical Steps for Compliance:
  • Define a set of technical and organizational controls mapped to specific risks
  • Conduct vulnerability assessments and penetration tests to evaluate system defenses (see Testing Guide)
2.3 Secure Software Development Lifecycle (Secure SDLC)
DORA mandates that security be integrated into every phase of the software development lifecycle (SDLC), aligning with the concept of security by design.
Requirements Include:
  • Secure coding practices and peer code reviews to eliminate vulnerabilities
  • Regular security testing (e.g., static application security testing (SAST) and dynamic application security
  • Ensuring third-party software and components used in development meet security standardstesting (DAST))
Phases of Secure SDLC with Security Practices:
1. Planning Phase:
  • Conduct risk assessments for new software projects
  • Define security requirements alongside functional requirements
  • Use threat modeling tools to identify potential security risks
2. Design Phase:
  • Apply "security by design" principles to architecture decisions
  • Adopt secure design patterns (e.g., input validation, secure APIs)
  • Develop data flow diagrams (DFDs) to evaluate how sensitive data is processed
3. Implementation Phase:
  • Use automated tools for SAST to detect vulnerabilities in source code
  • Enforce secure coding standards (e.g., OWASP Secure Coding Practices)
  • Implement cryptography for data security (e.g., TLS for in-transit data)
4. Testing Phase:
  • Perform DAST to identify runtime vulnerabilities
  • Conduct fuzz testing to uncover unexpected behaviors or crashes
  • Perform manual security testing for critical components
5. Deployment Phase:
  • Secure deployment pipelines using DevSecOps practices
  • Validate that systems are configured securely before going live
  • Ensure system monitoring tools are activated for real-time threat detection
6. Maintenance and Updates:
  • Regularly patch vulnerabilities in software and dependencies
  • Continuously monitor logs for signs of abnormal behavior
  • Conduct periodic security audits to ensure compliance
2.4 Security by Design Principles
DORA emphasizes the integration of security by design principles into ICT systems, ensuring they are resilient by default.
Core Principles of Security by Design:
  • Minimal Privilege: Limit access to the least privilege necessary for operations
  • Default Deny: Block all traffic by default unless explicitly permitted
  • Secure Defaults: Preconfigure systems with the most secure settings
  • Fail-Safe Mechanisms: Ensure systems default to a secure state in case of failure
Practical Steps for Compliance:
  • Apply secure configurations to operating systems and applications using CIS benchmarks
  • Design systems to detect and recover from failures with minimal downtime
  • Perform a formal security review during the design phase of all major projects
2.5 Continuous Monitoring and Logging
To ensure the ongoing resilience of ICT systems, entities must establish mechanisms for continuous monitoring and logging of ICT events.
Requirements Include:
  • Secure storage of logs for analysis and regulatory reporting
  • Use of automated tools to detect vulnerabilities as they arise
Practical Steps for Compliance:
  • Deploy SIEM (Security Information and Event Management) solutions for centralized log management
  • Establish key risk indicators (KRIs) to identify potential ICT risks early
  • Regularly review logs for anomalies and indicators of compromise (IoCs)
2.6 Testing and Validation
DORA requires entities to validate the effectiveness of their ICT risk controls through regular testing.
Requirements Include:
  • Conducting penetration testing and red team exercises (see Testing Guide)
  • Reviewing the adequacy of ICT controls during audits
Practical Steps for Compliance:
  • Perform annual penetration tests targeting critical systems and applications
  • Simulate incident scenarios (e.g., ransomware attacks) to evaluate response capabilities
  • Collaborate with third-party experts to conduct independent reviews of ICT controls
3. DORA Compliance Checklist for ICT Risk Management Framework
To ensure compliance, organizations should implement the following measures:
ICT Risk Governance:
  • Designate a responsible function (e.g., CISO) for ICT risk management (see Governance Guide)
  • Ensure the Board oversees and approves the ICT risk management framework
Secure SDLC Integration:
  • Train developers on secure coding practices
  • Incorporate automated security tools into development pipelines
  • Establish secure design patterns as mandatory in project lifecycles
Incident Management:
  • Test incident response processes through tabletop exercises
Third-Party Risk Management:
  • Ensure vendors comply with security standards (e.g., ISO/IEC 27001) (see TP(S)RM Guide)
  • Perform due diligence and regular audits on third-party providers
Monitoring and Reporting:
  • Implement real-time monitoring tools and maintain logs for 6+ months
  • Report significant ICT incidents to regulators within specified timelines
4. Penalties for
Non-Compliance
Non-compliance with DORA's ICT risk management requirements can result in:
Fines and Sanctions
Financial penalties proportional to the severity of the non-compliance
Operational Restrictions
Suspension of critical ICT systems until compliance is achieved
Reputational Damage
Disclosure of non-compliance to the public
5. Tools and Frameworks for Compliance
The following tools and frameworks can help organizations achieve DORA compliance:
  • OWASP Top 10
    Guidelines for secure software development
  • NIST Cybersecurity Framework (CSF)
    Best practices for cybersecurity
  • CIS Controls
    Actionable controls for improving ICT resilience
  • ISO/IEC 27001
    Framework for information security management systems (ISMS)
  • BSIMM
    Guidance on improving software security programs
6. Conclusion
Building a robust ICT risk management framework and integrating a secure SDLC are critical components of DORA compliance. By embedding security by design principles into every aspect of ICT systems, organizations can enhance their resilience to threats, comply with regulatory requirements, and protect their operations and customers from harm.
7. References
  1. DORA Text (Regulation (EU) 2022/2554) Available at: Official EU DORA Regulation
  1. OWASP Secure Coding Practices Available at: OWASP Website
  1. NIST Cybersecurity Framework Available at: NIST CSF
  1. ISO/IEC 27001 Standards Available at: ISO Official Site
  1. CIS Benchmarks Available at: CIS Benchmarks
Links to Related DORA Compliance Themes
For a comprehensive understanding of DORA compliance, this guide aligns with the following related topics:
For detailed implementation guidance, refer to DORA's RTS and ITS documentation and related guides within this compliance series.
The StratOps way to accelerate DORA
CISO & Advisor | My StratOps newsletter helps cybersecurity experts achieve more, faster.

I hope this guide on Governance, Organization, Resources for ICT Risk will help your team achieve DORA compliance.
Have feedback? Let’s connect on LinkedIn
Not yet a member? Get insights & more resources in the StratOps newsletter
🚀 Accelerate your DORA implementation with StratOps
Implementation kits are a great start, but real resilience requires structured execution.
Join my StratOps trainings to master DORA’s 12 capabilities and fast-track compliance.