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.
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.
NIS2 vs ISO 27001: How to Combine Requirements into One Practical Plan
NIS2 and ISO 27001 should not be treated as two separate projects. NIS2 defines regulatory duties: cyber risk management, incident reporting, board oversight, supplier security and business continuity. ISO 27001 provides a management system that helps organize these duties: scope, risks, Statement of Applicability, controls, audits, management reviews and corrective actions. The best approach is one requirements map, one risk register, one action roadmap and one evidence repository.
Prepared by: CCyber Editorial Team
NIS2 and ISO 27001 are best combined into one practical plan instead of being managed as two parallel projects. NIS2 defines the regulatory duties a company must meet: cyber risk management, technical and organizational measures, incident reporting, board oversight, supplier security, business continuity and compliance evidence. ISO 27001 provides the management approach: scope, information security policy, risk assessment, risk treatment plan, Statement of Applicability, internal audits, management reviews and corrective actions. A shared plan should have one applicability assessment, one risk register, one control map, one roadmap, one evidence matrix and one board report.
July 2026
NIS2 and ISO 27001 are often discussed together, but they are not the same. The simplest distinction is: NIS2 says that certain organizations must meet cybersecurity requirements under law. ISO 27001 says how to build an information security management system that manages risk in an organized, auditable and repeatable way.
The best approach is not “NIS2 or ISO 27001”. The better question is how to use ISO 27001 as a management system that helps meet and prove NIS2 requirements.
Not automatically. An ISO 27001 certificate may be strong evidence of organizational maturity, but it does not by itself mean full NIS2 compliance. The reasons are simple.
The company still needs to check whether it is subject to NIS2, in which country, in which sector, in which role and whether it is essential or important.
NIS2 implementation details come from national law. In Poland, current rules connected with the national cybersecurity system must be checked.
NIS2 has specific incident reporting requirements. The company needs a procedure and templates for the first hours of an incident.
A certificate may cover only part of the organization. If the ISO 27001 scope does not include critical services, regulated systems or suppliers relevant to NIS2, it must be expanded or supplemented with separate mapping.
It provides the most value when it covers real risks, current assets, suppliers, incidents, tests, audits and corrective actions. A certificate without current evidence may not be enough in a NIS2 audit.
The best model is a layered approach: NIS2 as the regulatory duty layer, ISO 27001 as the management system layer, ISO 27002 as the control layer and evidence as the audit layer.
The most important practical tool is the requirements map. It is a table showing which NIS2 requirement is supported by which ISO 27001 element, which control the company uses and which evidence confirms operation.
NIS2 area: incident handling.
ISO 27001 element: planning, operation, performance evaluation, corrective action.
Controls: incident response procedure, logs, roles, escalation, exercise.
Evidence: response plan, tabletop report, incident register, remediation action list.
NIS2 requires an answer on whether the company is in scope. ISO 27001 requires defining the scope of the information security management system. These two activities should be combined.
Evidence: applicability assessment, management system scope, critical service map, board decision.
NIS2 emphasizes management accountability for approving and overseeing cyber risk management measures. ISO 27001 requires leadership, roles, responsibilities and management review.
Evidence: board minutes, risk reports, budget decisions, management review.
This is the shared core of NIS2 and ISO 27001. Without a risk register, the company cannot show why selected controls are adequate and proportionate.
Evidence: risk methodology, risk register, risk treatment plan, risk acceptance decisions.
The ISO 27001 Statement of Applicability can become the main NIS2 control map if extended with regulatory requirements.
Evidence: Statement of Applicability, NIS2 map, control list, implementation status.
ISO 27001 organizes incident management. NIS2 adds specific duties to report significant incidents within short timelines.
Evidence: incident procedure, notification templates, exercise report, incident register.
NIS2 requires business continuity and recovery after incidents. ISO 27001 helps embed this into management, testing and audits.
Evidence: business continuity plan, backup report, restore test report, action list after test.
NIS2 strongly emphasizes supplier risk. ISO 27001 and ISO 27002 help organize supplier relationships, contractual requirements and reviews.
Evidence: supplier register, risk assessments, contracts, supplier access review, exit plan.
Access control is one of the most important areas for NIS2 and ISO 27001. A compromised administrator account can undermine the whole security programme.
Evidence: MFA report, administrator list, access review report, offboarding checklists.
NIS2 refers to vulnerability handling and security in acquisition, development and maintenance of systems. ISO 27001 helps embed these actions into risk, change and evidence processes.
Evidence: vulnerability report, remediation list, retest, risk acceptances.
NIS2 requires awareness and board accountability. ISO 27001 requires competence, awareness, internal audits, management reviews and corrective actions.
Evidence: training plan, participant lists, internal audits, management review, corrective action register.
Determine whether the company is subject to NIS2, in which sector, role and country. In Poland, check current national rules connected with KSC.
Result: applicability report and board decision.
Determine whether the current or planned ISO 27001 scope covers all services, systems, locations and suppliers relevant to NIS2.
Result: management system scope and critical services map.
Compare NIS2 requirements with the current ISO 27001 status, controls, procedures and evidence.
Result: gap analysis with priorities.
Build one shared cyber risk register. Do not create one register for NIS2 and another for ISO 27001.
Result: risk register with owners, impact, controls and action plan.
Add columns to the Statement of Applicability: NIS2 requirement, owner, evidence, status, gap and remediation action.
Result: Statement of Applicability as NIS2 and ISO 27001 control map.
Define actions for 30, 60, 90 days and 12 months. Prioritize gaps that reduce the highest risk and matter most for audit.
Result: roadmap with deadlines, owners and budget.
Complete key procedures: incidents, reporting, backup, access, suppliers, vulnerabilities, training and corrective actions.
Result: procedure set used in practice.
Run restore test, incident exercise, access review and reporting path test.
Result: test reports, gap list and remediation actions.
Assess critical suppliers, add security requirements to contracts and review supplier access.
Result: supplier register, risk assessments and improvement plan.
Train the board and employees. Training should focus not only on knowledge, but also decisions and behaviors.
Result: materials, participant list and test results.
Build one evidence repository for NIS2, ISO 27001, KSC, customer audits and cyber insurance.
Result: evidence matrix with dates, owners and status.
Run internal audit, close nonconformities and prepare management review covering both ISO 27001 and NIS2.
Result: audit report, corrective action register and management review record.
The biggest mistake is creating two separate libraries: one for NIS2 and one for ISO 27001. This increases chaos, cost and inconsistency risk.
Do not create a new document if an existing document can be extended with scope, owner, evidence and requirement mapping.
The evidence matrix shows whether the company can prove controls are operating. This is especially important because NIS2 and ISO 27001 require not only declarations, but also repeatability, supervision and improvement.
One person runs NIS2, another runs ISO 27001, while documents, risks and evidence are not connected. The result is duplication, inconsistency and organizational fatigue.
ISO 27001 helps, but does not replace applicability assessment, national duties, incident reporting timelines and sector requirements.
The control table looks good, but the company cannot show an MFA report, restore test, access review or incident exercise.
The certificate covers headquarters or a selected process, but NIS2 concerns a service, system, company or supplier outside scope.
The company has an incident response procedure, but no templates and path for NIS2 duties: early warning, notification and final report.
Documentation is created by IT or compliance, but the board does not approve risks, budget, exceptions and priorities.
ISO and NIS2 both require supplier relationship controls, but the company has no critical supplier register or risk assessment.
The company checks ISO 27001 separately, but does not test whether the same evidence system answers NIS2 requirements.
A SaaS company has ISO 27001 certification for its platform and technical team. After NIS2 requirements begin affecting customers, clients start asking about incident reporting, suppliers, business continuity, vulnerabilities and board accountability. The company initially treats NIS2 as a separate legal project.
After analysis, it turns out most elements already exist in the ISO 27001 system, but there is no NIS2 mapping, no 24 and 72-hour notification templates, no formal assessment of several suppliers, no board training evidence and no readiness report. The company does not create a second documentation library. It extends the Statement of Applicability, updates the risk register, adds an evidence matrix and includes NIS2 in management review.
After 90 days, the company has one shared plan: NIS2 as the requirement layer, ISO 27001 as the management system, ISO 27002 as the control catalogue and one evidence repository. Customers receive consistent answers, and the board sees the real risk status.
ccyber.io helps companies combine NIS2 and ISO 27001 into one practical action plan. We do not create two parallel projects. We build shared requirements mapping, risk register, roadmap, Statement of Applicability, procedures and evidence repository.
We can support your organization with:
The best first step is a NIS2 and ISO 27001 Integration Workshop. In a short workshop, the company can determine which requirements are already covered, where gaps exist, which evidence is available and how to build one plan without duplicating work.
Not automatically. ISO 27001 helps significantly, but NIS2 applicability, national rules, scope, incident reporting, suppliers and evidence must be checked separately.
Yes, if the company wants to organize information security management in a repeatable and auditable way. ISO 27001 can be a very good structure for NIS2.
First combine scope, risk register, Statement of Applicability and evidence matrix. This quickly shows what is already covered and where gaps exist.
Not always. Existing ISO 27001 procedures can often be extended with NIS2 requirements, especially for incident reporting, suppliers and board oversight.
Applicability assessment, risk register, Statement of Applicability, MFA report, access review, restore test, tabletop report, supplier assessment, training and management review.
Sometimes it helps, but the customer may still ask about specific NIS2 requirements: incidents, 24 and 72-hour reporting, suppliers, business continuity, evidence and applicability.
Ideally the programme owner is from security or compliance, with board, IT, legal, risk, DPO, HR, procurement and business process owners involved.
Start with one table: NIS2 requirement, ISO 27001 element, control, owner, evidence, status and gap. This is the simplest way to stop managing two projects separately.
NIS2 and ISO 27001 do not need to compete with each other or create two separate workstreams. NIS2 defines regulatory duties, while ISO 27001 provides the management system that helps implement, supervise and prove them.
The best practical plan combines applicability assessment, management system scope, risk register, Statement of Applicability, ISO 27002 controls, procedures, tests, suppliers, training, audits and evidence in one model.
The best rule is: one risk register, one roadmap, one control matrix and one evidence repository. Then NIS2 is not an extra layer of chaos, but a natural extension of a mature information security management system.
Will Your Company Survive a Ransomware Attack? Disaster Scenarios and Survival Strategies
A company will survive a ransomware attack if it knows before the incident which processes are critical, how long it can operate without systems, where backups are, who makes decisions, how to contain the attack, how to restore data and how to communicate with customers. Survival does not mean no loss. It means controlling chaos: fast detection, isolation, board decisions, safe recovery, business continuity, evidence and a plan to return to normal operations.
Prepared by: CCyber Editorial Team
A company survives a ransomware attack when it does not start thinking about survival only after systems are encrypted. The key elements are: critical service list, tested backups, recovery plan, MFA, administrator account reduction, monitoring, device protection, updates, prepared response plan, emergency contacts, board decisions and exercised scenarios. The worst case is when the company loses email, files, finance system, CRM, backups and administrator access at the same time, while the board is still deciding who should call the IT provider, bank, customer, lawyer and insurer. Survival means limiting damage, operating in emergency mode and returning to work safely.
July 2026
Surviving a ransomware attack does not mean the company suffers no losses. It means the company keeps control of the situation, limits spread, preserves evidence, maintains communication, restores the most important services and returns to operations safely.
A company survives if it can answer:
Ransomware is a test of technology and a test of company management under pressure.
Ransomware combines several problems at once. The company may lose access to systems, data, email, files, backups, devices and administrative tools. Add time pressure, extortion, possible data leak, customer questions, legal duties and reputation risk.
The board should therefore treat ransomware as a business continuity scenario, not only an IT failure.
There are no tested backups, no incident plan, no critical systems list, no emergency contacts, broad administrator access and no board ransomware exercise.
Backup, MFA and an IT provider exist, but nobody knows when data was last restored, who has administrator accounts, whether backups are attack-resistant and who makes decisions at night or during a weekend.
Documents exist, but they were not tested. During an attack, the company discovers that contact lists are outdated, backup misses an important system and customer communication has no owner.
The company knows critical systems, has separated backups, restore tests, procedures, owners, contacts, communication plan, scenario exercises and board reports.
The most resilient companies have not only an IT plan, but also a business plan: how to serve customers, take orders, produce, ship, invoice and communicate when digital systems do not work.
The attacker takes over a user or administrator account, gains access to email and cloud files, then encrypts or deletes documents. Employees lose access to offers, contracts, invoices, project documents and customer correspondence.
The company loses access to invoicing, accounting, ERP or file servers. It cannot issue invoices, process payments, check receivables or run core financial processes.
Ransomware blocks production systems, warehouse systems, labeling, planning, scanners, operator stations or connections between IT and OT. The company cannot produce, ship goods or control quality.
The company assumes it has backups. After the attack, it turns out backups were connected to the same network, the ransomware administrator had access, backups are encrypted or the last clean recovery point is weeks old.
The attacker not only encrypts data, but copies it first. The company receives a threat to publish customer data, contracts, financial documents, correspondence or employee data.
The attacker takes over an IT provider account, remote management tool or multi-customer support system. The company is attacked through a trusted administration channel.
The attacker takes over administrator accounts, changes access rules, adds their own accounts, resets passwords, disables MFA or destroys logs. The company does not know which accounts can be trusted.
The key board question is: what must work for the company to survive one week? This is not about full comfort. It is about minimum ability to serve customers, revenue, production, payments and communication.
Evidence to prepare: minimum operating level card with system recovery priority.
The company often knows which systems it has, but not what they depend on. Ransomware reveals dependencies at the worst moment.
Evidence to prepare: critical service dependency map.
Ransomware often starts with account takeover, remote access, vulnerabilities or administrator privileges. Identity protection is one of the most important survival strategies.
Evidence to prepare: MFA report, administrator account list and access review report.
Backup is a survival strategy only when it is available, clean and tested. The statement “backup runs” is not enough.
Evidence to prepare: backup report and restore test report.
Ransomware is much more dangerous if it can move from one laptop to servers, backups, file shares and production systems.
Evidence to prepare: segmentation map, access policies and endpoint protection report.
After an attack, communication may be harder than technology. Email may be down, phones may be overloaded, customers may ask about data and the team may receive conflicting information.
Evidence to prepare: crisis communication plan and emergency contact list stored outside the main email system.
A plan that has not been exercised is only a hypothesis. A ransomware exercise should include the board, IT, legal, communications, finance, operations and the IT provider.
Evidence to prepare: ransomware exercise report with gaps and remediation actions.
The ransom decision is a crisis, legal, financial, reputation and operational decision. It should not be made under pressure without consultation. Paying ransom does not guarantee data recovery, does not remove the attacker from the environment and may increase the risk of being targeted again.
The best strategy is to prepare the company so ransom pressure is as low as possible. This means backups, tests, plan, isolation and ability to operate in emergency mode.
Ransomware stops sales, production, finance, customer service and reputation. It is a board issue.
Backup without restore is not a strategy. Only a test shows whether the company can return to work.
Not everything can be restored immediately. The company should know how to operate for several days without some systems.
If email is encrypted or compromised, the crisis team must have another contact channel.
Not everything can be restored at once. The board should define which services return first.
The IT, cloud, backup or production system supplier must be part of the plan. Without them, the plan may fail.
During a real attack, people work under pressure. Exercises reduce chaos.
Restoring systems into a contaminated environment may cause re-encryption. First, understand scope and entry cause.
A manufacturing company has 180 employees. It uses ERP, warehouse system, email, cloud files, production planning systems and an external IT provider. The board assumes the company is prepared because “backup works”.
During a ransomware exercise, it turns out the backup covers ERP, but not several critical planning files. The warehouse system depends on a server nobody added to the critical list. The IT provider has broad administrator access, but the contract does not define incident response time. There is also no alternative communication channel if email stops working.
The company implements a 90-day plan. It tests recovery, updates the dependency map, reduces administrator access, defines minimum viable production operation, prepares crisis communication and exercises the first 24 hours of an attack. After three months, the company still has no guarantee ransomware will not hit it. But it has a much higher chance of surviving without weeks of chaos.
ccyber.io helps companies prepare for ransomware as a business continuity scenario, not only an IT incident. We combine the board, finance, IT, security, supplier, communication and audit evidence perspectives.
We can support your organization with:
The best first step is a Ransomware Survival Workshop. In a short workshop, the company can identify the most dangerous scenarios, calculate downtime cost, check whether backups really work, define which services must be restored first and decide what the board should approve before an incident.
No. Backup is necessary, but it must be separated, protected, tested and restorable into a clean environment. The company also needs a plan, people, communication and recovery priorities.
Isolation, backup protection, log preservation, crisis team activation, scope assessment, expert contact and board decisions about business priorities.
This decision should not be automatic. Consider law, sanctions, insurance, backup availability, data leak risk and the fact that payment does not guarantee recovery or attacker removal.
For critical systems, at least quarterly or after major changes. It is also worth testing full service recovery, not only a single file.
The board, IT, security, finance, operations, legal, communications, customer service, HR and key suppliers. Ransomware affects the whole company.
Start with basics: MFA, critical system list, tested backups, response provider, incident procedure, emergency contacts, employee training and a scenario exercise.
It means the ability to run the most important processes without full access to digital systems. It may include manual orders, alternative communication, emergency invoicing and priority support for key customers.
Start with three questions: which services must return first, were backups tested and who makes decisions in the first 24 hours of an attack?
A ransomware attack is a disaster scenario that checks whether the company truly understands its processes, data, systems, suppliers and board decisions. Tools are not enough. The company must know how to act when tools stop working.
A company survives if it prepares a minimum operating level, tested backups, recovery plan, identity protection, segmentation, monitoring, contact list, communication plan and scenario exercises.
The best rule is: do not ask only whether we have backup. Ask whether tomorrow morning we can restore the most important service into a clean environment and serve customers before everything returns to normal.
NIS2 Checklist for Companies: 20 Actions Before an Audit or Inspection
A NIS2 checklist before an audit or inspection should cover not only policies, but primarily evidence of operation. The company should confirm applicability, service scope, risk owners, asset inventory, risk management measures, MFA, backup, restore testing, incident response, incident reporting, suppliers, board and employee training, logs, vulnerabilities, access reviews and the evidence pack. An auditor or authority will ask not only “do you have a procedure?”, but “when did you last test it and what evidence do you have?”.
Prepared by: CCyber Editorial Team
Before a NIS2 audit or inspection, a company should prepare not only documents, but also evidence that cybersecurity works in practice. The 20 key actions are: confirming applicability, defining the scope of services and systems, assigning owners, preparing a risk register, performing gap analysis, approving an action plan by the board, organizing policies, inventorying assets, MFA and access control, access review, backup and restore testing, incident response plan, 24 and 72-hour incident reporting procedure, tabletop exercise, logs and monitoring, vulnerability management, supplier security, training, evidence repository and internal mock audit. An audit or inspection usually does not stop at “do you have a document?”. The key question is: “can you prove the document is being used?”.
July 2026
NIS2 audit readiness means the organization can show three things:
An audit or inspection is not only about checking whether the company has an information security policy. In practice, questions will concern who owns risk, when the last review happened, what test results were, which gaps are open, who approved exceptions and how the company responds to incidents.
The audit scope depends on the company’s role, sector, national rules, customer expectations and inspection purpose. In practice, prepare for questions about:
Every preparation area should have two layers: document and evidence. The document states what the company declares. Evidence shows that the declaration works in practice.
The first action is a formal applicability assessment. The company should know whether it is an essential entity, important entity, supplier to such an entity or organization indirectly affected by customer requirements.
Evidence: applicability assessment with date, sources, conclusion and board decision.
The auditor must know what the NIS2 programme covers. Without scope, risk and controls cannot be assessed.
Evidence: NIS2 scope map, critical systems and services list and exclusion justification.
Lack of owners is one of the most common gaps. NIS2 requires real cyber risk management, not anonymous tasks in a spreadsheet.
Evidence: RACI matrix or owner list approved by the board.
The risk register shows that the company manages cybersecurity as business risk. It should be linked to critical services, suppliers and the action plan.
Evidence: current risk register and risk review record by board or risk committee.
Gap analysis shows what the company already has, what is missing and which actions are priority before the audit.
Evidence: NIS2 gap analysis with gaps, priority, owner and remediation plan.
An auditor may ask whether the board understands risks and approved cyber risk management measures. An IT-only plan is not enough.
Evidence: resolution, management note or record approving the NIS2 roadmap.
Policies should be current, short and aligned with how the company actually works. Do not show documents the organization does not follow.
Evidence: approved documents with owner, version, review date and scope.
You cannot protect systems the company does not know. Asset inventory is the foundation of access control, backup, monitoring and incident response.
Evidence: asset register with owners, criticality, data and last update date.
Privileged accounts are one of the most important control areas. Missing MFA or too many administrators is a typical pre-audit gap.
Evidence: MFA report, administrator account list, PAM or PIM report where applicable.
Access review shows that the company controls who has access to systems and data. It is a very important audit evidence item.
Evidence: access review report with decisions: keep, reduce, remove, investigate.
Backup without restore testing is weak evidence. An auditor or authority may ask when the company last recovered data from backup and what the result was.
Evidence: backup report, restore test report and remediation list after the test.
The response plan should work in the first hours of an incident. It must be clear, short and mapped to roles.
Evidence: incident response plan, emergency contact list and role owners.
NIS2 provides staged reporting of significant incidents. The company must be able to quickly collect minimum information and escalate.
Evidence: incident reporting procedure, report templates and escalation path test.
A scenario exercise is one of the best readiness evidence items. It shows whether procedures work, people know their roles and the board can make decisions under pressure.
Evidence: tabletop exercise report with findings, gaps and action plan.
Without logs, the company may not know what happened, when and from which account. Logs also matter as evidence after an incident.
Evidence: log source list, retention policy, alert report and examples of alert response.
The organization should show that it detects, assesses and closes vulnerabilities. A scanner report alone is not enough.
Evidence: vulnerability report, remediation list, retest evidence and risk acceptance decisions.
NIS2 strongly emphasizes supply chain security. Before an audit, the company should know critical suppliers and their impact on services.
Evidence: critical supplier register, supplier risk assessments and security requirements in contracts.
NIS2 raises board accountability, so management training is an important preparation element. Employees should also know key procedures.
Evidence: training plan, participant list, materials, knowledge test result and effectiveness report.
Time matters in an audit. If evidence is scattered across mailboxes, folders and messengers, the inspection will be chaotic.
Evidence: evidence matrix with owners, dates, status and file location.
A mock audit helps find gaps before inspection. It should check not only documents, but also process owner interviews and evidence availability.
Evidence: internal audit report, nonconformity list, observations and corrective action plan.
The board report should be short and decision-focused. It should not be a list of technical details. It should show whether the company is ready, what remains risky and which decisions are needed.
The company has policies, but no reports, tests, logs, decisions or remediation actions.
The company assumes NIS2 applies or does not apply, but has no documented conclusion.
The board discussed cybersecurity, but there are no minutes, budget, risk acceptances or approved roadmap.
The auditor asks about restore, and the company only shows that backup runs.
The plan exists, but nobody checked whether it works in the first 24 and 72 hours.
Suppliers have access to data and systems, but were not assessed or added to the risk register.
Evidence is scattered and nobody is responsible for keeping it current.
Some gaps can be closed quickly, but tests, exercises, reviews and evidence need time.
A technology company prepares for an audit by a regulated-sector customer. It has a security policy, backup, MFA and an external IT provider. During review, however, it turns out there is no formal applicability assessment, the risk register is outdated, backup has not been tested for a year, access review did not cover suppliers and the incident plan has never been exercised.
The company does not try to create a large documentation library from scratch. It creates a 20-action pre-audit list. In the first month, it defines scope, owners and evidence. In the second month, it performs access review, restore test, supplier assessment and training. In the third month, it runs a tabletop and internal mock audit.
The result is practical: the company not only passes the audit more smoothly, but also improves real incident readiness. The biggest change is not a new policy. The biggest change is that every important area has an owner, evidence and remediation plan.
ccyber.io helps companies prepare for audits, inspections and NIS2 requirements in a practical, risk-based and evidence-driven way. We do not start from documents for documents. We start from scope, applicability, risks, critical systems, incidents, suppliers and board accountability.
We can support your organization with:
The best first step is a NIS2 Audit Readiness Workshop. In a short workshop, the company can determine which evidence already exists, what is missing, which risks are most urgent and which actions must be completed before the audit or inspection.
No. Policies are needed, but the auditor will expect operating evidence: reports, tests, reviews, logs, training records, board decisions and remediation actions.
First prepare applicability assessment, scope, risk register, owners, evidence matrix and board report. Then close technical and operational gaps.
MFA report, access review, restore test, risk register, incident response plan, tabletop report, supplier assessment, board and employee training, and board decisions.
It is strongly recommended. It is one of the best ways to prove the company can act after an incident, escalate to the board and prepare notifications within short timelines.
Yes. Supply chain security is an important NIS2 element. The company should have a critical supplier register, risk assessment and security requirements in contracts.
The board should know applicability status, top risks, action plan, critical gaps, budget decisions, incident status, supplier status and evidence status.
A basic evidence pack can be organized in 90 days if the company has an action owner and access to evidence. Full maturity usually requires a longer programme.
Start with an evidence matrix: requirement, evidence, owner, date, status and gap. This quickly shows where the company is ready and where real evidence is missing.
A NIS2 checklist before an audit or inspection should focus on evidence, not only documents. The company must show that it knows its scope, risks, systems, suppliers, incidents and board accountability.
The 20 key actions are applicability assessment, scope, owners, risk register, gap analysis, board decisions, policies, assets, MFA, access review, backup, restore test, incident response, incident reporting, tabletop, logs, vulnerabilities, suppliers, training, evidence repository and mock audit.
The best rule is: an audit is prepared before the audit, not during it. The earlier the company starts collecting evidence of operation, the lower the risk of chaos, nonconformities and costly emergency actions.
Cybersecurity Toolkit for SMEs: Documents, Procedures and Checklists
A Cybersecurity Toolkit for SMEs is a practical set of documents, procedures and checklists that helps a small company organize cybersecurity without building a large IT department. The minimum includes: system and account register, password and access policy, MFA rules, backup procedure, restore test, incident response plan, emergency contact list, phishing procedure, payment procedure, access review, offboarding checklist, supplier register, training plan and an evidence pack for customers, audits or insurers.
Prepared by: CCyber Editorial Team
A Cybersecurity Toolkit for SMEs is a practical set of documents, procedures, checklists and evidence that helps a small company manage cybersecurity without chaos. It is not about creating a large policy library that nobody uses. It is about preparing simple working tools: who has access, where data is, how backup works, who approves payments, what to do after phishing, how to remove access from a former employee, how to respond after an incident and what evidence to show a customer, auditor or insurer. A good SME toolkit should be short, practical, current and assigned to owners.
July 2026
A Cybersecurity Toolkit for SMEs is a set of practical materials that helps the company operate more safely and predictably. It is not one document. It is an organized pack that answers the key questions of the owner, board, employees and IT suppliers.
The toolkit should help answer:
The key rule: the toolkit must help people act. It should not be documentation created only to look good in a folder.
In a small company, cybersecurity is often distributed. The owner makes decisions, the IT supplier configures tools, accounting makes payments, employees use email and cloud tools, marketing manages social media and sales uses CRM. Without simple procedures, everyone acts from habit.
Common effects of lacking structure:
An SME toolkit organizes the basics and shortens response time. This is often more important than buying another tool.
A good toolkit should be simple. Each document should answer a specific question, have an owner and be verifiable.
This is the foundation of the whole toolkit. The company must know what it has and what it protects. Without this, access, backup, suppliers and incidents cannot be managed well.
Evidence: current system, account and device register.
The password and access policy should be short. Its purpose is to limit account takeover and excessive permissions.
Evidence: policy, MFA report, administrator account report and access review report.
This procedure organizes the user lifecycle: new person, role change, end of cooperation. It is especially important in small companies where accounts are often created informally.
Evidence: access requests and completed access removal checklists.
A backup without a restore test is only an assumption. The procedure should state what is backed up, how often, where, who owns it and when restore is tested.
Evidence: backup report and restore test report.
An incident response plan does not need to have dozens of pages. For SMEs, simplicity matters most: who decides, who to call, what to disconnect, what to preserve and who to inform.
Evidence: response plan and scenario exercise report.
Employees must know what to do with a suspicious email, SMS, messenger message or call from someone impersonating IT, a customer or the board.
Evidence: suspicious message report register and phishing training report.
Fake invoices and supplier bank account changes are real SME risks. This procedure should be mandatory for finance, accounting, administration and the board.
Evidence: supplier bank account change register and second-channel confirmations.
IT, cloud, hosting, backup, CRM, accounting and software suppliers may have access to company data or systems. The company should know which suppliers are critical and what risk they introduce.
Evidence: supplier register and critical supplier assessment card.
Devices are entry points to company data. The policy should define the security minimum for laptops, phones, tablets, personal devices and remote work.
Evidence: device list and minimum requirement compliance status.
Training should not be a one-time presentation. It should teach specific behaviors: reporting phishing, protecting MFA codes, using second-channel verification, using passwords safely and responding after a mistake.
Evidence: participant list, materials and short test results.
More customers, insurers and auditors ask not only whether the company has safeguards, but whether it can prove them. SMEs should therefore prepare a simple evidence pack.
Evidence: evidence repository with dates, owners and freshness status.
Documents and evidence should be stored in one controlled location. They should not be scattered across private folders, email inboxes and messengers.
SMEs increasingly receive cybersecurity questions from customers, partners and insurers. It is worth preparing answers in advance.
The company prepares long documents, but nobody uses them. Short procedures and checklists are better at the start.
If nobody owns the document, it quickly becomes outdated.
The company has a backup policy, but no restore test report. It has training, but no participant list. It has access procedure, but no review report.
A fake invoice may cost the company more than most basic safeguards.
An IT, cloud, hosting or software provider may have very broad access. It should be registered and regularly reviewed.
A plan works only when it has been exercised. Otherwise, the company discovers gaps under stress.
Documents prepared once and not reviewed for a year stop reflecting company reality.
A services company has 35 employees. It uses Microsoft 365, CRM, invoicing system, cloud file storage, online banking, a website and an external IT provider. A key customer sends a security questionnaire and asks for evidence of MFA, backups, access review, training and incident response plan.
The company has many good practices, but they are scattered. The IT provider knows something about backup, the office manager knows who creates accounts, finance knows the payment procedure, but there is no single set of documents and evidence. Responding to the customer takes several weeks.
After this experience, the company creates a simple toolkit: system register, password policy, access procedure, MFA report, backup procedure, restore test, incident plan, supplier register and evidence repository. During the next customer audit, the response is ready in days, not weeks.
ccyber.io helps SMEs prepare a practical Cybersecurity Toolkit: documents, procedures, checklists and evidence that support real security and audits. We do not create documentation for documentation. We build a toolkit that works in daily operations.
We can support your organization with:
The best first step is a Cybersecurity Toolkit Workshop for SMEs. In a short workshop, the company can determine which documents already exist, what is missing, which procedures are most urgent and which evidence should be prepared first.
Yes, but the documents should be simple and practical. Short procedures, checklists and execution evidence matter most.
Start with the system, account and device register. Without visibility, it is hard to prepare sensible access, backup or incident procedures.
No. A policy helps, but the company also needs procedures and evidence: backup tests, access reviews, MFA reports, training records and incident exercises.
At least quarterly for accounts, access, suppliers and backup. Strategic documents can be reviewed at least annually or after major company changes.
The owner may be the business owner, board member, office manager, operations person, vCISO or IT manager. The role should be formally named.
Yes. Insurers often ask about MFA, backup, training, incident response, suppliers and incident history. A good toolkit makes responses easier.
Yes. Customers often ask for security evidence. System register, MFA report, restore test, access review, training and procedures shorten response time.
Start with an owner, system register, MFA, password and access policy, offboarding checklist, emergency contacts and phishing procedure.
A Cybersecurity Toolkit for SMEs should be a practical working set, not a formal document library. It should help the company answer basic questions: what do we protect, who has access, how do we recover data, how do we respond to incidents and what evidence can we show?
The minimum toolkit includes system register, password and access policy, backup procedure, incident plan, phishing procedure, payment procedure, offboarding checklist, supplier register, training plan and evidence repository.
The best rule is: start with a small toolkit that really works. Ten pages of used procedures are better than one hundred pages of documentation nobody knows.
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.