NIS2 and DORA are very practical regulations, the implementation of which is not just about „producing more papers” but requires specific actions in the organization. Areas requiring action include: risk management, identities and access, monitoring, incident response and IT vendor control.
The most important thing for IT and security officers is to translate regulatory requirements into architectural decisions and an action plan that can be implemented without stopping business processes. The processes and procedures described in NIS2 or DORA are supposed to work and bring concrete benefits, not lie nicely described in documents on a shelf.
At ISCG, we take a practical approach: from quick gap analysis, to prioritization, to implementation and maintenance of security mechanisms in Microsoft-based environments. The goal is to prepare efficient processes, practice them in practice (especially incident response procedures), and as a side effect we get the readiness to audit the environment.
Compliance is the security architecture, not the procedures themselves
NIS2 and DORA emphasize risk management and operational capabilities: incident detection, mitigation, business continuity and incident reporting. Incident response procedures must also work if the incident happens at night or over the weekend (in our experience, that's usually when attacks are launched).
In NIS2, reporting responsibilities are described in stages - including early warning in 24 hours and reporting in 72 hours after „knowledge of the incident” (awareness).
DORA describes in greater detail the operational requirements for financial institutions: the ICT risk management framework, resilience testing, the role of the board of directors, and requirements for ICT service providers (third parties).
In practice, you need a consistent governance model that includes: identity, access, monitoring, incident response process and vendor control. Documenting these processes makes sense if these processes are actually implemented.
NIS2 versus DORA - operational differences from an IT department perspective
Both regulations share a common goal: to increase incident resilience. However, they differ in scope and emphasis.
NIS2 covers a wide range of organizations in many sectors (key and important players). For many companies, this means the first „hard” requirements in the area of incidents, monitoring or risk.
DORA concerns the financial sector and the companies that provide IT services to it. The area of supplier management is emphasized here: requirements in contracts, audit rights, incident cooperation and a contingency plan for termination of cooperation. DORA also more strongly emphasizes the board's responsibility for the ICT risk management framework.
If you're in finance or work for the industry, DORA usually means faster entry into the details and more precise implementations.
Implementation checklist: step by step to readiness
1) ICT inventory and risk management
Start with an image: what is critical and what does it depend on.
- Identify critical business functions and the systems that support them (applications, databases, integrations, entitlements).
- Arrange identities and access: MFA as a minimum, target roles, access rules and privileged account approach.
- Establish a basic standard for classifying information (what is sensitive, what is protected, what can be shared).
2) Monitoring and reporting of incidents
NIS2 requires staged reporting (24h/72h, among other things), so you need to have a process and tools ready.
- Provide central visibility of events (logs, alerts, correlations).
- Set thresholds and criteria for a „significant incident” so the team knows what to escalate.
- Test the response (IR) and communication process - as a viable course of action.
3) Securing the IT supply chain
DORA is pushing hard on ICT providers: contracts, auditability, requirements and contingency scenarios.
- Build a registry of vendors (cloud, IT outsourcing, application vendors, integrators).
- Set minimum requirements: SLAs, audit rights, incident handling and audit cooperation policies.
- Prepare assumptions for an exit strategy (exit strategy) if the supplier ceases to meet requirements.
4) Business continuity and restoration
What matters in a crisis is whether you can replicate business process operations.
- Verify backups and restores and whether they were tested.
- Establish RTO/RPO priorities at least for key services.
- See to the owners of the processes - without this, decisions will be diluted.
Want to test your environment's readiness for NIS2/DORA without stalling your project?
Audit-readiness in 2-4 weeks: how to put it together without disorganizing the team
If the goal is to prepare quickly for an audit, a rhythm of short sprints works well. Each week has a clear outcome.
Week 1: scope + assets + risk
Map of critical services, owners and dependencies, list of suppliers and „top risks” and deficiencies.
Week 2: identity + access + monitoring
Overview of MFA, privileged accounts and access policies. Minimum login and detection standards and escalation thresholds.
Week 3: ICT suppliers + contracts + audit requirements
Supplier register, contract gaps and plan: what to renegotiate and in what order.
Week 4: remediation plan + schedule
List of „must-do” work, priorities, resources and responsibilities (e.g., based on RACI). Finally, a state of readiness - what is implemented, what is in progress, and where a management decision is needed.
How to start an audit without stalling the project
To plan a gap analysis without a long preliminary phase, we need some input data:
- Map key business processes and related IT systems.
- Identity and access status (MFA, privileged accounts, access rules).
- Outline of backup and DR (what is tested and how often).
- A list of key ICT suppliers and who is responsible for the relationship and contract.
This is usually enough to establish the audit scope, priorities and action plan.
FAQ - The most common questions about NIS2 and DORA
Does DORA replace NIS2 in the financial sector?
DORA is a sector-specific regulation for finance and broadly covers digital resilience (ICT risk, incidents, testing, vendors). This does not mean that NIS2 „disappears,” but for financial institutions the main burden of operational requirements is carried out by DORA.What are the incident reporting requirements in NIS2 (24h/72h)?
NIS2 describes phased reporting - including early warning at 24 hours and reporting at 72 hours after „awareness.” In practice, you need tools and a process that allows you to operate within these time windows.Does having tools (e.g. EDR/SIEM) guarantee compliance?
No. Tools are part of the puzzle, but compliance requires a process: who responds, at what time, what are the escalation thresholds, how do you report and how do you control suppliers.How do I know if my organization is a „key” or „important” entity in NIS2?
It depends on the sector and the criteria in the directive (annexes) and the parameters of the organization. It is best to do a brief legal and organizational qualification and translate the result into scope IT.What exactly does DORA's supply chain protection obligation mean?
ICT vendor registry, requirements in contracts (including cooperation in audits), continuous supervision, and exit strategy. These are areas that regularly return in requirements for the market.Where do we start if we don't have mature security policies?
From inventory and gap analysis: assets → risks → priorities → minimum standard of control and monitoring. Fine-tune the documentation later, once the foundation is in place.Let's talk about your IT readiness for NIS2 and DORA
Learn about our other services
Business applications
Services for applications and turnkey solutions in the area of process digitization and modern work environment.
Full support and optimization of IT infrastructure, ensuring stable development of your business.
IT infrastructure
Security of deployment and maintenance of Microsoft 365 and Azure services that enable flexible management and cost optimization.