Practical guides on EU cybersecurity regulations and compliance requirements for companies operating in Poland and the European Union. We explain NIS2, the Polish KSC Act, DORA, the Cyber Resilience Act, ISO/IEC 27001, NIST Cybersecurity Framework and related obligations in a clear, business-focused way.
Does NIS2 Cover Asset Inventory and Visibility? Scope and Concrete Requirements
Yes, NIS2 covers asset inventory and visibility, although it does not always use the everyday language of “CMDB” or “asset inventory”. Article 21 of the Directive refers to asset management, access control policies, system security, business continuity, supply chain security and effectiveness assessment of cybersecurity measures. In practice, this means that a company should know which systems, devices, applications, accounts, data, cloud services, suppliers and public-facing assets it has, who owns them, how critical they are, what data they process, who has access, whether they are covered by backup, updates, monitoring and security controls. For selected digital and managed service entities, Implementing Regulation 2024/2690 further specifies the requirement for a complete, accurate, up-to-date and consistent asset inventory.
Prepared by: CCyber Editorial Team
Yes, NIS2 covers asset inventory and visibility. This does not mean that every company must immediately buy an expensive CMDB, CAASM, EASM or enterprise platform. It does mean, however, that an organization in scope of NIS2 should be able to demonstrate which assets it has, which are critical, who owns them, what data they process, who has access, whether they are protected, whether they are monitored and how they affect business continuity. Asset inventory is needed for risk analysis, access control, vulnerability management, backup, incident response, supply chain security, effectiveness testing and board reporting. Without asset visibility, NIS2 compliance becomes a declaration, not an operating cyber risk management system.
July 2026
Yes. Article 21 of NIS2 refers, among other measures, to human resources security, access control policies and asset management. This means that asset management is part of the mandatory cybersecurity risk management measures for entities in scope of the Directive.
At the same time, asset inventory also follows indirectly from other requirements. Risk analysis, incident management, backup planning, supplier assessment, access control and effectiveness testing cannot be done without knowing which assets the company has.
Asset visibility is the organization’s ability to quickly determine which assets exist, where they are, who is responsible for them, what their security status is and how they affect a business service or process. A hardware list alone is not enough.
Inventory is the register. It shows what the company has. It can be maintained in a spreadsheet, CMDB, ITSM tool, asset management system or GRC platform.
Visibility is the ability to detect and confirm the actual state of assets. It shows whether the register reflects reality. Visibility comes from identity directories, EDR, MDM, DHCP, DNS, firewalls, cloud, backup, scanners, invoices, contracts and interviews with process owners.
The company has 120 laptops in a spreadsheet. That is inventory. But EDR shows 138 devices, DHCP shows 151 hostnames, and accounting shows invoices for 9 SaaS tools outside the IT list. That is visibility. Only combining both layers provides real control.
Implementing Regulation 2024/2690 specifies technical and methodological NIS2 requirements for selected digital entities and trust services, including DNS providers, TLD registries, cloud providers, data centres, CDNs, managed service providers, managed security service providers, marketplaces, search engines, social networking platforms and trust services.
This regulation is not automatically a detailed requirements catalogue for every NIS2 entity in every sector, but it is a very useful point of reference. It shows how the regulator understands asset management: asset classification, inventory, freshness, consistency, change history and lifecycle management.
For entities covered by Regulation 2024/2690, requirements are much more concrete than the general wording of NIS2. In practice, they are worth using as a benchmark in other organizations as well.
The organization should define classification levels for assets, including information, in scope of its network and information systems. The classification should correspond to the required protection level.
The organization should maintain an asset inventory that is complete, accurate, up to date and consistent. Changes to inventory entries should be traceable.
The register does not need excessive detail for every minor element, but it must be sufficient for risk, protection, monitoring, recovery and audit.
The register should include operations and services, as well as network and information systems and other assets supporting those operations and services.
The register should be regularly reviewed and updated. Change history should be documented.
The register should be simple, but useful. Its purpose is not to create an archive that nobody reads. Its purpose is risk management.
It can be a spreadsheet or lightweight database. What matters is ownership, versioning, mandatory fields and review cycle.
If EDR shows 80 laptops, the identity directory shows 95 devices and DHCP shows 120 hosts, this is not a problem to hide. It is something to investigate. Differences show visibility gaps.
An unknown asset should not disappear from the report. It should have “to be investigated” status, action owner and deadline.
New system, new supplier, new SaaS application, new integration, new domain and new administrator account should trigger inventory update.
Inventory without remediation is only a catalogue. NIS2 requires risk management, so review results should lead to decisions.
NIS2 is not only about laptops. The greatest risk may be in SaaS, administrator accounts, public assets, data and suppliers.
A system list without information about which services those systems support does not help assess incident impact.
IT may know the system name, but business knows how much an outage will affect customers, revenue and operations.
New supplier, new application, new integration or new administrator account should update the register.
Abandoned subdomains, old VPNs, public panels and forgotten test servers are a common source of risk.
A register without MFA, backup, EDR, update and monitoring status does not support real risk management.
An auditor may ask when the asset was added, who changed criticality and why the system was retired.
Even the best tool will not help if nobody confirms owners, closes gaps or reports risk.
A services company with 110 employees is preparing for an audit by a customer in scope of NIS2. The company uses Microsoft 365, CRM, invoicing system, file repository, several SaaS applications, an IT provider and external backup. IT has a laptop list, but not a complete list of applications, cloud services, administrator accounts and public assets.
During the first review, the company creates an asset register. It exports users and administrators from Microsoft Entra ID, devices from EDR, applications from invoices, domains from DNS, public IPs from hosting and systems covered by backup. It turns out that the company uses 18 SaaS services, of which 7 were unknown to IT. Three critical systems have no confirmed restore test. Two supplier accounts have administrator access without formal owner. One old subdomain points to an unused test panel.
The company does not immediately buy an expensive tool. First, it organizes owners, criticality, MFA, backup, public exposure and supplier access. After 90 days, it has an asset register, gap report, remediation plan and review evidence for the auditor. This is not a perfect enterprise model, but it is an operating visibility system that supports NIS2 compliance.
ccyber.io helps companies prepare asset inventory and visibility models aligned with NIS2 without excessive costs and without starting with expensive enterprise tools. We build the process, register, data sources, metrics, evidence and improvement plan.
We can support your organization with:
The best first step is a NIS2 Asset Visibility Workshop. In a short workshop, the company can determine which assets it already sees, where the biggest gaps are, which data sources can be used without new costs and what register is sufficient for the first compliance stage.
Yes. NIS2 refers to asset management as part of cybersecurity risk management measures. Asset inventory is also necessary for risk, access, backup, incidents, suppliers and business continuity.
No. NIS2 does not prescribe a specific tool. What matters is whether the company can demonstrate current inventory, owners, criticality, security status and regular review.
At the start, yes, if it has an owner, versioning, mandatory fields, change history, recurring review and is compared with technical data. For larger organizations, a spreadsheet may quickly become insufficient.
Visibility means the company not only has a register, but can detect assets from multiple sources, compare them with the register, identify gaps and start remediation actions.
Critical systems, customer data, identity, email, backup, finance systems, public assets, administrator accounts, SaaS services, cloud and suppliers with access.
No. It applies to selected digital entity categories and trust services. However, it is a very useful practical benchmark for asset management in other organizations as well.
Critical assets should be reviewed at least quarterly and after every material change. A full review can be done annually or more frequently if the organization changes quickly.
Start with critical services, systems, users, administrators, devices, SaaS applications, suppliers, domains, public IPs and backup. Then assign owners, criticality and security status.
NIS2 covers asset inventory and visibility because cyber risk cannot be managed without them. Asset management is explicitly referenced in Article 21, and concrete requirements for some digital and managed service entities are further specified in Implementing Regulation 2024/2690.
In practice, a NIS2-aligned inventory should cover not only hardware, but also business services, ICT systems, applications, data, accounts, suppliers, cloud, public-facing assets, backup, monitoring and dependencies. Every asset should have an owner, criticality, security status and review date.
The best rule is: do not ask only whether we have an asset list. Ask whether that list helps manage risk, recover after an incident, detect unknown assets and show the auditor that the organization knows what it protects.
Which Companies Are Currently Affected by Regulations Such as NIS2, CRA and DORA - EU Country Overview
NIS2, CRA and DORA apply to different types of companies and should not be treated as one single regime. NIS2 mainly covers medium-sized and large entities in selected critical sectors, but details depend on national transposition in each EU Member State. DORA applies to the financial sector and ICT risk, while ICT providers are mainly affected through contracts, oversight of critical ICT providers and requirements from financial customers. CRA applies to manufacturers, importers, distributors and other economic operators making products with digital elements available on the EU market. For companies operating in multiple countries, the key is to check separately: country of operation, sector, company size, product type, financial-sector customer relationship and supply chain role.
Prepared by: CCyber Editorial Team
NIS2, CRA and DORA apply to different companies. NIS2 mainly applies to medium-sized and large entities in critical sectors and selected smaller entities of special importance, but details depend on national law in each EU Member State. CRA applies to products with digital elements, meaning manufacturers, importers, distributors, authorised representatives and some commercially relevant open-source roles. DORA applies to financial entities and ICT risk, while ICT providers are mainly affected through contracts, financial-sector customer requirements and oversight of critical ICT third-party providers. A company operating in several EU countries should check separately: country, sector, size, legal role, service type, product, customers and suppliers.
July 2026
This overview is not individual legal advice. In EU cyber regulations, definitions, exceptions, thresholds, national acts, sector of activity and the company’s exact role matter. Two companies in the same industry may have different status if one is medium-sized and the other is a microenterprise, if one acts as a digital product manufacturer and the other only as an integrator, or if one serves banks and the other does not.
The most important practical rule is: do not ask only “is my industry covered?”. Ask: in which country do we operate, what service do we provide, how large is the company, what data do we process, are we a supplier to a regulated sector and do we place a digital product on the EU market?
| Regulation | Simplest question | Who is affected | What matters most |
|---|---|---|---|
| NIS2 | Does the company operate in a critical sector and meet a threshold or exception? | Mainly medium-sized and large entities in NIS2 sectors and selected entities regardless of size | Cyber risk management, incidents, supply chain, business continuity, management accountability |
| DORA | Is the company a financial entity or an ICT provider to the financial sector? | Financial entities, while ICT providers are mainly affected through contracts, customer requirements and critical provider oversight | ICT risk, ICT incidents, digital resilience testing, ICT suppliers, register of information, contracts and exit plans |
| CRA | Does the company make a product with digital elements available on the EU market? | Manufacturers, importers, distributors, authorised representatives, selected open-source roles | Product security, vulnerabilities, updates, technical documentation, conformity assessment, CE marking, reporting |
NIS2 covers entities in sectors of high criticality and other critical sectors. As a rule, it covers medium-sized and large companies, but it also allows selected smaller entities to be covered where they have a special role or importance.
DORA applies to the financial sector. Direct obligations primarily apply to financial entities. ICT providers are nevertheless strongly affected indirectly, because their financial-sector customers must assess risk, maintain appropriate contracts, registers, audit rights, exit plans and monitor ICT services.
CRA applies to products with digital elements made available on the EU market. This means it does not apply only to classic IoT devices. It may cover software, hardware, firmware, applications, components, security products, network devices and products connected to a device or network.
The table takes a practical company perspective. DORA and CRA are regulations, so their core scope is common across the EU. NIS2 requires checking national transposition, national authorities, registration procedures and possible local extensions. Special attention is marked for countries which, according to the Commission communication from July 2026, had not notified full transposition and were referred to the Court of Justice of the EU.
| EU country | NIS2 - who to check | DORA - who to check | CRA - who to check | Practical note |
|---|---|---|---|---|
| Austria | Medium-sized and large entities in NIS2 sectors and selected special entities under national law | Financial entities operating in Austria and their ICT providers | Economic operators making products with digital elements available on the EU market | Check national NIS2 implementing law, authority and registration duties |
| Belgium | Medium-sized and large entities in NIS2 sectors and providers of digital and managed services | Banks, insurers, fintechs and other financial market entities plus ICT providers | Manufacturers, importers and distributors of digital products | Check local thresholds, registration and authority requirements |
| Bulgaria | Entities in NIS2 sectors, especially energy, transport, health, digital infrastructure and ICT services | Financial entities and ICT providers supporting financial functions | Companies placing software, hardware or components on the EU market | Check national transposition status and local deadlines |
| Croatia | Medium-sized and large entities in NIS2 sectors and suppliers to such entities | Financial sector and ICT providers | Economic operators of digital products | Check national obligations, authority and incident notification path |
| Cyprus | Entities in NIS2 sectors, especially digital, finance, health and service sectors | Financial entities active in Cyprus and their ICT providers | Manufacturers, importers and distributors of digital products | Check national NIS2 transposition and competent CSIRT |
| Czechia | Medium-sized and large entities in NIS2 sectors and nationally specified entities | Financial entities, fintech, crypto, insurance and ICT providers | Companies making products with digital elements available on the EU market | Check Czech NIS2 law and implementing acts |
| Denmark | Entities in NIS2 sectors including energy, transport, health, digital infrastructure and administration | Financial entities and ICT providers | Economic operators of digital products | Check local sector authorities and registration requirements |
| Estonia | Entities in NIS2 sectors, especially digital infrastructure, administration, health and ICT services | Financial entities and ICT providers for finance | Manufacturers, importers and distributors of digital products | Check local supervision and incident reporting rules |
| Finland | Medium-sized and large entities in NIS2 sectors and selected smaller entities of special importance | Financial sector and ICT providers | Economic operators of products with digital elements | Check Finnish implementing acts and sector-specific authority |
| France | Entities in NIS2 sectors, but full transposition status requires special verification | Financial entities and ICT providers serving the French financial market | Manufacturers, importers and distributors of digital products | Special note: the Commission referred France to the CJEU for failure to notify full NIS2 transposition |
| Germany | Entities in NIS2 sectors, including important and particularly important entities under national law | Financial entities and ICT providers | Companies placing digital products on the EU market | Check local thresholds, registration and BSI requirements |
| Greece | Entities in NIS2 sectors, especially energy, transport, health, digital infrastructure and administration | Financial entities and ICT providers | Economic operators of digital products | Check national law and the national point of contact |
| Hungary | Medium-sized and large entities in NIS2 sectors and selected entities under national law | Financial entities and ICT providers | Manufacturers, importers and distributors of digital products | Check local registration and supervision requirements |
| Ireland | Entities in NIS2 sectors, but full transposition status requires special verification | Financial entities, fintechs, ICT providers and finance service centres | Product companies and distributors of digital products on the EU market | Special note: the Commission referred Ireland to the CJEU for failure to notify full NIS2 transposition |
| Italy | Entities in NIS2 sectors and managed or digital service providers | Financial entities and ICT providers | Economic operators of digital products | Check Italian implementing rules and local procedures |
| Latvia | Medium-sized and large entities in NIS2 sectors and selected special entities | Financial entities and ICT providers | Manufacturers, importers and distributors of digital products | Check local authorities and obligation dates |
| Lithuania | Entities in NIS2 sectors including digital infrastructure, health, energy, transport and administration | Financial entities and ICT providers | Economic operators of digital products | Check national registration and notification duties |
| Luxembourg | Entities in NIS2 sectors, especially finance, digital, ICT service management and administration | Highly relevant for the financial sector and ICT providers | Companies making products with digital elements available | Check the relationship between NIS2, financial supervision and DORA |
| Malta | Entities in NIS2 sectors and digital or managed service providers | Financial entities and ICT providers | Manufacturers, importers and distributors of digital products | Check local registration path and competent authority |
| Netherlands | Entities in NIS2 sectors, but full transposition status requires special verification | Financial entities and ICT providers in the Dutch market | Economic operators of digital products | Special note: the Commission referred the Netherlands to the CJEU for failure to notify full NIS2 transposition |
| Poland | Entities in NIS2 sectors and entities identified by the national KSC amendment | Financial entities and ICT providers serving the financial sector | Product companies placing software, hardware or components on the EU market | Check the current KSC status and sector rules, because they decide national details |
| Portugal | Medium-sized and large entities in NIS2 sectors and selected entities under national law | Financial entities and ICT providers | Economic operators of digital products | Check local transposition and competent authorities |
| Romania | Entities in NIS2 sectors including energy, transport, health, digital infrastructure and administration | Financial entities and ICT providers | Companies making products with digital elements available | Check Romanian rules and registration procedures |
| Slovakia | Entities in NIS2 sectors and providers of important services to such entities | Financial entities and ICT providers | Manufacturers, importers and distributors of digital products | Check national requirements and entity classification |
| Slovenia | Medium-sized and large entities in NIS2 sectors and special entities under national law | Financial entities and ICT providers | Economic operators of digital products | Check local implementation status and supervisory authorities |
| Spain | Entities in NIS2 sectors, but full transposition status requires special verification | Financial entities and ICT providers serving the Spanish market | Manufacturers, importers and distributors of digital products | Special note: the Commission referred Spain to the CJEU for failure to notify full NIS2 transposition |
| Sweden | Entities in NIS2 sectors, especially infrastructure, administration, health, transport, energy and digital services | Financial entities and ICT providers | Economic operators of digital products | Check local rules and competent sector authority |
A company operating in multiple EU countries should not prepare one generic assessment for the whole group. It should prepare a matrix: country, entity, sector, product, service, customer and supplier.
It may not be directly a financial entity under DORA, but it will be an ICT provider to a financial customer. If it develops its own digital product, it may also need to prepare for CRA. If it meets NIS2 criteria as a managed service provider, digital provider or ICT service management entity, it must also check NIS2.
It may be covered by CRA as a manufacturer of a product with digital elements. If it serves energy, transport, healthcare or critical manufacturing customers, it may receive NIS2 requirements through contracts. If it supplies to the financial sector, the customer may require DORA-aligned evidence.
It may be a digital or ICT service provider. If it offers a product with digital elements, component or customer-installed agent, it should check CRA. If it serves financial customers, it should prepare an ICT supplier pack under DORA.
The key regulation is DORA. NIS2 may matter sectorally and for relationships with national authorities, but DORA operates as sector-specific EU law for many cyber and ICT obligations in the financial sector. CRA may appear if the bank or fintech is a digital product manufacturer, not only a user.
It may be subject to NIS2 if it operates in one of the covered manufacturing sectors and meets the criteria. It may be indirectly affected by CRA as a buyer of digital products or directly affected if it manufactures hardware or software with digital elements.
These are three different mechanisms. NIS2 concerns sectors and entities, DORA concerns the financial sector and ICT, and CRA concerns digital products.
A company operating in several EU Member States must check local NIS2 rules, authorities and registration duties in each relevant country.
A company may not be directly subject to DORA or NIS2, but it may receive contractual requirements from a bank, infrastructure operator or NIS2 customer.
Without a product register, it is difficult to know which products have digital elements, who is the manufacturer and which conformity path is needed.
A company using an AI tool or application is not always a manufacturer under CRA. A company selling a product under its own brand may be one.
Small companies may be indirectly affected by customer requirements or directly covered by selected exceptions.
National NIS2 transposition status, CRA guidance, standards, implementing acts and authority practice can change.
A Polish SaaS company sells its platform to customers in Germany, France, Spain and the Netherlands. Some customers are banks and insurers. The platform has a customer-installed agent, API, administration panel and customer data integration module.
The analysis shows three parallel tracks. First, financial customers require an ICT supplier pack under DORA: SLA, incidents, testing, exit plan, subcontractors and security evidence. Second, depending on company size and service type, NIS2 must be checked in the countries of operation and in Poland. Third, the customer-installed agent may be a product with digital elements, so the company needs a CRA assessment, SBOM, vulnerability process and product compliance plan.
The key board conclusion is: the company should not ask “are we subject to one regulation?”. It should build a matrix: NIS2 for sectors and countries, DORA for financial customers, CRA for digital products.
ccyber.io helps companies determine which EU cyber regulations affect them directly or indirectly. We combine NIS2, KSC, DORA, CRA, AI Act, ISO 27001, cyber insurance and customer requirement perspectives.
We can support your organization with:
The best first step is an EU Cyber Regulations Applicability Workshop. In a short workshop, the company can identify which entities, countries, products, services and customers trigger obligations under NIS2, DORA or CRA.
Not fully. NIS2 is a directive and requires national transposition. Core sectors and assumptions are EU-level, but details, authorities, registration and supervisory practice are national.
No. DORA applies to a broad catalogue of financial entities, including payment institutions, investment firms, insurers, crypto entities and other financial market participants.
An ICT provider is usually affected by DORA through financial customer requirements, contracts, audits, register of information, tests and exit plans. Critical ICT providers may be subject to additional oversight.
No. CRA also applies to software, components, firmware, applications and products with digital elements made available on the EU market.
Yes. It may be outside direct NIS2 scope, but be a supplier to a regulated entity. It may also be a digital product manufacturer under CRA or an ICT provider to a financial entity under DORA.
The country and entity matrix matters most. For NIS2, check each country. For DORA, check financial customers and ICT services. For CRA, check products and supply chain roles.
Yes. An example is a SaaS provider for banks that meets NIS2 thresholds and sells a product with digital elements on the EU market.
Start with the list of countries, entities, products, services, regulated customers and suppliers. Then build the applicability matrix: NIS2, DORA, CRA and national requirements.
NIS2, CRA and DORA do not answer the same question. NIS2 asks about the entity’s sector, size and importance. DORA asks about the financial sector, ICT risk, suppliers and critical functions. CRA asks about the product with digital elements and the company’s role in the product supply chain.
Across the EU, DORA and CRA have a largely common scope because they are regulations. NIS2 requires national transposition, so companies must track the laws of the Member States where they operate. Multinational companies especially should not rely on one generic assessment.
The best rule is: prepare one applicability matrix for the whole group, but make decisions separately for country, entity, sector, product, service and regulated customer relationship.
What Compliance Evidence Should You Prepare for DORA, NIS2, KSC and ISO/IEC 27001?
Compliance evidence for DORA, NIS2, KSC and ISO/IEC 27001 is not only about policies and procedures. An auditor, regulator, customer or board will want to see that the company truly manages cyber risk: applicability assessment, system scope, risk register, asset register, board decisions, policies, test results, logs, backup reports, access reviews, training, incident register, supplier assessments, business continuity plan, exercise reports, remediation actions and review evidence. The best approach is one evidence matrix that maps the same artifacts to multiple requirements, instead of building separate folders for each regulation.
Prepared by: CCyber Editorial Team
Compliance evidence for DORA, NIS2, KSC and ISO/IEC 27001 should show not only that the company has documents, but that it truly manages cyber risk and digital resilience. The minimum evidence pack includes applicability assessment, organizational and system scope, asset register, risk register, risk treatment plan, security policies, board approvals, roles and responsibilities, MFA, backup, restore testing, incident response plan, incident register, notification procedures, BCP, DRP, resilience tests, access reviews, supplier register, supplier assessments, contracts with security clauses, training, logs, monitoring, internal audits, management reviews and corrective actions. The best approach is to prepare one evidence matrix that maps the same artifacts to DORA, NIS2, KSC and ISO/IEC 27001.
July 2026
In many companies, “evidence” means a PDF policy. That is not enough. In a compliance audit, the evidence chain matters: what the company planned, what it implemented, who approved it, when effectiveness was checked and what was improved after a gap was found.
A document describes a rule or process. Example: access management policy, incident procedure, BCP or supplier policy.
Evidence shows that the document works in practice. Example: access review report, administrator role activation log, restore test report, tabletop minutes or list of removed permissions.
An artifact is any item that may be shown as evidence: file, report, log, configuration screenshot, ticket, protocol, board decision, session recording, system export or registry entry.
These frameworks are not identical, but all require proof that the organization manages security in an organized way. An auditor will not be satisfied with “we have it implemented”. They will want to see evidence.
DORA is the most detailed for the financial sector and ICT risk. Evidence should show ICT risk management, ICT incidents, digital operational resilience testing, ICT third-party risk, register of information, contracts, subcontractors, tests and reporting.
NIS2 focuses on cybersecurity risk management measures, significant incident reporting, management accountability and supply chain security. Evidence should show that the company has policies, processes, technical measures, training and risk oversight.
KSC is the national context for Polish organizations. Companies must work with the currently binding law and the current state of national NIS2 implementation. Evidence should support national duties: applicability assessment, responsibilities, contacts, notifications, cooperation with competent authorities, risk management and documented actions.
ISO/IEC 27001 requires systematic information security management. Evidence should show the ISMS: scope, context, risks, objectives, Statement of Applicability, risk treatment plan, internal audit, management review, corrective actions and control effectiveness.
Building one repository for DORA, another for NIS2, another for KSC and another for ISO/IEC 27001 quickly creates chaos. The same evidence can support many requirements.
A data restore test report can support:
This is the first evidence item to prepare. The organization must know whether and why it is subject to DORA, NIS2, KSC or ISO/IEC 27001, and which systems, services, companies and locations are covered.
A document with date, owner, version, legal or standard basis, board decision and planned review date.
Regulations and standards increasingly require visible management involvement. The board should approve risks, risk management measures, budget, priorities and reviews.
Minutes or a decision showing that the board not only received information, but made a decision, accepted risk or assigned actions.
You cannot protect, test or audit what the company cannot see. The asset register is a foundation of compliance.
A register updated periodically, with owners, criticality, process links and change history.
Compliance evidence must show that risk is assessed, prioritized and managed, not only written into a document.
Each risk has an owner, rating, action plan, deadline, status and evidence of closure or conscious acceptance.
For ISO/IEC 27001, the Statement of Applicability is a key evidence item. For DORA, NIS2 and KSC, it is useful to prepare a similar control map.
One map showing which controls satisfy specific requirements and where the evidence of their operation is stored.
Policies are necessary, but only as a foundation. Policies without execution evidence are not enough.
A document that is approved, current, known to process owners and linked to real execution records.
Access to systems is one of the most important audit areas. Evidence should show who has access, why, who approved it and when it was reviewed.
A report showing specific accounts, systems, roles, decisions, review dates and actions after review.
Compliance evidence must allow the company to reconstruct what happened. Logs are needed not only for security, but also for audit and incidents.
A sample event reconstruction: login, role activation, change performed, ticket, approval, alert and case closure.
The auditor will want to know whether the company can detect, classify, escalate, handle, notify and document incidents.
An incident record with timeline, decisions, communication, impact, classification, technical evidence and closed remediation actions.
DORA, NIS2 and KSC emphasize incident reporting. ISO/IEC 27001 requires systematic incident management. The company must have evidence that it can meet notification deadlines and criteria.
A tabletop or test showing that the company can classify an incident, collect information, approve communication and submit the notification within the required time.
One of the most important evidence items is the recovery test. Backup without testing is a declaration, not resilience evidence.
A restore test report with date, scope, result, recovery time, problems and remediation actions.
DORA requires a digital operational resilience testing programme. NIS2 and ISO/IEC 27001 also expect effectiveness testing. Evidence is not the test plan alone, but results and post-test actions.
A test includes scope, methodology, result, gap owners, priorities, deadlines and closure confirmation.
Regulations and standards expect the company to know vulnerabilities, prioritize them and control changes in the environment.
An example vulnerability from detection to closure: scan, risk assessment, ticket, fix, retest and closure approval.
Supplier evidence is especially important under DORA and NIS2. In ISO/IEC 27001, it is also a key part of information security controls.
A complete supplier card: service, data, access, criticality, risk, contract, subcontractors, incidents, SLA, exit plan and latest review.
Training cannot be only a signed attendance list. Evidence should show who was trained, on what, when and whether training was effective.
Training report with scope, attendance, test results, conclusions and improvement actions.
Evidence should show that the company knows what data it processes, how it classifies it, who has access to it and how it is protected.
Data map with location, owner, classification, baseline controls and latest access review.
If the company develops or maintains applications, the audit will ask about security by design, testing and vulnerability handling.
Release report showing security requirements, tests, results, exceptions, approvals and remediation actions.
ISO/IEC 27001 requires internal ISMS audits, but audits also provide strong evidence for DORA, NIS2 and KSC.
An audit report that not only describes gaps, but also shows owners, deadlines and closure evidence.
Management review shows that leadership oversees the system, risks, incidents, audit results, action effectiveness and resource needs.
Review minutes with decisions, action owners and deadlines, not just a presentation without decision trace.
Auditors know that nobody has a perfect system. What matters is whether the company finds gaps and closes them in a controlled way.
One completed corrective action shown from gap detection to confirmation of effectiveness after the fix.
Companies have some IT procedures, but lack the DORA register of information, mapping of ICT services to critical or important functions, subcontractor controls and ready exit plans.
Companies have IT procedures, but lack formal board decisions, management training evidence, a map of services covered by requirements and evidence of effectiveness assessment.
The organization prepares policies, but lacks a strong link between risks, controls, SoA, evidence of control operation, audit and management review.
Someone must own the structure, freshness, access, naming and completeness of evidence.
A better structure is: risk, access, incidents, backup, suppliers, training, audits. The matrix then shows regulatory mapping.
The auditor must know whether the evidence is current and who can explain it.
Policies, procedures and reports should have a version, approval date and change history.
A screenshot may help, but a system report, log, ticket or recurring automated report is stronger.
If evidence is created one week before the audit, it is usually inconsistent, incomplete or disconnected from real processes.
A backup policy does not replace a backup report and restore test. An access review procedure does not replace an actual review.
This leads to duplication and contradictions. One evidence matrix with requirement mapping is better.
Evidence without an owner quickly becomes outdated. The auditor asks, and nobody knows who can explain the document.
The company does not know whether evidence is current. This is especially dangerous for policies, risk registers and technical reports.
Declarations are not enough. System reports, logs, tickets, test results and approval evidence are needed.
A test without a remediation plan does not improve compliance. The auditor will ask what was done with the results.
The board may discuss cybersecurity, but without minutes, decisions and actions it is difficult to prove.
A technology company providing services to the financial sector prepares at the same time for a customer audit, ISO/IEC 27001 and DORA requirements as an ICT provider. The team has many documents: policies, procedures, backup reports, scan results and contracts. The problem is that nobody knows which document supports which requirement.
The company creates an evidence matrix. The same restore test report maps to business continuity in ISO/IEC 27001, digital resilience in DORA and customer requirements. The same supplier register maps to DORA, NIS2 and ISO/IEC 27001. The same access review maps to access control, PAM, audit and cyber insurance.
After 90 days, the company does not have more documents than before. It has better organized evidence. The customer audit runs faster because the team can show the requirement, evidence, owner, date and remediation status.
ccyber.io helps companies prepare practical compliance evidence packs for DORA, NIS2, KSC and ISO/IEC 27001. We do not build documents just for audits. We connect regulations, risks, controls, technical evidence and board decisions into one coherent system.
We can support your organization with:
The best first step is a Compliance Evidence Workshop. In a short workshop, the company can define which requirements apply, which evidence already exists, which evidence is weak, where owners are missing and how to build one evidence matrix across multiple regulations.
No. A policy is necessary, but execution must be shown: reports, logs, tests, reviews, decisions, training and remediation actions.
Yes. Many evidence items are shared, such as risk register, asset register, backup, restore test, access review, incident register, supplier assessment and audit report.
ICT risk management framework, register of information, ICT incidents, digital operational resilience testing, ICT supplier management, contracts, subcontractors and exit plans.
Applicability assessment, risk management, management approval, incident handling, business continuity, supply chain security, cyber hygiene, training and notification procedures.
ISMS scope, risk assessment, risk treatment plan, Statement of Applicability, security objectives, internal audit, management review and corrective actions.
It depends on risk and process. Risk, supplier, asset and access registers should be reviewed periodically. Incident, test and change evidence should be generated after every relevant event.
They can help, but system reports, logs, tickets, minutes, data exports and approval evidence are stronger. Screenshots can lose context easily.
Start with applicability assessment, scope, asset register, risk register, requirements map and list of existing evidence. Then build the evidence matrix.
Compliance evidence for DORA, NIS2, KSC and ISO/IEC 27001 should demonstrate an operating security and resilience management system, not only a document set. The auditor will ask about risk, decisions, implementation, tests, incidents, suppliers, continuity and remediation actions.
The best approach is one evidence matrix mapping common artifacts to many requirements. This way, the company does not create four parallel compliance systems, but one coherent evidence model.
The best rule is: do not ask only whether we have a document. Ask whether we can show that the process works, has been tested, is overseen by the board and leads to real security improvement.
Cyber Resilience Act: What Digital Product Manufacturers Must Prepare in 2026 and 2027
The Cyber Resilience Act means that manufacturers of software, hardware and products with digital elements must prepare product security as a process, not as a one-time test. In 2026, the key tasks are vulnerability handling, reporting of actively exploited vulnerabilities and severe incidents, product inventory, product classification, SBOM, update process, reporting contact and evidence. In 2027, manufacturers must complete risk assessment, technical documentation, conformity assessment, user instructions, support period, CE marking and market surveillance readiness.
Prepared by: CCyber Editorial Team
The Cyber Resilience Act, or CRA, changes the approach to digital product security in the European Union. A manufacturer of software, hardware, applications, components or products connected to a network must prepare not only a secure product on the day it is placed on the market, but also a security maintenance process throughout the support period. In 2026, the most important task is to prepare vulnerability handling and reporting of actively exploited vulnerabilities and severe incidents affecting product security. In 2027, manufacturers must complete full readiness: cybersecurity risk assessment, essential requirements, technical documentation, conformity assessment, EU declaration of conformity, CE marking, user instructions, support period, SBOM, security updates and evidence for market surveillance.
July 2026
The Cyber Resilience Act is an EU regulation that introduces horizontal cybersecurity requirements for products with digital elements. Its goal is to reduce the number of vulnerable products on the market, improve transparency for users and require manufacturers to maintain product security throughout the expected period of use.
In practice, CRA means that product security becomes a condition for entering the EU market. A manufacturer should not think only about functionality, sales and UX. It must also show that the product was designed, developed, documented, assessed and maintained according to cybersecurity requirements.
From 11 September 2026, reporting obligations for actively exploited vulnerabilities and severe incidents affecting product security will start applying. This means the manufacturer should already have a working process for detection, qualification, escalation and notification.
From 11 December 2027, the main CRA obligations will apply. New products with digital elements made available on the EU market will need to meet the essential cybersecurity requirements. The manufacturer must have technical documentation, risk assessment, conformity assessment, instructions, support period and declaration of conformity ready.
Companies that start preparation only at the end of 2027 will be late. CRA requires changes in the product, code, architecture, documentation, supplier contracts, update process, vulnerability handling and the way product teams work.
CRA applies to products with digital elements made available on the EU market. This includes final products and separately marketed components. A product with digital elements may be hardware, software or a combination of hardware and software.
This requires careful analysis. CRA applies to products with digital elements, and the definition includes remote data processing solutions if they are designed or developed by the manufacturer or under its responsibility and if their absence would prevent the product from performing one of its functions. Therefore, a SaaS company should check whether it offers a product with digital elements, component, client application, agent, installed software, device or remote data processing solution that is necessary for product functionality.
A software house will not always be the manufacturer under CRA. If it creates custom software and the customer places the product on the market under its own brand, roles must be defined in the contract. If the software house develops and sells a product under its own name or trademark, it may be the manufacturer and should prepare for CRA obligations.
The key role for this article is the manufacturer. This is the entity that develops or manufactures a product with digital elements, or has it designed, developed or manufactured, and markets it under its own name or trademark.
The manufacturer is responsible for product security, risk assessment, requirements, technical documentation, conformity assessment, declaration of conformity, CE marking, support period, updates and vulnerability handling.
The importer places on the EU market a product from a manufacturer outside the EU. It must make sure the product meets the requirements and that the manufacturer has performed the required actions.
The distributor makes a product available on the market without affecting its properties. It must act with due care and check basic conformity elements.
If a company modifies a product, sells it under its own brand, integrates it into a larger solution or makes a substantial modification, it should check whether it assumes manufacturer obligations.
The manufacturer should start with a full list of products with digital elements. Without a register, CRA scope, product class, support period, vulnerabilities, components and documentation cannot be managed.
Evidence to prepare: CRA product register with owners and classification.
Not every product will follow the same conformity assessment path. Many products may use manufacturer self-assessment, but important and critical products may require stricter procedures, including notified body involvement.
Evidence to prepare: product classification card with justification.
This is the most important area for 2026. The manufacturer must know how it receives vulnerability reports, qualifies them, escalates them, fixes them, informs users and reports actively exploited vulnerabilities.
Evidence to prepare: vulnerability handling procedure and vulnerability register.
From 11 September 2026, the manufacturer should be ready to report actively exploited vulnerabilities and severe incidents affecting product security. Roles, escalation path, templates and decisions must be prepared before an incident occurs.
Evidence to prepare: CRA reporting playbook, notification templates and escalation exercise.
CRA requires identifying and documenting vulnerabilities and components contained in products, including preparing a software bill of materials in a commonly used and machine-readable format covering at least top-level dependencies.
Evidence to prepare: SBOM, component policy and dependency vulnerability report.
The manufacturer should show that security is part of product development, not an end-stage test. Secure SDLC should cover security requirements, architecture, code, tests, reviews and updates.
Evidence to prepare: secure SDLC policy, test results and review evidence.
CRA requires effective mechanisms for distributing updates so that vulnerabilities are fixed or mitigated in a timely manner. For many products, security updates should be easy for users, secure and separated from functionality updates where technically feasible.
Evidence to prepare: security update procedure and update process test report.
Every in-scope CRA product should have a cybersecurity risk assessment. The assessment should identify risks, operating environment, users, interfaces, data, foreseeable misuse, vulnerabilities, components and applicable requirements.
Evidence to prepare: product cybersecurity risk assessment.
The manufacturer must show how the product meets the essential cybersecurity requirements in Annex I. In practice, this means the product should be designed without known exploitable vulnerabilities, have secure default settings, limited attack surface, access control, data protection, security updates and vulnerability handling.
Evidence to prepare: CRA requirements matrix with controls, tests and evidence.
Technical documentation will be one of the most important conformity evidence items. It should make it possible to demonstrate that the product meets CRA requirements and that the manufacturer operates product security processes.
Evidence to prepare: complete CRA technical documentation.
The manufacturer must select the right conformity assessment procedure. For many products, self-assessment will be possible. For important or critical products, a stricter procedure or notified body involvement may be required.
Evidence to prepare: conformity assessment path decision and evidence pack.
After a positive conformity assessment, the manufacturer can issue the EU declaration of conformity and mark the product with CE. This is not only a formality. CE means the manufacturer declares that the product meets the applicable requirements.
Evidence to prepare: EU declaration of conformity and CE marking procedure.
CRA requires that users receive information necessary for secure use of the product. This includes contact details for vulnerability reporting, intended purpose, security properties, support period, security updates, secure setup and secure decommissioning.
Evidence to prepare: product security instructions and public support information.
CRA has legal consequences, but implementation is mainly a product, engineering and operational task. Legal analysis alone is not enough without changes in the product development process.
The company does not know which products are in scope, which are components, which are important or critical and which versions are still supported.
From 2026, reporting actively exploited vulnerabilities requires a fast decision path. Without a process, the company may not assess and report on time.
A component list is not enough. The company needs an update process, vulnerability monitoring and mapping between components and product versions.
CRA requires security throughout the product lifecycle. An end-stage test does not replace secure SDLC, threat modeling and dependency control.
The user must know how long security support will be provided. The manufacturer must justify and document it.
If the product is important or critical, the manufacturer may need notified body involvement. This requires time and planning.
Documentation, tests, updates, risk decisions and vulnerability handling must leave a trace. Without evidence, conformity is difficult to demonstrate.
A SaaS company and software house develops an access management product for B2B customers. The product consists of a web application, an agent installed at the customer, API, open source components, login module and cloud integrations. The company initially assumes CRA mainly concerns IoT devices and delays the topic.
After analysis, it turns out that the customer-installed agent and access management product may be products with digital elements in scope of CRA. The company must prepare product register, risk assessment, SBOM, vulnerability reporting process, security update handling, customer instructions and conformity assessment path analysis.
In 2026, the company launches vulnerability contact, CVD, vulnerability register, SBOM and reporting playbook. In 2027, it completes technical documentation, tests, conformity assessment, instructions and CE process. As a result, CRA becomes part of product maturity, not a panic project at the end of 2027.
ccyber.io helps digital product manufacturers prepare for the Cyber Resilience Act in a practical, product-focused and evidence-driven way. We combine regulatory, security engineering, secure SDLC, security testing, SBOM, vulnerability, update and conformity documentation perspectives.
We can support your organization with:
The best first step is a CRA Product Readiness Workshop. In a short workshop, the company can identify which products are in scope, which obligations are urgent in 2026, which conformity path may be needed and what evidence must be prepared before 2027.
No. CRA applies to products with digital elements, meaning many hardware and software products, including applications, components, firmware, network devices, security products, embedded systems and network-connected products.
The most important task is preparing vulnerability handling and reporting of actively exploited vulnerabilities and severe incidents affecting product security.
The most important task is full product readiness: risk assessment, essential requirements, technical documentation, conformity assessment, instructions, support period, CE marking and evidence repository.
No. Many products can use self-assessment. Important or critical products may require stricter procedures and, in certain cases, notified body involvement.
Products placed on the market before 11 December 2027 will generally be subject to the requirements only if they undergo a substantial modification from that date. However, Article 14 reporting obligations apply to in-scope CRA products even if they were placed on the market before that date.
CRA requires preparing an SBOM as part of identifying components and vulnerabilities. Public availability to users is a separate issue. The manufacturer should prepare SBOM and procedures for making it available to relevant parties where required.
The support period should be defined by the manufacturer and generally should be at least 5 years, unless the expected product use period is shorter. It must be clearly indicated to the user and justified in documentation.
Start with the product register, CRA classification, in-scope assessment, vulnerability handling process, SBOM and action roadmap before 11 September 2026 and 11 December 2027.
The Cyber Resilience Act requires digital product manufacturers to move from “we released a product” to “we maintain a secure product throughout the support period”. This means changes in product, engineering, legal, quality and operational processes.
In 2026, the manufacturer should focus on reporting, vulnerability handling, SBOM, updates and secure SDLC foundations. In 2027, it must complete full readiness: risk assessment, requirements, documentation, conformity assessment, declaration of conformity, CE and user information.
The best rule is: do not wait until 2027. A product whose architecture, components, updates and documentation are not prepared today may require far more work than a formal declaration of conformity.
DORA in Practice: What Digital Operational Resilience Means for Financial Firms and ICT Providers
DORA means that financial firms must prove they can operate despite an outage, cyberattack, ICT provider failure or unavailability of a critical system. Digital operational resilience is not only about having technical safeguards. It includes ICT risk management, business continuity, resilience testing, incident reporting, supplier control, ICT contract register, board oversight and operating evidence. For ICT providers, DORA means stronger contractual requirements, audits, information duties, subcontractor controls and, in selected cases, direct oversight as a critical ICT third-party provider.
Prepared by: CCyber Editorial Team
DORA, the Digital Operational Resilience Act, is an EU regulation on digital operational resilience in the financial sector. In practice, it means that banks, insurers, investment firms, payment institutions, crypto-asset service providers and other financial entities must manage ICT risk in a documented, tested and supervised way. A financial firm must know which services and systems are critical, how it responds to incidents, how it restores operations, how it controls ICT providers and how it reports major incidents. For ICT providers, DORA means that financial-sector customers will require more transparency, better contracts, auditability, incident reporting, subcontractor control and resilience evidence.
July 2026
DORA changes how cybersecurity is understood in the financial sector. It is not enough to say that the company has safeguards, policies and an IT provider. The organization must show that it can maintain or restore financial services after a digital disruption.
In practice, DORA requires a financial firm to:
Simply put: DORA requires the financial sector to be resilient not only against a typical cyberattack, but also against provider failure, operational error, cloud unavailability, data center problems, connectivity loss, faulty change, ransomware and other ICT disruptions.
Digital operational resilience is the organization’s ability to maintain, protect, detect, respond, recover and learn after a digital disruption. In the financial sector, the goal is to ensure that an ICT incident does not stop services that are important for customers, markets and financial stability.
This means digital operational resilience is not one tool. It is a system for managing risk, continuity, suppliers and evidence.
DORA applies to a broad catalogue of financial entities operating in the European Union and affects ICT service providers supporting the financial sector. The exact qualification should always be checked against the regulation, implementing acts and positions of competent authorities.
DORA also affects ICT providers, meaning companies delivering information and communication technology services to the financial sector. Not every ICT provider automatically becomes directly supervised by EU authorities. Most providers will feel DORA through contractual requirements from financial-sector customers. Providers designated as critical may be subject to specific European-level oversight.
A financial firm must have an ICT risk management framework. This is not only a document, but an operating process: asset identification, risk assessment, safeguards, monitoring, response, recovery and reporting.
DORA requires management, classification and reporting of major ICT-related incidents to competent authorities. The company must have a procedure, roles, templates, escalation path and response evidence.
DORA requires digital operational resilience testing. Tests should not be limited to one technical test. They should cover procedures, systems, suppliers, recovery and crisis scenarios.
This is one of the most important DORA areas. The financial sector is highly dependent on technology providers. DORA requires these dependencies to be visible, controlled and covered by contracts.
DORA provides for information and intelligence sharing on cyber threats among financial entities. In practice, firms should consider how they use threat information, sector warnings and industry cooperation.
DORA provides specific oversight for ICT providers designated as critical for the financial sector. For such providers, this means higher expectations around risk, controls, transparency and cooperation with oversight authorities.
DORA requires digital operational resilience to become a board topic, not only a technical topic. The board should understand which functions are critical, which ICT risks threaten them, which risk-reducing actions are implemented and which supplier dependencies matter most.
For financial firms, DORA means moving from “we have IT and security” to “we can prove digital operational resilience”. This is a major difference.
ICT providers supporting the financial sector should treat DORA as a significant change in customer expectations. Even if the provider is not directly supervised as a critical ICT third-party provider, its financial-sector customers must demonstrate control over supplier risk.
The distinction between critical or important functions is very important in DORA. These functions indicate which processes, systems and suppliers matter most for the resilience of the financial firm.
One practical DORA requirement is the register of information on ICT provider contracts. This is not a simple supplier list. It is a structured set of data showing which ICT services support the firm, which functions they cover and what risk results from these dependencies.
Evidence to prepare: current ICT contract information register linked to critical or important functions.
DORA means ICT provider contracts must become more precise. This is especially true where the provider supports a critical or important function.
Testing under DORA should answer the question: can the company operate when something goes wrong? This is not only a technical test. It checks people, processes, suppliers, backups, communication and board decisions.
DORA requires the company to identify, classify and report ICT incidents. This must be prepared in advance because during an incident there is no time to create a process from scratch.
The firm has an incident response plan, but no classification and reporting procedure aligned with DORA. During a crisis, people know “something happened”, but do not know whether and how to report.
DORA and NIS2 share a common goal: stronger digital resilience and cybersecurity. Their scope differs. DORA is a specific regulation for the financial sector and ICT risk. NIS2 covers a broad catalogue of critical and important sectors.
If a financial firm is subject to DORA, DORA will be the primary regulation for digital operational resilience. This does not mean other regulations can be ignored, but for ICT risk in the financial sector, DORA is the key reference point.
An ICT provider may simultaneously feel DORA requirements from financial-sector customers and NIS2 requirements if it is itself in scope of NIS2 or serves entities from other regulated sectors. Providers should therefore build one security programme that supports multiple regulations and audits.
ISO 27001 can help significantly with DORA preparation, but it does not replace DORA. ISO 27001 provides an information security management system, risk register, controls, audits, management reviews and corrective actions. DORA adds financial-sector specific requirements, especially around ICT risk, ICT incidents, resilience testing and ICT providers.
First, determine which entities, services, systems, locations, providers and functions are covered by DORA.
Result: DORA scope and critical or important function map.
Compare the current state with DORA requirements. Check not only documents, but also operating evidence.
Result: DORA gap analysis with owners and priorities.
The risk register should connect technology risks with financial services, customers, suppliers and business continuity.
Result: ICT risk register approved by the relevant governance forum.
Prepare classification, escalation and reporting procedures for major ICT incidents.
Result: ICT incident procedure, templates and reporting path test.
Test not only technology, but also people, suppliers, recovery and communication.
Result: test schedule, reports and remediation list.
The register should show the full picture of ICT provider dependencies.
Result: information register ready for reporting and review.
Focus first on providers supporting critical or important functions.
Result: contract update plan, new clauses and risk assessments.
The board should understand DORA, ICT risks, critical functions, suppliers and disruption scenarios.
Result: board training, risk report and budget decisions.
DORA requires evidence. Evidence should be organized and current.
Result: DORA evidence matrix with owners, dates and status.
A mock audit shows whether the firm is truly ready or only has documents.
Result: audit report, gap list and corrective action plan.
DORA requires real resilience and evidence of operation. Documentation without tests, registers and decisions is not enough.
The firm does not know which processes matter most, so it cannot prioritize tests, suppliers and recovery properly.
A supplier list is not enough. The firm must know which provider supports which function and what impact provider failure would have.
This is a major risk, especially for services supporting critical or important functions.
Digital resilience requires testing board decisions, communication, suppliers and emergency-mode operation too.
An incident response plan is not enough if there is no classification, templates and reporting path aligned with DORA.
A provider may deliver a technically good service, but may not be ready for reporting, audits, subcontracting and evidence required by financial-sector customers.
The board sees IT projects, but not real resilience: tests, RTO, RPO, critical providers, incidents and overdue risks.
A financial firm uses several key ICT services: cloud, transaction system, customer service system, SOC service, backup and an external software provider. Before DORA, it treated these contracts mainly as procurement and IT topics. After analysis, the firm discovers that some providers support critical or important functions, while contracts lack clear rules on audit, incident reporting, subcontracting and exit plans.
The firm launches a DORA programme. It creates a critical function map, ICT risk register, ICT contract information register and testing plan. It performs a restore test, major ICT incident exercise and supplier review. The board receives the first report with resilience metrics, and providers receive requirements for contract annexes.
The biggest change is not creating a new policy. The biggest change is that the firm starts seeing technology dependencies as business risk and can show evidence of resilience.
ccyber.io helps financial firms and ICT providers prepare for DORA in a practical, risk-based and evidence-driven way. We do not start from documentation for documentation. We start from critical functions, suppliers, incidents, tests, the board and the real ability to operate after disruption.
We can support your organization with:
The best first step is a DORA Operational Resilience Workshop. In a short workshop, the company can determine which functions are critical, which providers matter most, which contracts need changes, which tests must be performed and which evidence should be prepared before audit.
DORA is an EU regulation on digital operational resilience in the financial sector. It covers ICT risk management, incidents, resilience testing, ICT providers and oversight of critical ICT third-party providers.
DORA applies from 17 January 2025. Financial firms should already operate under its requirements and maintain readiness evidence.
Yes, but in different ways. Most ICT providers experience DORA through requirements from financial-sector customers in contracts, audits and reporting. Critical ICT providers may be subject to specific oversight.
It is the ability of a firm to maintain or restore services despite an ICT incident, outage, cyberattack, provider failure or technology disruption.
Critical or important functions, ICT risk, incidents, resilience testing, ICT providers, information register and operating evidence.
Not automatically. ISO 27001 helps significantly, but DORA has sector-specific requirements for ICT incidents, resilience testing, ICT providers, information register and board oversight.
Service description, responsibility boundaries, security evidence, incident procedure, continuity plan, recovery tests, subcontractor list, audit rules and exit plan.
Start with the critical or important function map, ICT risk register, ICT supplier register and contract review for providers supporting the most important services.
In practice, DORA means moving from IT protection to digital operational resilience of the entire financial organization. The firm must know which services are critical, which systems support them, which providers are essential, how backups work, how incidents are reported and whether the board sees the real risk level.
For financial firms, DORA means ICT risk management, resilience testing, incident reporting, provider control and evidence. For ICT providers, it means more transparency, stronger contracts, audits, reporting, subcontractor control and the need to show that the service is resilient.
The best rule is: digital resilience cannot be proven by a policy alone. You need tests, reports, metrics, board decisions, supplier registers and evidence that the firm can operate despite disruption.
We write about regulations such as NIS2, DORA, CRA and ISO 27001, cybersecurity for SMEs and critical infrastructure, as well as cyber hygiene, emerging threats and building security awareness within organisations.
Every article delivers practical knowledge - no jargon, just concrete steps you can act on to effectively protect your data, people and business continuity.