Contribution

Contributing to the Project

Thanks for your interest in contributing! This project is a collaborative effort to provide open, practical resources to help organizations prepare for and comply with the Digital Operational Resilience Act (DORA).

We welcome contributions of all kinds: improvements to documentation, new templates, bug fixes, or discussions about best practices.

🛠 How to Contribute

1. Fork & Branch

• Fork the repository to your own GitHub account.

• Create a new branch for your changes:

  git checkout -b feature/my-improvement

2. Make Your Changes

• Follow existing formatting and style conventions.
• Keep commits small and meaningful.
• For significant changes (e.g., new templates, restructuring), please open an Issue first to discuss.

3. Test & Verify

• If you’re editing code, check that the site builds without errors.
• If you’re editing content, check spelling, formatting, and clarity.

4. Submit a Pull Request (PR)

• Push your branch and open a PR against main.

• In the PR description, explain:

  • What you changed
  • Why you changed it
  • Any related Issue numbers

---

✅ Contribution Guidelines

• Respect licensing: By contributing, you agree that your work will be released under this project’s license (see LICENSE).
• No legal advice: Do not submit content that could be interpreted as professional legal or regulatory advice. Keep templates and guidance general and practical.
• Stay original: Only contribute content you created yourself, or that is openly licensed and properly attributed.
• Be clear: Write in plain, accessible language so resources are usable by a wide audience.
• Be respectful: Follow a collaborative and constructive tone in Issues and PRs.

---

📄 Legal Disclaimer

This project provides general information and templates only. It does not constitute legal advice or guarantee compliance with DORA or other regulations. Contributors are responsible for ensuring their submissions respect copyright, licensing, and confidentiality obligations.

---

🙌 Getting Help

• Questions or Ideas? Open an Issue.
• Small Fixes? Go straight to a PR.
• Big Ideas? Start a discussion before coding.

We’re glad you’re here — thank you for helping make digital resilience more accessible to everyone!

Regulations markdown

Regulations markdown content should be specially formatted

Nested lists

All nested lists with markers in parentheses should be prefixed by dash and have indent related to it level.

Dot followed by number top-level list:

2. Financial entities shall ensure that ...:

    - (a) are aligned to the financial entity’s information security objectives included in the digital operational resilience strategy referred to in Article 6(8) of Regulation (EU) 2022/2554;

    - (b) indicate the date of the formal approval of the ICT security policies by the management body;

    - (c) contain indicators and measures to:

      - (i) monitor the implementation of the ICT security policies, procedures, protocols, and tools;

      - (ii) record exceptions from that implementation;

      - (iii)ensure that the digital operational resilience of the financial entity is ensured in case of exceptions as referred to in point (ii);

Letter in parentheses top-level lists:

Financial entities shall develop, document, and implement ...:

- (a) an indication of the approval ...

- (b) a procedure and a methodology...

  - (i) vulnerabilities and threats that affect or may affect the supported business functions, the ICT systems and ICT assets supporting those functions;

  - (ii) the quantitative or qualitative indicators to measure the impact and likelihood of the   vulnerabilities and threats referred to in point (i);

- (c) the procedure to identify, implement, and document ICT risk treatment measures for the ICT risks identified and assessed, including the determination of ICT risk treatment measures necessary to bring ICT risk within the risk tolerance level referred to in point (a);

- (d) for the residual ICT risks that are still present following the implementation of the ICT risk treatment measures referred to in point (c):

  - (i) provisions on the identification of those residual ICT risks;

  - (ii) the assignment of roles and responsibilities regarding:

    - (1) the acceptance of the residual ICT risks that exceed the financial entity’s risk tolerance level referred to in point (a);

    - (2) for the review process referred to in point (iv) of this point (d);

  - (iii)the development of an inventory of the accepted residual ICT risks, including a justification for their acceptance;