What is DORA in IT operations?
DORA in IT operations means putting the EU regulation DORA (Digital Operational Resilience Act) into practice, day to day, in the IT operations of financial entities. At its core, DORA requires traceable ICT risk management: verified access controls, documented protective measures and robust logs that can prove digital operational resilience at any time, not just describe it once. The exact obligations, scope and exemptions follow from the actual regulation text and need checking case by case. For Zscaler operations, DORA mainly means control that is lived and verified, not a policy written once and filed away.
DORA in IT operations in detail
DORA addresses financial entities and their critical ICT service providers with a single framework for digital operational resilience: ICT risk management, reporting major incidents, resilience testing and managing third-party risk are among its core building blocks. For day-to-day Zscaler operations, that means running access rights, rule sets and security configuration so they can be reviewed and audited at any time.
The distinction matters here too: Zscaler provides technical building blocks such as threat protection, policy enforcement and transaction/event logs, but a financial entity’s full DORA programme needs more than that, including testing programmes and governance processes. Under Article 4, the requirements are to be implemented in proportion to size and risk profile; a simplified framework under Article 16 applies to certain small institutions.
Why DORA matters in Zscaler operations
Financial entities are under particularly close supervisory scrutiny, and DORA explicitly requires ICT risk management to be continuous and demonstrable, not just documented on paper. Zscaler operations without clean, continuously maintained records of access and changes quickly become an audit gap.
Managing ICT third parties matters too: any financial entity using providers such as SourcingBlox or Zscaler itself must factor their risk contribution into its own DORA framework and be able to document it accordingly.
Common sources of error
- DORA documentation exists but does not reflect the actual configuration state of Zscaler operations.
- The audit trail is not kept complete, particularly for manual exceptions.
- Managing ICT third-party providers is not linked to day-to-day operations.
- Proportionality and institution-specific exemptions are not tracked on an ongoing basis.
DORA in practice: what CentaurNexus contributes
Compliance Mapping in CentaurNexus automatically maps real signals from the Zscaler tenant to DORA controls and bundles them into an exportable evidence pack for internal reviews and supervisory enquiries. Policy Health Saga complements this with a DORA-ready configuration report and a prioritised action plan, and the append-only audit trail evidences every change made through CentaurNexus in Zscaler operations. That way, the actual state of ICT risk management can be shown at any time, instead of being pieced together only when an audit is due. More on systematic configuration review in the guide Getting more from your Zscaler licence.
DORA in operation: how to spot it
DORA usually gets read as a legal topic. In operations, the question looks different: not “are we compliant”, but “can we show it when someone asks”. Four situations make the difference visible.
“The auditor asks who changed the rule.”
What it usually is: The question is not really about the tool, it is about traceability. An answer from memory doesn’t count.
How to tell them apart: What matters is a change history that brings together the time, the role that acted and the prior state. Audited Change History is built for exactly that.
“We don’t know which provider has access to what.”
What it usually is: The point where DORA tips over from paper into operations. The outsourcing register is only as good as the actual access state.
How to tell them apart: The state on the ground needs to be reconciled against the register, not the other way round. Vendor Session Access keeps third-party access visible, with status and validity.
“Producing the evidence costs us days, every time.”
What it usually is: A sign that evidence is being pieced together after the fact instead of generated continuously.
How to tell them apart: Compliance Mapping maps tenant signals to the control framework on an ongoing basis. The effort shifts from a fixed deadline into everyday operations.
“We reported an incident, but the deadline was already tight.”
What it usually is: Reporting deadlines start from the moment you become aware. If the first call is how you find out something has failed, you lose the start of the clock.
How to tell them apart: Early detection here is not a convenience, it protects your deadline. The watchdog reports defined states as soon as they occur, and their resolution just the same.
In operations, DORA comes down to three questions: who changed what, who has external access, and since when have we known. All three either exist continuously, or not at all.
Related terms
Frequently asked questions about DORA in IT operations
DORA (Digital Operational Resilience Act) has applied directly across the EU since 17 January 2025 and covers financial entities from banks and insurers to investment firms and payment institutions, as well as ICT third-party service providers. Article 2 lists the types of institution and exemptions; classification needs checking case by case.
In a Zscaler context, that mainly means running access rights, rule sets and logs so that you can prove at any time who can access what, which protective measures are active, and how incidents are handled. DORA requires a continuous, documented process for this, not one-off measures.
No. Zscaler provides important technical building blocks such as threat protection and logging, but DORA also requires organisational elements such as testing programmes, reporting processes and management of ICT third parties that go beyond any single security service.
DORA places great weight on the traceability of ICT incidents and governance decisions. A complete audit trail of every security-relevant change in Zscaler operations delivers exactly that traceability, and supports both internal reviews and supervisory enquiries.
Yes. DORA explicitly addresses ICT third-party service providers as well. The European Supervisory Authorities (ESAs) directly oversee critical providers; classification follows the criteria in Article 31, such as how systemically important the provider’s customers are and how substitutable it is. The ESAs published a first list of critical providers in November 2025; classification needs checking case by case.
- Regulation (EU) 2022/2554 (DORA) - eur-lex.europa.eu
- BaFin: Digital Operational Resilience (DORA) - bafin.de
- EBA/ESAs: designation of the first critical ICT third-party providers (November 2025) - eba.europa.eu
- Zscaler Help Portal: official documentation on reporting and logging - help.zscaler.com
Note: CentaurNexus is an independent product of SourcingBlox GmbH and not an offering of Zscaler, Inc. Product and brand names belong to their respective owners. The current regulation text and supervisory practice in force are what ultimately governs the specific legal status of DORA.