Our blog features practical articles on cybersecurity and regulations, written in plain language that business owners and managers can understand. We cover specific topics such as NIS2, DORA and CRA requirements, ISO 27001 implementations, incident analysis, phishing, ransomware and best practices for SMEs.
Instead of technical jargon we offer actionable guidance that can be applied to your business straight away. We focus on content you can implement immediately: checklists, threat analyses, SME guides and regular updates on new regulations.
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.
How to Get Cheaper Cyber Insurance? Implement These Controls Now
Cheaper cyber insurance does not come from simply declaring that the company “cares about security”. Insurers look at real controls, incident history, industry, revenue, data, suppliers and the company’s ability to recover after an attack. The biggest impact on insurability and policy terms usually comes from MFA, tested backup, EDR, updates, administrator account control, secure remote access, email protection, training, payment procedures, incident response plan, BCP, supplier control and an evidence pack. There is no guaranteed premium reduction, but well-documented safeguards can help obtain better terms, higher limits, fewer exclusions or smoother renewal.
Prepared by: CCyber Editorial Team
To increase the chance of cheaper cyber insurance, a company should improve what insurers see as the biggest risk sources: no MFA, untested backup, weak endpoint protection, outdated systems, excessive administrator rights, uncontrolled remote access, weak email protection, no training, no payment procedure, no incident response plan and no evidence. A lower premium cannot be guaranteed because pricing depends on industry, revenue, claims history, coverage scope, limits and the insurance market. However, a company can improve its insurability and position in discussions with a broker and insurer. The key point is not to declare safeguards by word alone. Every questionnaire answer should have scope, owner and evidence.
July 2026
Yes, but the word “cheaper” must be understood correctly. The insurer does not sell a discount for a tool name. The insurer assesses risk. If the company can show that it reduced incident likelihood and can limit impact, it may have a better position when discussing premium, limits, exclusions and renewal.
Better preparation may help with:
Important: cyber insurance is not a reward for having tools. It is a mechanism for transferring part of the risk. The company still needs to manage risk, maintain safeguards and update information provided to the broker and insurer.
The insurer wants to answer a simple question: how likely is this company to have an expensive incident and how large could that cost be?
You cannot change all factors. You cannot easily change the industry or incident history. But you can improve safeguards, prepare evidence, organize processes and show that the company has real control over cyber risk.
If a broker or insurer asks whether the company has MFA, backup, EDR and training, “yes” is too weak. The company must show exactly where the control works, who is covered, which exceptions exist and when it was last checked.
Weak: “We have backup”.
Strong: “Backup covers Microsoft 365, file server, finance system and CRM. Copies are separated from production. The latest restore test was performed on 12 June 2026. The test result and remediation actions are in the report.”
MFA is one of the most important controls from the insurer perspective. It protects against account takeover after password theft, phishing or credential leaks.
Evidence for the insurer: MFA report, list of covered accounts, exception list and risk acceptance decisions.
Backup without testing is a promise, not evidence. The insurer wants to know whether the company can recover after ransomware, failure, human error or data loss.
Evidence for the insurer: backup report, restore test report, RTO, RPO and remediation list.
The insurer will ask whether laptops, servers and workstations are protected. Antivirus alone may not be enough if nobody monitors alerts or if protection does not cover all devices.
Evidence for the insurer: EDR or antivirus coverage report, exception list, alert report and response procedure.
Unpatched systems, VPNs, firewalls, servers and internet-facing applications are common entry points. The insurer may ask how quickly the company patches critical vulnerabilities.
Evidence for the insurer: vulnerability report, patch management report and overdue vulnerability list.
Administrator accounts are a shortcut to the whole company for an attacker. Insurers pay close attention to MFA, number of administrators, named accounts and access reviews.
Evidence for the insurer: administrator account report, PIM or PAM report, access review and list of removed permissions.
Remote access is convenient, but it is also one of the most important risk points. Public RDP, old VPNs, supplier accounts without MFA and permanent service access are especially dangerous.
Evidence for the insurer: remote access model description, MFA report, supplier access list and session logs.
Email is often where fraud, account takeover and fake payment attempts begin. The insurer may ask about MFA, filtering, SPF, DKIM, DMARC and training.
Evidence for the insurer: email configuration report, SPF/DKIM/DMARC status, training report and phishing report register.
Training should not be one annual presentation. From the insurer perspective, it matters more whether the company teaches employees to recognize phishing, report mistakes, use MFA and verify payments.
Evidence for the insurer: training plan, participant list, materials, test results and reporting metrics.
Business email compromise and fake payments may not be covered by a standard policy or may have sublimits. Regardless of coverage, the company should reduce fake payment risk.
Evidence for the insurer: payment procedure, second-channel confirmation register and finance training report.
The policy may provide access to experts, but the company still needs to know what to do in the first hour of an incident. The response plan should be short, current and exercised.
Evidence for the insurer: incident response plan, contact list, tabletop report and remediation action list.
Cyber insurance may cover downtime costs, but the insurer will want to know whether the company can limit downtime and operate in emergency mode.
Evidence for the insurer: BCP, DRP, restore test report, downtime cost analysis and board decisions.
If the company does not know which systems and data it has, it cannot answer insurer questions well. Inventory is the foundation for risk and coverage scope.
Evidence for the insurer: asset register, critical system map and data classification.
An incident at an IT, cloud, hosting, backup or finance system provider can stop the company. The insurer may ask whether the company manages third-party risk.
Evidence for the insurer: supplier register, risk assessments, security clauses and list of suppliers with access.
After an incident, the company must reconstruct what happened. Missing logs make response, investigation, notifications and claims handling harder.
Evidence for the insurer: log source report, SIEM or log management configuration, sample alerts and retention policy.
The best safeguards will not help much in a broker conversation if the company has no evidence. An evidence pack shortens discussions, reduces ambiguity and supports renewal.
Evidence for the insurer: organized evidence repository with dates, owners and freshness status.
Every insurer has its own assessment model, but in practice the strongest weight often goes to controls that reduce ransomware, account takeover and downtime.
“We have MFA” is risky if MFA does not cover administrators, VPN or suppliers.
Exceptions are normal, but they must be known, documented and accepted. A hidden exception may become a problem after an incident.
The company may have EDR, but nobody responds to alerts. It may have backup, but nobody tests it. It may have an incident plan, but nobody knows it.
The insurance questionnaire should be reviewed by IT, security, the board, finance, legal and process owners.
A cheaper policy with large exclusions may not protect against the scenario most realistic for the company.
The broker can compare offers, but if company risk is high, price competition has limited value.
Backup marked as “working” in a questionnaire without a restore test is weak evidence.
MFA on standard accounts is not enough if administrators, VPN, suppliers and the finance system are excluded.
The IT provider knows part of the technology, but usually does not know the full picture of data, finance, incident history, suppliers and board decisions.
Fake payments may be excluded or limited. A second-channel procedure is inexpensive and very important.
Training without participant lists, programme and test results is hard to show in an audit.
The company changes cloud, supplier, system or data scope, but does not update broker and insurer information.
The key question is not only “how much does the policy cost”, but what it actually covers and excludes.
A services company has 70 employees and wants to buy cyber insurance. The first offer is expensive, and the broker points to questionnaire issues: MFA works only in Microsoft 365, backup has not been tested for a year, there is no formal incident response plan, EDR does not cover all devices and no payment procedure exists.
The company does not immediately look for another cheaper offer. First, it closes key gaps over 60 days. It enables MFA for administrators and VPN, performs a restore test, completes EDR coverage, prepares an incident response plan, trains employees, implements second-channel verification for bank account changes and collects evidence.
After the questionnaire update, the broker has stronger material for discussions with insurers. The company is not guaranteed the lowest premium, but it gains a better negotiation position, less ambiguity and a greater chance of a policy that matches real risk scenarios.
ccyber.io helps SMEs prepare for cyber insurance in a practical, risk-based and evidence-driven way. We do not promise an automatic premium reduction because the decision belongs to the insurer. We help improve insurability, close key gaps and prepare an evidence pack for the broker.
We can support your organization with:
The best first step is a Cyber Insurance Cost Reduction Readiness Workshop. In a short workshop, the company can check which safeguards are already implemented, where evidence is missing, which gaps most affect broker discussions and what should be done before sending the questionnaire.
There is no guarantee, but MFA is one of the most important controls assessed by insurers. Missing MFA may make it harder to obtain good terms.
Not backup alone. Restore testing, separated copies, backup account protection and critical service recovery planning are important.
It depends on the insurer, industry and company size. In practice, endpoint protection, alert monitoring and incident response are very commonly assessed.
It may help as evidence of maturity, but the insurer may still ask about specific controls such as MFA, backup, EDR, incident response and suppliers.
Yes, through a broker the company can discuss coverage, limits, exclusions, sublimits and requirements. Better security evidence may make that discussion easier.
No. A cheaper policy may have lower limits, higher deductible, more exclusions or missing coverage for important scenarios such as BEC or supplier incidents.
Do not hide them. Describe the actual state, scope, remediation plan and deadlines. A “partially implemented” answer with evidence is better than an unsupported declaration.
Start with MFA, backup testing, endpoint protection, administrator review, secure remote access, incident response plan and evidence pack for the broker.
Cheaper cyber insurance does not start with price negotiation, but with reducing real risk. The insurer will look at whether the company has basic safeguards and whether it can prove them.
The most important solutions are MFA, tested backup, EDR, updates, administrator control, secure remote access, email protection, training, payment procedure, incident response, BCP, supplier control, logs and evidence repository.
The best rule is: do not try to buy a cheaper policy based on wishful answers. Implement basic controls, test them, collect evidence and only then discuss terms with your broker.
Third-Party Risk Management: How to Assess Suppliers Under NIS2 and DORA
Third-party risk management under NIS2 and DORA is not about sending one annual questionnaire to a supplier. A company must know which suppliers are critical, which data and systems they handle, whether they have privileged access, whether they support critical or important functions, where they process data, which subcontractors they use, how they report incidents, how they test continuity and whether the company can safely exit the relationship. The best model is a supplier lifecycle: classification, due diligence, risk assessment, contractual requirements, onboarding, monitoring, testing, incident response, review and exit plan.
Prepared by: CCyber Editorial Team
Third-party risk management under NIS2 and DORA should start with a supplier map, not a questionnaire. The company must know which suppliers support critical services, have access to data, have administrator accounts, maintain systems, provide cloud, software, monitoring, backup, OT, SOC, MDR or business processes. NIS2 requires supply chain security and supplier relationships to be included in cyber risk management. DORA goes further for the financial sector and requires formal ICT third-party risk management, register of information, assessment of services supporting critical or important functions, due diligence, monitoring, contractual clauses, subcontractor controls, audit rights and exit plans. Good supplier assessment is a process across the whole relationship lifecycle, not a one-time form.
July 2026
Third-party risk is the risk a company takes through relationships with suppliers, service providers, partners, subcontractors, integrators, group entities or external tools. In cybersecurity, it means that a supplier incident can become the company’s incident.
NIS2 covers a broad set of sectors and essential or important entities. In the supplier context, the key point is that supply chain security and supplier relationships must be included in cyber risk management measures. This means the organization must know which suppliers matter, what risks they create and which safeguards are required.
DORA is a financial sector regulation focused on ICT risk. It is more detailed in supplier management. It requires a register of information on ICT contracts, ICT third-party risk strategy, assessment of critical or important functions, due diligence, monitoring, audit rights, contractual requirements, subcontractor controls, concentration risk assessment and exit strategies.
NIS2 says: manage supplier risk as part of cybersecurity. DORA says: show exactly which ICT suppliers support critical or important functions, which contracts apply, where data is located, who the subcontractors are, what audit rights you have, how you monitor risk and how you can exit without losing resilience.
The best starting point is a simple supplier map. Without it, the company does not know who to assess, how deeply and against which requirements.
Not every supplier can be assessed the same way. A coffee supplier, ERP provider and backup provider do not create the same risk. Classification allows the company to choose the right level of due diligence.
The supplier supports a critical service, critical or important function, production, payments, customer data, security, backup, cloud or a system whose failure seriously affects the company.
The supplier does not stop the whole company, but has access to sensitive data, privileged accounts, customer systems, production environment or important integrations.
The supplier processes limited data or supports a less critical process, but still requires basic assessment and contractual requirements.
The supplier has no access to data, systems or critical processes. Light assessment, basic contractual language and periodic review are enough.
Before procurement or contract signature, the company should assess whether the supplier can be allowed for the intended type of data or service.
At this stage, the company collects information about safeguards, certifications, processes, subcontractors, continuity, incidents and supplier compliance.
This is not only a list of answers. Impact, likelihood, gaps, exceptions, residual risk and business decision must be assessed.
Security requirements should be included in the contract, annex, SLA, DPA, service terms or security schedule. A questionnaire without contract terms has limited value.
The supplier should receive only the access it needs. The owner, contacts, incident path and operating requirements must be defined.
Supplier risk changes. Incidents, audit results, SLA, subcontractor changes, vulnerabilities, data location and service changes must be monitored.
Critical suppliers require regular review. Frequency should depend on risk.
The company must know how it will leave the supplier, recover data, switch the process, remove access and maintain business continuity.
First determine whether the supplier affects a service that may be subject to NIS2 requirements. The real impact matters, not only the supplier’s formal label.
NIS2 focuses in part on relationships with direct suppliers. The company should understand their vulnerabilities, quality of cybersecurity practices and secure development approach.
The supplier should meet requirements appropriate to risk. Requirements will differ for a cleaning company, SOC provider and software house maintaining a customer application.
If an incident at the supplier may affect your service, customer or regulatory reporting timeline, the contract must define timing, channel and notification content.
A supplier whose failure can stop your company should show continuity plans, recovery tests and crisis communication process.
For NIS2 audit purposes, the company should keep evidence: supplier register, risk assessments, contractual requirements, reviews and remediation plan.
DORA concerns ICT services provided by third parties. Identify which contracts concern ICT services, which are outside the scope and which support critical or important functions.
The register of information is a key evidence item for ICT supplier management under DORA. It should include contracts, services, functions, suppliers, subcontractors, locations, identifiers, links and service assessment.
DORA places the strongest focus on services supporting critical or important functions. These require the most detailed assessment, contracts, monitoring, testing, audit rights and exit plans.
Before signing an ICT supplier contract, the company should assess risks, supplier capability, security, resources, subcontractors, data location, continuity and concentration risk.
Contracts should describe the service, SLA, data location, security, incidents, cooperation with authorities, audits, subcontracting, business continuity, testing and exit.
If the ICT supplier uses subcontractors for services supporting critical or important functions, the company must understand the subcontracting chain, location risk, concentration, audit rights and ability to object to material changes.
DORA does not end at due diligence. The supplier must be monitored, and risks, SLA, incidents, changes, subcontractors and tests should be reviewed regularly.
A questionnaire is only the start. Answers must be evaluated, documented and linked to a risk decision.
The same form for a critical supplier and low-risk supplier leads to fatigue, weak answers and no real decisions.
The company does not know how many suppliers it has, which contracts are ICT and who supports critical processes.
The best time for due diligence is before the contract. After signing, negotiating requirements becomes harder.
The supplier may be secure, but risk may come from its subcontractor, data location or downstream service chain.
The company knows how to buy the service, but not how to recover data, switch the process and remove access after the relationship ends.
Without audit rights or alternative assurance, the company must rely only on supplier declarations.
The supplier may have an incident, but the customer may learn about it too late to meet its own regulatory duties.
IT or procurement collects questionnaires, but nobody in the business owns supplier risk.
A financial company uses 180 suppliers, including 45 ICT suppliers. Initially, it keeps one procurement spreadsheet. There is no clear distinction between services supporting critical or important functions. Some supplier contracts lack audit, subcontractor, incident and exit plan clauses.
After analysis, the company creates a DORA register of information, classifies suppliers by criticality, identifies 12 ICT services supporting critical functions, assesses subcontractors and prepares security annexes. In parallel, it implements a process for assessing new suppliers before contract signature.
After 90 days, the board sees the real dependency map for the first time: which suppliers are critical, where data is located, where audit rights are missing, where concentration risk exists and which exit plans must be prepared first.
ccyber.io helps companies build practical third-party risk management programmes for NIS2, DORA, ISO 27001, cyber insurance and customer requirements. We combine cybersecurity, regulatory, procurement, legal, data and business continuity perspectives.
We can support your organization with:
The best first step is a TPRM and Supplier Risk Workshop. In a short workshop, the company can identify the most important suppliers, NIS2 or DORA requirements, contractual gaps and actions needed before audit or inspection.
Yes. NIS2 includes supply chain security and supplier relationships as part of cyber risk management measures. Control scope should depend on supplier risk and importance.
No. DORA applies to ICT services provided by third parties. Cloud is an important example, but SaaS, hosting, business systems, SOC, backup, IT outsourcing and other ICT services may also be in scope.
It is a function whose disruption could significantly affect business continuity, customers, regulatory duties or operational stability of a financial entity.
No. A questionnaire must lead to risk assessment, decision, contractual requirements, remediation actions and monitoring. A supplier answer without evidence is weak.
Supplier register, criticality classification, risk assessment, contract with security clauses, test reports, continuity plan, incident procedure, subcontractor list and exit plan.
Alternative assurance may be considered, such as certifications, independent reports, SOC 2, ISO 27001, security test reports, security documentation or independent third-party audit. For critical suppliers, refusal must be assessed as risk.
Critical suppliers should be reviewed at least annually and after every material change. Medium and low-risk suppliers can be reviewed less often according to classification.
Start with a supplier register, criticality classification, ICT supplier identification, contract review and assessment of the top 10 suppliers.
Third-party risk management under NIS2 and DORA requires visibility, classification, due diligence, contracts, monitoring and evidence. Supplier risk cannot be managed if the company does not know who has access to data, who supports critical services and who uses downstream subcontractors.
NIS2 requires suppliers to be included in cyber risk management. DORA requires a more detailed system for ICT suppliers in the financial sector: register of information, assessment of critical or important functions, subcontractor control, audit rights, monitoring and exit plans.
The best rule is: do not ask only whether the supplier has a certificate. Ask how supplier failure would affect your company, which data it processes, who has access, who its subcontractors are, how it will report an incident and whether you can safely exit the relationship.
How to Prepare an Audit Trail for Privileged Access?
An audit trail for privileged access is not just a system log. It is a complete evidence chain showing who had privileges, who approved them, when they were activated, for what reason, from which device, what actions were performed, whether the session was monitored, whether access was removed and whether logs are protected from modification. A good audit trail connects IAM, PAM, PIM, SIEM, system logs, cloud logs, ticketing, access reviews, session recordings and business owner decisions. The key question is: after an incident, can we reconstruct the full history of privileged account use?
Prepared by: CCyber Editorial Team
An audit trail for privileged access should answer six questions: who had access, who approved it, when it was used, why it was used, what was done and whether access was later removed. The information that “an administrator logged in” is not enough. Data from IAM, PAM, PIM, ticketing, SIEM, cloud logs, system logs, application logs, session recordings and access reviews must be connected. A good audit trail covers the full access lifecycle: granting, activation, approval, use, actions during the session, configuration changes, data downloads, session end, permission expiration, review and any remediation actions.
July 2026
An audit trail is an evidence chain. In the context of privileged access, it shows how a permission was created, who approved it, when it was used, what actions were performed and whether the whole process followed company rules.
Privileged access includes accounts, roles and permissions that can change configuration, grant rights to others, read sensitive data, delete data, disable safeguards, manage cloud environments, run commands on servers or affect business continuity.
The audit trail should prove that this access was granted intentionally, used for an approved purpose, monitored and later reduced or removed.
A privileged account can change everything. It can add a user, disable MFA, change an access policy, delete backup, download data, expose a resource publicly, disable logging or grant access to an attacker. This is why after an incident the key question is: what did the privileged account do?
Without an audit trail, the company often knows only that “something happened”. It does not know who made the change, whether they had the right to do it, whether the action was part of a plan or a sign of an attack.
Login logs are part of an audit trail, but not the whole audit trail. A single log saying “user X logged in at 10:14” is not enough. An auditor, customer or incident response team will ask much more.
Every privileged access should have a reason. It may be a service ticket, change request, failure, deployment, incident or scheduled administrative window.
Privileged access should not result only from the administrator’s own decision. It should be approved by the right person: system owner, manager, security, process owner or on-call approver in emergency mode.
Best practice is just-in-time access. The user is eligible, meaning they can activate a role after meeting conditions, but they do not have permanent active access.
The audit trail should show context. This helps distinguish normal administrator work from suspicious activity.
The most important point is what the administrator did after receiving privileges. A login without action logs is weak evidence.
For high-risk actions, it is useful to have a session recording, command log or full action record in PAM. This especially applies to suppliers, critical system administrators and jump server sessions.
The audit trail should show that access was not left permanently. If it was time-bound, it should expire. If it was emergency access, it should be formally closed.
The best audit trail does not end with logs. It should be periodically reviewed. Someone must check whether roles are still needed and whether privileged access was used according to rules.
Every privileged access event should contain a set of fields that allow it to be connected with a person, process and action.
If logs are stored only on the system managed by the administrator, they may be changed or deleted by the same person or by an attacker using that person’s privileges.
The auditor sees role activation, but not why it was needed. Without a ticket, it is hard to distinguish planned change from abuse.
Administrator login is visible, but the changes performed are not. This is not enough to explain an incident.
An “admin”, “root”, “service” or “vendor” account makes accountability difficult. After an incident, the company does not know which person used the account.
Service accounts, service principals, managed identities and API keys often have broad privileges while being poorly monitored.
Logs are collected, but nobody reads them. The company learns about the problem only after the incident.
An incident may be detected after weeks or months. If logs are stored only for 7 or 30 days, the company may lose the ability to reconstruct events.
The worst scenario is an administrator or attacker using that account being able to disable logging or delete logs.
The company should have a clear definition. Without it, some people treat only global admin accounts as privileged, while others also include service accounts, subscription owners, application administrators and suppliers.
You cannot audit what you cannot see. The register should include people, suppliers, technical accounts, applications and cloud roles.
For every system, define where logs come from: IAM, PAM, PIM, operating system, application, cloud, database, ticketing and SIEM.
Every high-risk activation should have justification and a ticket number. This supports audit and incident analysis.
Standing privileged access increases risk. Time-bound access creates a better audit trail because it enforces an activation moment, justification and often approval.
Logs must resist modification and deletion. Access to logs should be restricted, and logging configuration changes should generate alerts.
An audit trail should not be only an archive. It should support detection of events requiring response.
The audit trail shows who uses permissions. Access review shows whether they should still have them.
There is no universal answer. Retention depends on risk, regulations, contracts, industry, storage cost and incident detection time. For privileged access, longer retention than standard diagnostic logs is often appropriate.
Retention should be formally approved. The company should know which logs are needed for audit, which for incident response and which for customer requirements.
The best way is a reconstruction exercise. Choose one administrator account, one role activation or one change ticket and check whether you can rebuild the full trail.
Break glass accounts are necessary, but very risky. They are meant to allow emergency access when standard mechanisms fail. However, they cannot sit outside the audit trail.
IT providers, MSPs and integrators often have privileged access to customer environments. This requires special accountability. A supplier account should not be a black box.
A SaaS company uses Microsoft Entra ID, Azure, GitHub, CI/CD system, database and customer support tool. It has several administrators and an external DevOps provider. The board assumes the audit trail works because “we have cloud logs”.
During a mock audit, it turns out administrator sign-ins are visible, but not all actions are linked to tickets. Roles are permanently active. The supplier uses one shared account. PIM logs have short retention. Session recordings do not exist. Access review has not been done for nine months.
The company implements PIM for critical roles, requires MFA and activation justification, adds ticket numbers, moves logs to a central SIEM, introduces named accounts for the supplier and performs the first access review. After 90 days, the company can show a full trail: request, approval, activation, actions, logs and access removal.
ccyber.io helps companies prepare audit trails for privileged access in cloud, hybrid and SaaS environments. We combine IAM, PAM, PIM, SIEM, compliance, audit and incident response perspectives.
We can support your organization with:
The best first step is a Privileged Access Audit Trail Workshop. In a short workshop, the company can define which accounts matter most, which logs already exist, where evidence gaps are and whether the company can reconstruct administrator account use history.
No. Logs are part of the audit trail. The audit trail also includes access request, approval, justification, activation, actions, session, access expiration, review and process evidence.
The most important thing is connecting person, permission, purpose, approval and actions performed. The auditor should see the full history, not a single login log.
Not always, but recording is valuable for critical systems, suppliers, break glass accounts and high-risk actions.
It depends on risk, regulations and contracts. In practice, privileged access logs are often worth retaining for at least 12 months, and longer for critical systems if audits or contracts require it.
PIM helps significantly because it provides activation, justification, approval and history. But it is not enough alone if you do not collect action logs from target systems and do not link activation with tickets.
You need a register, owner, permission scope, usage monitoring, secret rotation, alerts for unusual use and regular review of unused accounts and keys.
Start with a critical role register, MFA for administrators, centralized logs, ticket requirement during activation and a reconstruction test of one administrator’s activity history.
Select one high-risk change and try to reconstruct the full history: request, approval, activation, MFA, actions, logs, completion and review. Gaps will show what must be improved.
An audit trail for privileged access is one of the most important elements of identity and cloud control. Without it, the company does not know who truly had power over systems, what they did and whether the action was authorized.
A good audit trail connects IAM, PAM, PIM, SIEM, cloud logs, system logs, ticketing, session recordings, access reviews and owner decisions. It creates the most value when logs are complete, centralized, protected from modification and reconstructable after an incident.
The best rule is: do not ask only whether we have logs. Ask whether after an incident we can prove who requested access, who approved it, when it was used, what exactly was done and whether access was removed.
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.