DORA in practice: How crowd-sourced security makes resilience auditable

DORA requires Swiss companies to do much more than write policies or run annual spot checks. What matters is verifiable evidence of digital operational resilience. Crowd-sourced security helps bridge the gap between regulatory requirements and day-to-day IT. It enables continuous testing and produces audit-ready evidence for remediation, including along the supply chain.

gbf-blog-dora.png

The EU regulation DORA (Digital Operational Resilience Act) sets out what financial entities must have in place, both organisationally and technically, so that cyber attacks and system outages, whether in-house or at third parties, do not disrupt operations. DORA can also apply to Swiss companies. What matters is not only where a company is headquartered, but also its role within a group and within the supply chain.

Am I affected?

DORA has been in effect since January 17, 2025. There are three typical situations in which DORA becomes relevant for Swiss companies:

  • Swiss entities within EU groups (including group-internal IT or shared services)
  • Swiss service providers delivering ICT services to EU financial entities
  • Swiss providers in supply chains, where EU customers pass down DORA requirements contractually

If your organization falls into one of these categories, you need to do more than “be resilient” in principle. You need to be able to prove it.

DORA's practical impact: Operational discipline and evidence

DORA is primarily about operational resilience: clear accountability, recurring cycles, and reliable evidence. That requires governance and responsibility at board and executive level, including risk acceptance and prioritization.

In practice, DORA shows up as a combination of clear organization (roles, processes, accountabilities) and recurring cycles (test, prioritize, remediate, verify), supported by robust evidence.

DORA’s five key areas, briefly explained

DORA covers five areas that together form the overall picture:

  1. ICT risk management An end-to-end framework: policies, processes, controls, operations, and monitoring.

  2. ICT incident reporting Clear incident criteria, processes, timelines, responsibilities, and the ability to deliver consistent information.

  3. Digital operational resilience testing A risk-based testing program for critical services, including vulnerability management, retesting, and documentation. Depending on applicability, threat-led penetration testing (TLPT) may also be relevant.

  4. Managing ICT third-party risk (ICT service providers) Transparency over dependencies, minimum contractual clauses (for example, audit rights, incident obligations, SLAs), and exit and portability capabilities.

  5. Information sharing Structured sharing of cyber threats and vulnerabilities can strengthen resilience. Important context: information sharing is generally voluntary, while other DORA evidence requirements, such as those related to third party transparency, are mandatory.

Many organizations consolidate the typical evidence and artefacts that follow from these pillars into an “Evidence Pack”.

What you ultimately need: an “Evidence Pack”

In audits and when responding to customer requests, statements and slide decks don't stand up to scrutiny. Evidence does. A pragmatic target state is a structured evidence repository that brings decisions, tests, results, and improvements together in a clearly traceable way.

Typical components include:

  • Inventory of critical services, including dependencies and recovery objectives
  • Exercise and incident evidence (runbooks, escalation paths, tabletop records, lessons learned)
  • Test reports (for example penetration testing, red teaming, bug bounty programs, vulnerability assessment, scanning), including status and retests
  • Vulnerability management (prioritization, remediation cycle, analysis of exposure time)
  • Third party documentation (contracts, security addendum, audit rights, subcontractor rules, exit and portability)

The whitepaper outlines a more complete audit evidence structure and includes a compact checklist.

Where crowd-based security can help

Periodic tests are, by nature, point-in-time snapshots. Crowd-based security approaches, such as bug bounty programs or vulnerability disclosure programs, can bridge the gaps between testing cycles and surface changes in cloud environments, releases, and configurations earlier.

In crowd-based testing, external security researchers report vulnerabilities within clear rules and a defined scope. Triage and validation, reporting and retesting create reliable evidence and support the recurring improvement cycle (test, prioritize, remediate, verify).

When embedded properly, this can help identify changes between testing cycles earlier and supports remediation with verifiable evidence.

Quick check: How close are you to being “DORA audit-ready”?

This quick check is intended as a high-level sense-check. The interpretation of what “good” looks like and which evidence is typically expected is described in the whitepaper, including a checklist.

  • Are responsibilities clearly defined (including escalation) and are decisions on risk acceptance governed?
  • Are critical services documented, including dependencies (RTO/RPO, recovery testing)?
  • Is there a recurring test and improvement cycle (test, remediation, retest, documentation)?
  • Can you demonstrate the status of vulnerabilities (prioritization, remediation progress, exposure time)?
  • Are ICT third parties, including relevant subcontractors, transparently captured and contractually governed (audit, incident, SLAs, exit)?
  • Do you have incident runbooks and evidence from exercises (tabletops, review, actions)?

Whitepaper: DORA’s impact on Swiss companies

The whitepaper summarizes DORA for Swiss practice, outlines typical evidence expectations, and provides a concrete checklist for assessing your current state.

Download DORA whitepaper