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.
Cybersecurity Without an IT Department: What to Implement First
A small company without an IT department does not need to start with complex tools. First, it should A small company without an IT department does not need to start with complex tools. First, it should protect what most often causes real losses: email, accounts, computers, phones, backup, administrator access, payments, customer data, suppliers and incident response. The starting minimum is MFA, password manager, updates, backup with restore testing, device protection, account cleanup, employee training, payment procedure and a simple plan for what to do after an attack.
Prepared by: CCyber Editorial Team
A company without an IT department should implement cybersecurity in stages, starting with controls that quickly reduce the biggest risks. The first priorities are: securing email and business accounts with MFA, using a password manager, updating computers and phones, backing up critical data, testing restore, protecting devices, limiting administrator accounts, setting a payment and supplier bank account change procedure, training employees and preparing a simple incident response plan. You do not need to build a security operations center or buy many tools immediately. You need to know which data and accounts are critical, who owns them, how to recover them and what to do in the first hours after a suspicious event.
July 2026
Cybersecurity without an IT department means the company has no internal administrator team, security manager or infrastructure specialists. This is common in SMEs. It does not mean the company can ignore risk.
In practice, technology responsibility is often distributed:
The problem starts when nobody has the full picture: which accounts exist, who has access, where data is stored, whether backup works, who can reset passwords, who removes access when an employee leaves and what to do after an attack.
Small companies often assume they are too small to interest cybercriminals. This is a dangerous assumption. For an attacker, a small company can be attractive because it has money, data, email, customers and online banking, but often lacks mature safeguards.
Common targets in SME attacks:
An attack does not need to be highly advanced. Phishing, stolen password, missing MFA, malicious attachment, fake invoice, compromised supplier account or ransomware on a computer with important files may be enough.
The first control is not a tool. The first control is ownership. In a company without an IT department, clearly name the person who is organizationally responsible for cybersecurity. This person does not need to configure everything personally, but must track the plan, suppliers, deadlines and evidence.
Evidence to prepare: one-page responsibility sheet: who owns accounts, backup, computers, payments, suppliers and incidents.
You cannot protect what the company cannot see. The first practical step is simple inventory.
Minimum: spreadsheet with system name, owner, administrator, number of users, MFA, backup and supplier.
Evidence to prepare: account, system and device register updated at least quarterly.
MFA, or multi-factor authentication, is one of the most important controls for a small company. A password can be stolen, but MFA makes it harder to use the password alone to take over an account.
Evidence to prepare: critical account report showing whether MFA is enabled.
In small companies, passwords are often saved in notes, browsers, spreadsheets or sent by messenger. This is high risk. A password manager helps create and store unique passwords for each system.
Evidence to prepare: list of systems covered by the password manager and exception list to close.
Updates close bugs that may be used in attacks. A company without an IT department should aim for a simple model: automatic updates wherever possible.
Evidence to prepare: simple update report: device, owner, system, latest update date, status.
Backup is one of the most important safeguards for a company without an IT department. It protects against ransomware, accidental deletion, computer failure, employee departure and cloud mistakes.
Most important: backup without a restore test is an assumption, not evidence.
Evidence to prepare: backup report and restore test report for a file, mailbox or critical system.
Computers and phones store email, files, login sessions and account access. If a device is compromised or lost, the attacker may access many systems.
If employees use personal phones or laptops for work, the company should have clear rules: what is allowed, which apps are approved, whether PIN is required, whether customer files may be downloaded and what happens when the employee leaves.
Evidence to prepare: device list with minimum security requirements and compliance status.
In small companies, accounts often stay active after an employee leaves, changes role or a supplier finishes work. This is a simple path to an incident.
Evidence to prepare: quarterly access review report with decisions: keep, reduce, remove, investigate.
Email is the center of a small company. Invoices, contracts, password resets, customer communication and access to other accounts all flow through email. Email takeover often means compromise of much of the company.
Evidence to prepare: email configuration report, SPF/DKIM/DMARC status and suspicious message report register.
For a small company, a fake invoice or supplier bank account change may be more damaging than a technical attack. Payment security is part of cybersecurity.
Evidence to prepare: payment procedure and supplier bank account change register with second-channel confirmation.
A company without an IT department especially needs a simple incident plan. Under stress, there is no time to decide who to call and what to disable.
Evidence to prepare: one-page incident plan, emergency contact list and short exercise report.
The best SME model is not a full IT department on day one, but a clear internal owner and a trusted technical partner with a defined scope of responsibility.
If the company has no IT department, the supplier becomes a very important part of security. They should not be selected only by price or availability.
Evidence to prepare: IT supplier card with service scope, access, MFA, response time and emergency contact.
Everyone assumes someone is handling it, but nobody has the account, device, backup and supplier list.
Email, cloud, social media, hosting and administrator accounts are just as important. Email takeover may lead to takeover of many other accounts.
The company has a copy, but never checked whether it can be restored and how long it takes.
The password to email, social media or invoicing is known by several people and nobody knows who made a change.
This is a common gap. Access must be removed on the day cooperation ends.
A supplier may be needed, but access should be named, protected with MFA, documented and regularly reviewed.
A fake invoice or supplier bank account change can cause a large loss without any malware.
Employees should know what to do before phishing, fake calls or ransomware happen.
A tool will not help if nobody knows who has accounts, where data is stored and how to respond to an alert.
After an attack, the company loses hours searching for the bank, IT provider, hosting and email provider phone numbers.
A service company has 18 employees. It uses Microsoft 365, invoicing software, CRM, online banking, a website and several social media accounts. It has no IT department. The owner assumes the email provider and external technician “take care of security”.
After a short review, it turns out only some accounts have MFA, social media passwords are shared, backup has never been tested, a former employee still has CRM access and there is no supplier bank account change procedure. The company does not need a complex security system immediately. It needs the basics.
Within 30 days, the company enables MFA on email, banking, CRM and hosting, deploys a password manager, creates account and device lists and introduces a payment procedure. Over the next 60 days, it starts backup, tests restore, trains employees and performs the first access review. After 90 days, it has a simple incident plan and emergency contact list.
The biggest change is not buying an expensive tool. It is that the company knows what it has, who has access, what is critical, how to recover it and who makes decisions after an attack.
ccyber.io helps small companies implement cybersecurity without building a full IT department. We start with the minimum that truly reduces risk: accounts, MFA, backup, devices, email, payments, suppliers, training and incident response.
We can support your organization with:
The best first step is a Cyber Minimum Workshop for SMEs. In a short workshop, the company can determine which accounts and data matter most, where MFA is missing, whether backup works, who has access, which procedures are needed and which actions should be implemented in the first 30 days.
Yes. Small companies have email, money, customer data, invoices, online accounts and reputation. That is enough to become a target for phishing, ransomware or payment fraud.
Start with an account and device list, MFA on email and critical accounts, password manager, backup, updates, access review, payment procedure and employee training.
Not at the beginning. Organize the basics first. More expensive tools make sense when the company knows what it protects, who has access and how it responds to incidents.
One person should be organizationally responsible. This may be the owner, board member, office manager or operations person supported by an external specialist.
They can help a lot, but the company should still know their responsibility scope, access, response time, MFA rules, backup rules and incident procedure.
Email, Microsoft 365 or Google Workspace administrator, banking, CRM, invoicing system, hosting, domain, online shop, social media and backup.
At least quarterly for critical data and after major changes in systems, backup provider or file structure.
Start with three simple procedures: phishing reporting, payments and supplier bank account changes, and response to account takeover or ransomware.
Cybersecurity without an IT department must be simple, practical and organized. A small company should not start with complex tools, but with controls that protect against the most common losses: email takeover, data loss, fake invoices, ransomware, missing backup and uncontrolled access.
The first steps are MFA, password manager, updates, tested backup, device protection, account review, secure email, payment procedure, employee training and a simple incident plan.
The best rule is: start with visibility and ownership. The company must know which accounts, devices, data and accesses it has. Only then should it select tools, suppliers and further security layers.
NIS2 Directive: What Is the Company Board Personally Responsible For?
NIS2 does not mean that the board must personally configure firewalls, backups or monitoring systems. It does mean that the board must approve cyber risk management measures, oversee their implementation, understand the impact of cyber risks on business operations, ensure resources, complete training and maintain evidence that cybersecurity is actually managed. Personal board accountability mainly concerns lack of oversight, lack of decisions, ignoring risk, failing to act on supervisory recommendations and inability to prove that the company acted responsibly.
Prepared by: CCyber Editorial Team
Under NIS2, the company board is mainly responsible for overseeing cybersecurity as a business risk. The board does not need to implement technical controls personally, but it must approve cyber risk management measures, oversee their implementation, ensure resources, understand risks, participate in training and require evidence that controls work. Personal board accountability does not mean automatic liability for every incident. It does mean, however, that the board cannot say “this is an IT matter” if the company had no risk assessment, response plan, backup, access control, supplier oversight, training, reporting and evidence. The detailed scope of accountability depends on national law, the role of the specific person, company structure and circumstances of the infringement.
July 2026
Personal board accountability under NIS2 does not mean every board member becomes a system administrator or cybersecurity specialist. It means cybersecurity becomes an area where the board must exercise real oversight.
In practice, the board is responsible for whether the company:
Simply put: the board is not responsible for every technical detail, but it is responsible for whether the company has an effective cyber risk management system.
The board may delegate execution to IT, security, compliance, external advisors and suppliers. It should not delegate oversight responsibility.
If the board has no reports, does not know the risks and does not make decisions, it will be difficult to show real oversight.
The first board responsibility is to ensure that the company knows whether it is subject to NIS2 or national implementing rules. This should not be an assumption or verbal opinion. A documented assessment is needed.
The assessment should cover:
Board evidence: NIS2 applicability assessment with a decision on who owns further actions.
NIS2 states that management bodies approve cyber risk management measures. This means the board should know the main risks and approve a plan of technical, operational and organizational measures.
Risk management measures include, among others:
Board evidence: approved cyber risk management plan linked to the risk register and budget.
Approving the plan is not enough. The board should oversee whether the plan is being implemented. Oversight does not need to mean daily task tracking. It should mean recurring reporting, questions about delays and decisions on high-priority risks.
The board should see:
Board evidence: recurring NIS2 dashboard with decisions and remediation actions.
NIS2 requires members of management bodies to receive training. The purpose is not to turn the board into a technical team. The purpose is for the board to understand cyber risks, assess risk management practices and understand the impact of cybersecurity on the company’s services.
Board training should include:
Board evidence: training materials, participant list, test result or participation confirmation, and note with conclusions.
The board does not need to implement controls personally, but it must provide real resources. Lack of budget does not remove risk. It may show that the company knowingly did not implement required measures.
The board should require clear information on:
Board evidence: approved budget or conscious risk acceptance decision with justification and review date.
NIS2 provides short timelines for reporting significant incidents. The board should ensure that the organization has a process that works in the first hours of an incident.
The company should be able to prepare:
The board does not need to write the notification personally, but it should know who classifies the incident, who informs the authority, who manages communication and who approves the report.
Board evidence: incident reporting procedure, notification templates and exercise report covering the first 24 and 72 hours.
Cybersecurity under NIS2 is not only about preventing attacks, but also limiting the impact of incidents on services. The board should know whether the company can continue operations and recover critical systems.
The board should ask:
Board evidence: business continuity plan, recovery test report and decisions on residual risks after the test.
NIS2 emphasizes supply chain security. The board should know which suppliers are critical and what risks they introduce into the organization.
The supplier programme should include:
Board evidence: critical supplier register, risk assessments and decisions about high-risk suppliers.
The board sets the tone of the organization. If employees fear reporting mistakes or suspicious situations, the company loses time. If managers demand bypassing procedures, training will fail.
The board should support:
Board evidence: training plan, training effectiveness report, reporting metrics and remediation actions after exercises.
During inspection, audit or after an incident, declarations are not enough. The company must show evidence. The board should require an organized evidence pack.
Evidence should include:
Board evidence: evidence repository and requirements matrix for NIS2, KSC, ISO 27001 and customer requirements.
Not every incident automatically means board accountability. Incidents can happen even in well-managed organizations. The key question is whether the company acted responsibly before, during and after the incident.
Many companies discuss cybersecurity in meetings, but do not document decisions. This is a mistake. After an incident, the decision trail matters.
IT is critical, but NIS2 concerns risk management, business continuity, suppliers, budget, incidents and management accountability.
The company assumes NIS2 does not apply because it is not classic critical infrastructure. NIS2 has a broader scope, and requirements may also come through customers and supply chains.
Risks are discussed, but there are no decisions, owners, budgets and deadlines. After an incident, it is hard to show real oversight.
The board does not need to be technical, but it must understand risks, obligations and consequences of decisions.
Incident response plans, backups and business continuity without tests are only assumptions. The board should require exercise reports.
An ICT supplier, cloud provider, software vendor, integrator or service company may be the source of an incident. NIS2 requires supply chain risk to be considered.
Fines matter, but business disruption, customer loss, post-incident inspection and inability to prove responsible behavior may be bigger problems.
The company may be doing many good things, but without evidence, it is difficult to show them to an authority, customer, auditor or insurer.
A technology company provides services to healthcare and industrial customers. The board initially assumes that NIS2 is a technical topic, so it assigns it to IT. After the first assessment, it turns out that the company is an important supplier to regulated entities, has access to customer data and maintains systems affecting continuity of customer services.
The gap analysis shows that the company has MFA, backup and monitoring, but lacks a formal risk register, board decisions, incident exercise, supplier programme, access review reports and training evidence. IT performed many actions, but the board did not receive recurring reports and did not make formal risk decisions.
The board launches a 90-day plan. The company creates an applicability assessment, risk register, action plan, board report, tabletop exercise, recovery test and critical supplier register. The most important change is not creating one document. The most important change is that the board starts regularly overseeing cyber risk and making documented decisions.
ccyber.io helps boards and security teams prepare organizations for NIS2 in a practical, measurable and evidence-based way. We do not start from documents for documents. We start from applicability, risk, board accountability, incidents, suppliers and business decisions.
We can support your organization with:
The best first step is a NIS2 Board Accountability Workshop. In a short workshop, the company can determine whether it is subject to NIS2, what the board’s duties are, which risks require decisions, what evidence must be prepared and which actions should start in the first 30 days.
NIS2 requires management bodies to approve cyber risk management measures, oversee their implementation and be potentially liable for infringements. The detailed scope of accountability depends on national law and circumstances.
Not automatically. An incident may happen despite reasonable safeguards. The key question is whether the company had adequate measures, oversight, procedures, timely reporting, response and evidence.
It does not need to know every technical detail. It must understand risks, business impact, reporting obligations, control status, gaps and budget decisions.
Yes. The directive requires training for members of management bodies so they have the knowledge and skills needed to identify risks and assess cybersecurity risk management practices.
Possible consequences depend on national law. NIS2 provides for liability of persons able to ensure compliance and, in certain cases, the possibility of temporary prohibition from exercising managerial functions in essential entities.
No. A CISO or vCISO can lead the programme, but the board should still approve measures, oversee implementation, provide resources and make risk decisions.
Applicability assessment, risk register, board reports, budget decisions, training evidence, backup tests, incident exercises, access reviews, supplier assessments and corrective actions.
Start with applicability assessment, board training, risk register, control status report and 90-day action plan. Then run an incident exercise and prepare an evidence pack.
The NIS2 Directive does not require the board to become the IT department. It does require the board to exercise real oversight over cybersecurity as business risk. This means approving risk management measures, overseeing implementation, training, budget decisions, supplier management, incident reporting readiness and evidence of control operation.
Personal board accountability will usually not result from the mere fact that an incident occurred. It will result from the question of whether the board did what could reasonably be expected: understood the risks, required action, provided resources, responded to gaps, trained, exercised incidents and documented decisions.
The best rule is: the board does not need to do everything personally, but it must have evidence that it oversees. Under NIS2, lack of oversight, lack of decisions and lack of evidence are often a bigger problem than the technical gap itself.
What Compliance Evidence Should You Prepare for NIS2, KSC and ISO 27001?
Compliance evidence for NIS2, KSC and ISO 27001 is not only policies and procedures. A company should be able to show that cybersecurity works in practice: risk register, control owners, board decisions, backup reports, recovery tests, access reviews, training, supplier assessments, logs, vulnerability reports, incident response exercises, corrective actions and recurring reviews. The best evidence pack shows not only “we have a document”, but “we implemented, tested, measured and improved it”.
Prepared by: CCyber Editorial Team
For NIS2, KSC and ISO 27001, companies should prepare evidence showing that cybersecurity is actually managed, not only documented. The most important evidence includes: applicability assessment, risk register, board decisions, security policies, Statement of Applicability for ISO 27001, risk treatment plan, backup reports, recovery tests, access reviews, MFA, vulnerability management, training, supplier assessment, incident response plan, exercise reports, logs, metrics and corrective actions. A good evidence pack answers four questions: what was the company supposed to do, who owns it, was it done and what proves that it works?
July 2026
Compliance evidence means documents, reports, logs, records, decisions, test results and other traces that show the organization meets a requirement. In cybersecurity, evidence is especially important because many controls are not visible from the outside. The company must show that they work in practice.
Example: a backup policy is a document. The latest backup report, restore test report and list of issues after the test are evidence that the process works.
Good evidence should show:
NIS2 is an EU directive. It requires cyber risk management, appropriate technical, operational and organizational measures, significant incident reporting, management body accountability, business continuity, supplier management and training. Evidence for NIS2 should show that the company knows whether it is in scope, what its risks are, which measures it implemented and how it responds to incidents.
KSC, the Polish Act on the national cybersecurity system, is the Polish legal basis for the national cybersecurity system. The current text should always be checked in official sources because laws and implementing acts may change. Evidence for KSC should align with national duties, deadlines, incident definitions, supervision requirements and expectations of competent authorities.
ISO 27001 is an information security management system standard. Evidence shows that the organization has an ISMS, operates through a continual improvement cycle and can demonstrate risks, objectives, controls, audits, management reviews and corrective actions.
The common denominator is simple: risk management, accountability, controls, testing, monitoring, incidents, suppliers, training and improvement. The language of requirements differs, but much of the evidence can support NIS2, KSC and ISO 27001 at the same time.
You do not need a separate document set for each regulation. Well-designed evidence can support several requirements at once.
Examples:
The best approach is to build one evidence matrix and map each item to NIS2, KSC, ISO 27001, customer contracts and cyber insurance requirements.
An evidence matrix is a central table showing which evidence the company has, what it supports and when it must be refreshed.
Area: backup and recovery.
Evidence: restore test report for a critical system.
Owner: IT operations.
Frequency: quarterly for critical systems.
Supports: NIS2 continuity, KSC information security management system, ISO 27001 Annex A continuity and backup controls.
This is the first evidence group. Before showing controls, the company must know whether and to what extent it is subject to NIS2 and KSC, while for ISO 27001 it must define the ISMS scope.
The company prepares policies and procedures but cannot explain which services, systems and group entities they apply to.
NIS2 and KSC raise cybersecurity to management accountability level. ISO 27001 also requires top management involvement in the information security management system.
Good evidence is not only a board presentation. Good evidence is a record with decisions, risks, budget, owners and deadlines.
Risk is the common foundation of NIS2, KSC and ISO 27001. Without a risk register, it is difficult to show why selected controls are adequate.
A risk register exists, but it has no owners, dates, actions, metrics or board decisions. In that case, it is a document, not a management tool.
Policies show the expected way of working. Procedures show how the company performs specific processes. Policies alone are not enough, but they are a necessary system layer.
A policy should have an owner, version, approval date, scope, review period and link to risks and controls.
The Statement of Applicability, or SoA, is one of the most important ISO 27001 documents. It shows which Annex A controls apply, which do not apply and why.
The SoA is treated as a certification table, not a live control map. A good SoA should be updated after risk, technology and ISMS scope changes.
Access control is one of the most important evidence areas. Account takeover, excessive permissions and missing MFA are frequent incident sources.
An access review report should show not only a user list, but owner decisions: keep, reduce, remove or investigate.
NIS2 and KSC explicitly emphasize business continuity, backup and recovery. ISO 27001 also requires organizations to prepare for disruptions and loss of availability.
The company shows that backup runs, but does not show restore testing. For audit and resilience, restore is more important than the fact that a copy exists.
Under NIS2 and KSC, incident response evidence is particularly important because reporting deadlines are short and the competent authority may ask about the incident handling process.
The best evidence is an exercise report where the company tested the first 24 and 72 hours of an incident: who decides, who reports, who gathers facts and who informs the board.
Vulnerability management shows that the company actively detects and closes gaps instead of waiting for an incident.
The company has a test report, but no evidence that vulnerabilities were fixed or consciously accepted by the risk owner.
NIS2 and KSC strongly emphasize supply chain risk. ISO 27001 also requires managing security in supplier relationships.
Good evidence is a critical supplier card: service, business owner, access scope, risk, contractual requirements, last assessment date and contingency plan.
Training is an organizational requirement and evidence of security culture. Under NIS2 and KSC, board and staff training matter. Under ISO 27001, awareness, competence and participation records matter.
The company shows an attendance list, but does not show whether training changed behavior. It is useful to measure phishing reports, second-channel use and exercise results.
Without logs and metrics, it is difficult to show that the company detects incidents, responds and improves controls.
A good monitoring report shows not only the number of alerts, but also response time, closure status, owners and remediation actions.
The ISMS scope shows which processes, locations, systems, teams and services are covered by the information security management system.
Evidence should show interested parties, legal requirements, customer requirements, internal and external factors, and how these affect the ISMS.
ISO 27001 requires a methodical approach to risk. Evidence includes the methodology, risk register, assessments, decisions and action plan.
The SoA shows which controls are applied, which are not applied and why. It should be consistent with the risk assessment.
The organization should have measurable information security objectives, for example closing high-risk vulnerabilities, backup tests, access reviews, training or MFA improvement.
Evidence includes audit plan, checklist, audit report, nonconformities, observations and corrective actions.
Evidence includes management review minutes covering risk status, audit results, incidents, metrics, corrective actions and management decisions.
Evidence includes nonconformity register, root cause analysis, correction plan, owner, deadline and closure confirmation.
The company should show why it concluded that it is or is not in scope. This should be a documented conclusion, not a verbal opinion.
If the company is an essential or important entity, it should have evidence of registration, decision, qualification or other confirmation according to the relevant national procedure.
The company should have procedures and templates for the first hours of an incident. Evidence should include reporting process tests, not only a written procedure.
Evidence includes board reports, decisions, training, approved plans and budget.
KSC may allow competent authorities to request documents, information and evidence of requirement implementation. Therefore, the evidence pack should be ready before inspection, not created only after a request.
The evidence repository should be organized, secure and easy to review. It should not be a folder where everyone uploads random files.
Not every file is good evidence. Evidence should be credible, current and linked to a requirement.
A policy says what should happen. Evidence shows what actually happened.
If nobody owns evidence, it quickly becomes expired.
During audit, the company wastes time searching for files, and some evidence disappears with the folder owner.
The auditor must know whether evidence is current. No date weakens credibility.
The company has backup, BCP or incident response procedures, but no reports showing the process was exercised.
The board discusses cybersecurity, but there are no minutes, decisions, budget or risk acceptance records.
The company has many files, but does not know which requirement each file supports.
A vulnerability report or audit report is not enough. You need to show what was fixed, when and who approved closure.
A SaaS company is preparing for enterprise customer requirements, NIS2 and ISO 27001. The IT team has many good practices: MFA, backup, monitoring, vulnerability scanning and training. The problem appears during a customer audit. The company cannot quickly show when the latest restore was performed, who approved access review, which risks the board accepted and whether critical suppliers were assessed.
The company creates an evidence matrix. Each control area gets an owner, file location, update frequency and status. Within 90 days, the company organizes its risk register, Statement of Applicability, backup reports, access reviews, training, suppliers, vulnerabilities and incident response.
The result: during the next audit, the company does not search for evidence chaotically. It shows an evidence pack: what is required, which evidence exists, when it was updated and which remediation actions are in progress. This shortens the audit and increases credibility with the customer, board and insurer.
ccyber.io helps companies prepare a practical compliance evidence pack for NIS2, KSC, ISO 27001, customer audits and cyber insurance. We do not create documents for documents. We build an evidence system that shows controls work in practice.
We can support your organization with:
The best first step is a Compliance Evidence Workshop. In a short workshop, the company can determine which evidence already exists, what is missing, which evidence is expired and how to build a pack ready for the board, auditor, customer or supervisory authority.
No. A policy is necessary, but you need operating evidence: reports, tests, reviews, logs, decisions and corrective actions.
Applicability assessment, risk register, action plan, security policy, MFA report, access review, restore test, incident plan, supplier assessment and training evidence.
Yes. Many evidence items can support several requirements at once. That is why it is worth creating an evidence matrix and mapping evidence to different regulations and standards.
It depends on the area. Risks, suppliers, access reviews, backup, training and vulnerabilities should have defined review frequency, usually quarterly, semi-annually or annually.
Lack of testing. Companies have backup, incident response or BCP procedures, but no reports showing that the process was exercised.
No, not automatically. ISO 27001 helps a lot, but NIS2, KSC, incident reporting, scope and national requirements must be assessed separately.
Usually compliance, CISO, vCISO, risk or the ISMS owner. Owners of specific evidence should be in IT, security, HR, legal, procurement, finance and business teams.
Start with an evidence matrix: requirement, evidence, owner, date, status and gap. Then complete the key areas: risk, access, backup, incidents, suppliers and training.
Compliance evidence for NIS2, KSC and ISO 27001 should show that cybersecurity works in practice. A policy, presentation or declaration alone is not enough. Reports, tests, logs, decisions, reviews and corrective actions are needed.
The most important evidence groups are: scope and applicability, board decisions, risk, policies, Statement of Applicability, access control, backup, incident response, vulnerabilities, suppliers, training, monitoring, audits and corrective actions.
The best approach is one repository and one evidence matrix connecting NIS2, KSC, ISO 27001, customers and insurers. Then the company does not prepare for audits in panic. It has an evidence system that works every day.
NIS2 Penalties: What Management Boards Need to Know About the New Directive
NIS2 penalties may reach millions of euros or a percentage of global annual turnover, but the numbers alone are not the most important issue for the board. NIS2 moves cybersecurity into management accountability: the board must approve cyber risk management measures, oversee implementation, understand incident reporting duties and ensure compliance evidence. Penalties are not only about the incident itself, but about poor risk management, missing reporting, ignored supervisory orders or lack of real controls.
Prepared by: CCyber Editorial Team
NIS2 penalties can be very high, but management boards should not treat the directive only as a sanctions topic. NIS2 requires organizations in scope to have a real cyber risk management system, incident reporting procedures, supplier oversight, business continuity, training, access control, supply chain security and implementation evidence. The directive states that for essential entities the maximum administrative fine must be at least EUR 10 000 000 or 2% of total worldwide annual turnover, whichever is higher. For important entities, the threshold is at least EUR 7 000 000 or 1.4% of turnover. However, details in Poland must be checked in the national law implementing NIS2 because the directive is implemented through national legislation.
July 2026
NIS2 is a European Union directive. This means Member States must implement its requirements into national law. The directive defines a minimum level of requirements, including the minimum level of maximum fines, but the detailed control process, supervisory authority, procedures, national definitions and sanctions come from the implementing law in each country.
For the board, the practical conclusion is simple: knowing the directive text is not enough. Three things must be checked:
In Poland, NIS2 implementation is connected with the Act on the national cybersecurity system and its amendment. Therefore, in practice, the board should work with the current national law, not only with general NIS2 presentations.
For essential entities, the directive provides that infringements of cyber risk management and incident reporting obligations may be subject to administrative fines with a maximum level of at least:
For important entities, the directive provides a maximum penalty level of at least:
This wording is important. NIS2 defines the minimum level of maximum penalties that Member States must ensure. National rules may include their own procedures, conversions, periodic penalties, rules for public administration and additional supervisory measures.
Not every incident automatically means a penalty. Cybersecurity is not a promise that an incident will never happen. The regulation looks at whether the organization managed risk appropriately for its scale, sector, threats and impact on services.
The penalty risk increases when the company:
The key message for the board: the authority will not assess only that something happened. It will assess whether the company acted reasonably, proportionately, on time and with evidence.
NIS2 requires technical, operational and organizational measures. This is not only a firewall or antivirus. It is a full cyber risk management system.
Risk areas include, among others:
NIS2 introduces strict deadlines for reporting significant incidents. In simplified terms, an organization should prepare for:
The practical problem is that the company must have a process that works under stress. It is difficult to prepare a good notification within 24 hours if nobody knows in advance who decides, who gathers facts, who contacts the CSIRT, who informs the board and who manages communication.
NIS2 requires management bodies to approve cyber risk management measures and oversee their implementation. The board cannot limit itself to saying “IT handles this”.
In practice, the board should have:
The risk of sanctions increases when the company receives recommendations, orders or audit findings and does not act. NIS2 provides a broad set of supervisory measures, not only financial fines.
In practice, the authority may require, among other things:
Evidence matters in NIS2 compliance. A company may have good technical actions, but if it cannot document them, it will be harder to defend its approach before an authority, auditor or customer.
Evidence may include:
NIS2 clearly raises cybersecurity to board level. This does not mean every board member must configure systems. It means the board must understand risk, approve direction, oversee implementation and provide resources.
NIS2 requires Member States to ensure that it is possible to hold responsible persons or legal representatives of essential entities liable for breaches of their duties to ensure compliance. The directive also provides for the possibility of a temporary prohibition from exercising managerial functions in certain cases involving essential entities, in accordance with national law and procedural safeguards.
This does not mean that every outage or incident automatically leads to personal liability for a board member. It does mean, however, that the board should treat cybersecurity as an oversight obligation, not only a technical IT task.
NIS2 distinguishes essential and important entities. This distinction affects, among other things, supervision, authority approach and maximum penalty levels.
These are usually organizations in sectors of highest criticality, where disruption may have a particularly important impact on society, economy, public safety or continuity of important services.
These are organizations in scope that must also meet NIS2 requirements, but are subject to a different supervisory model and lower minimum thresholds for maximum fines.
The board should not guess the category. It should request a formal applicability assessment covering sector, company size, type of services, group dependencies, country of operation and national rules.
NIS2 covers a broad range of sectors. The European Commission states that the directive establishes a framework for 18 critical sectors across the European Union.
The regulatory scope may depend on national details, organization size and service type. That is why an applicability assessment should be the first step.
After a serious incident, an authority or customer may ask not only what happened. Questions usually focus on how prepared the organization was before the incident.
The worst answer is: “we do not know”, “there was no owner”, “there was no procedure”, “we did not test it”, “we have no evidence”.
The best answer is: “we had a process, we know the scope, we reported on time, we have logs, we have a report, we have board decisions, we have a remediation plan and we can show evidence”.
First, determine whether the company is subject to the regulation and in which role.
The assessment should include:
Evidence to prepare: NIS2 applicability assessment report and board decision on next steps.
The company should compare the current state with NIS2 requirements. This should be about practical gaps, not only a list of documents.
Check:
Evidence to prepare: NIS2 gap analysis with priorities and action plan.
The board needs to see cybersecurity as business risk. The risk register should show impact on services, customers, revenue, business continuity and compliance.
The register should include:
Evidence to prepare: cyber risk register approved or periodically reviewed by the board.
The company must know how to act in the first hours of an incident. NIS2 requires fast reporting, so the process must be exercised.
The plan should state:
Evidence to prepare: incident response plan and tabletop exercise report.
NIS2 strongly emphasizes supply chain security. The company should know which suppliers are critical and what risks they create.
The supplier programme should include:
Evidence to prepare: supplier register and supply chain risk assessment report.
The board should receive a regular, understandable report. It does not need excessive technical detail, but it must show risk, decisions and progress.
The report should cover:
Evidence to prepare: recurring NIS2 dashboard for the board.
IT can implement many controls, but accountability concerns the whole organization: board, risk, legal, suppliers, finance, HR, communication and business continuity.
Penalties matter, but a better question is: can the company ensure service continuity, report an incident on time and show evidence of risk management?
The company assumes NIS2 does not apply because it is not large critical infrastructure. The NIS2 scope is broader than previous rules.
Without evidence, it is hard to show that measures were implemented, tested and supervised.
Reporting deadlines are short. Without an exercise, the company may lose valuable hours defining roles and communication channels.
ICT suppliers, cloud providers, software providers, integrators and outsourcing companies may create significant risk.
NIS2 requires management body members to have the knowledge needed to understand cyber risk and risk management practices.
The board may accept risk, but it should do so consciously, based on data, not through lack of decision.
A technology company provides services to healthcare and industrial customers. The board initially assumes NIS2 mainly concerns critical infrastructure operators, so the topic is postponed. After analysis, it turns out the company may be an important supplier in the chain of services covered by customer requirements, and some NIS2 obligations will affect contracts, audits and security expectations.
The company performs a gap analysis. The largest gaps are lack of a formal risk register, untested incident response, no recurring access review, weak backup evidence, no supplier assessment and no cyber reporting to the board. The IT team had many good practices, but they were not structured or documented.
The board approves a 90-day plan: applicability assessment, risk register, tabletop, MFA for critical accounts, restore test, supplier programme and dashboard. After three months, the company is not “ready for everything”, but it has evidence, owners and a plan. This significantly reduces sanction risk and improves business resilience.
ccyber.io helps boards and security teams prepare organizations for NIS2 in a practical, measurable and evidence-based way. We do not start from documents for documents. We start from applicability, risk, critical services, incidents, suppliers and board accountability.
We can support your organization with:
The best first step is a NIS2 Board Readiness Workshop. In a short workshop, the company can determine whether it is subject to NIS2, what the key risks are, what the board must know, which decisions are needed and which actions should start immediately.
For essential entities, the directive sets a maximum fine level of at least EUR 10 000 000 or 2% of worldwide annual turnover. For important entities, at least EUR 7 000 000 or 1.4% of turnover. Details depend on national law.
Yes. NIS2 requires management bodies to approve cyber risk management measures, oversee implementation and be potentially liable for infringements, according to national law.
Not every incident automatically leads to a fine. The risk increases when the company lacks adequate measures, fails to report, ignores recommendations or cannot show evidence.
An essential entity usually has higher criticality and is subject to stronger supervision and higher fine levels. An important entity must also meet requirements, but is subject to a different supervision model and lower penalty thresholds.
First, request a NIS2 applicability assessment, then gap analysis, risk register, action plan, incident reporting plan and governance dashboard.
Yes. The directive requires members of management bodies to follow training that allows them to understand cyber risks and assess risk management practices.
ISO 27001 can help significantly because it organizes information security management, risk, controls and continual improvement. However, it does not automatically replace NIS2 analysis, incident obligations and national requirements.
Start with four things: applicability assessment, risk register, incident plan with 24 and 72-hour deadlines, and board report with priorities and budget.
NIS2 penalties are high, but the biggest change is not only the level of sanctions. The biggest change is that cybersecurity becomes a formal topic of board oversight, evidence and organizational accountability.
The board should understand whether the company is in scope, which services are critical, what the top risks are, whether the company can report an incident on time, whether suppliers are under control and whether evidence of implemented security measures exists.
The best response to penalty risk is not panic or documentation alone. The best response is a practical NIS2 readiness programme: applicability assessment, gap analysis, risk register, incident response, suppliers, training, tests, metrics and recurring board oversight.
AI-Powered Phishing: How AI Changes Scams and How to Prepare Employees
AI changes phishing because scammers can create fluent, personalized and multi-channel messages, conversations and fake scenarios faster. AI-powered phishing may look like an email from a supplier, a message from the CEO, a call from helpdesk, a delivery SMS, a deepfake meeting or a customer request for documents. Employees should be trained not only to recognize scams, but mainly to respond safely: stop, verify through a second channel, never share MFA codes, do not bypass procedures and report suspicious contact.
Prepared by: CCyber Editorial Team
AI-powered phishing is phishing supported by artificial intelligence. This does not mean every attack is fully automated or highly advanced. It means the attacker may use AI to write a better message, translate it into the recipient’s language, match a specific person’s style, prepare a fake document, clone a voice, create a deepfake or run a more convincing conversation. For employees, the main change is simple: a message without errors, familiar tone, correct language and credible voice are no longer sufficient proof of authenticity. Companies should train employees not only to recognize phishing, but to respond correctly: stop, check context, verify through a second channel, do not share MFA codes, do not bypass procedures and report suspicious situations.
July 2026
AI-powered phishing is a practical term for phishing attacks where the fraudster uses artificial intelligence to prepare or conduct the scam. It may involve text, voice, image, analysis of public information, conversation automation or creating many variants of the same message.
In practice, AI can help the attacker with:
You do not need to assume that every attack is highly advanced. Sometimes, the fraudster only uses AI to write a better email. That alone may increase attack effectiveness.
For years, employees were told that phishing can be identified by language mistakes. This is now a weaker signal. AI can write fluently, naturally and in the recipient’s language.
The attack may refer to the employee’s real role, department, project, customer, event, social media post or information from the company website.
The fraudster can generate many versions of the same message, adapt them to different recipients and quickly test which scenario works best.
The attack may begin by email, then move to phone, Teams, SMS or WhatsApp. AI can help keep the scenario consistent across channels.
Phishing no longer needs to be text-only. The attack may include a voice message, a call with a cloned voice or a fake online meeting.
AI can help create a document, email history, meeting note, project summary or message that looks like a natural part of work.
An employee may think: “this sounds normal”. The problem is that today’s phishing may sound exactly like that. Procedure is more important than intuition.
The most important change for the employee: it is not enough to judge whether the message looks professional. You need to judge whether the request makes sense, follows procedure and requires independent verification.
The message is correct, polite and refers to a real service. The attachment includes an invoice or a link to download a document. The bank account may be different than before.
A finance employee receives an urgent request for payment, bank account change or document preparation. The style may be similar to the manager’s real communication.
The fraudster pretends to be IT and says there is an issue with the account. They ask for an MFA code, login approval, tool installation or screen sharing.
The employee receives a message that looks like a request from a colleague, customer or supplier. The link leads to a fake login page or file.
The attack may look like a message from a courier, bank, service provider, manager or customer. AI can help adapt the language and create a more credible text.
The employee receives a document or poster with a QR code. The code leads to a fake login, payment page or form. Because the link is not visible immediately, some filters and users may assess it poorly.
Sales, customer service or project managers receive a brief, contract, specification or order. The document looks normal, but leads to a fake login, malicious file or data request.
The attacker uses fake image or voice to make an instruction credible during a meeting. The goal may be payment, process change, document transfer or access granting.
The fraudster calls with a voice that sounds like a known person. They may impersonate the CEO, manager, customer, supplier or IT employee.
An employee uses AI to summarize an email, document or webpage. If the AI tool analyzes external content, it may be manipulated by a hidden instruction. This is especially important for chatbots, RAG and AI agents.
“Do this now”, “the customer is waiting”, “the board already approved it”, “we do not have time for procedure”.
“Do not tell anyone”, “this is confidential”, “do not involve the team”, “paperwork later”.
MFA codes are private. Nobody should ask for them by email, phone, SMS, Teams or messenger.
Every change of payment details requires independent confirmation. Even if the message looks credible.
The CEO writes from a private messenger, a supplier asks for documents through a new address, a customer contacts from an unknown number.
Fraudsters often say the situation is exceptional. A good procedure should work exactly in exceptional situations.
The attachment or link may look professional. It is still worth checking whether it was expected and comes through the correct channel.
If the caller insists that you must not call back, ask your manager or verify through another channel, that is a strong red flag.
Correct language does not mean safety. AI can create error-free messages.
The attacker may match a person’s or organization’s style, especially if they have access to previous correspondence or public content.
Voice may be cloned. Decisions about money, data or access should not rely only on someone sounding familiar.
A fake invoice, offer or brief may look very good. Source and process verification matter.
Phishing does not always include an attachment. It may be a conversation, reply request, bank account change, QR code or fake login.
An employee may not always recognize AI. But they can always use a procedure.
Simple response model:
A second channel is an independent method of confirming a request. Do not use the phone number, link or address included in the suspicious message. Use contact details known beforehand.
A second channel should be mandatory for:
Employees should remember one rule: MFA codes are never shared. Also, a login notification that the user did not initiate should never be approved.
Training should cover:
The most effective training concerns real work. Finance, HR, IT, sales and the board should be trained differently.
An employee should be able to quickly report an email, phone call, voice message, SMS, messenger message or online meeting. Reporting must be simple and psychologically safe.
Do not measure only attendance. Measure whether employees report, verify, refuse to share MFA codes and follow procedures.
The biggest risks are payments, invoices, supplier bank account change and pressure from people impersonating executives.
Practice:
The biggest risks are password reset, MFA code, administrator access, remote support and user impersonation.
Practice:
The biggest risks are fake candidates, attachments, personal data, deepfake in an online interview and payroll-related fraud.
Practice:
The biggest risks are fake customer, link to a document, data request, contact address change and CRM information theft.
Practice:
The biggest risks are fake campaigns, deepfakes, advertising scams, links to assets, fake requests for social account access and use of AI tools without assessment.
Practice:
The biggest risks are authority-based fraud, voice cloning, deepfakes, secrecy requests, time pressure and a culture of bypassing procedures.
Practice:
The employee must know where to report a suspicious message, call, SMS, messenger message or online meeting.
Describes when a request must be confirmed through an independent channel and which channels are accepted.
Defines amount thresholds, approvals, roles, two-person approval and the ban on payments outside process.
Every bank account change should require independent verification through previously known contact details.
Helpdesk must have clear identity verification rules, especially for urgent and unusual requests.
Employees should know they may end the call, avoid sharing information and report the situation.
Employees should know which data must not be entered into unapproved AI tools and how to request approval for a new tool.
AI-powered phishing can arrive by phone, SMS, Teams, LinkedIn, WhatsApp, QR code, document or online meeting.
They may not always recognize it. That is why response procedure matters more than judging whether content looks artificial.
Clicks matter, but reports, second-channel verification, MFA refusals and response time matter as well.
If the company has no clear verification procedure, the employee is left alone with a pressured decision.
This reduces reporting. Employees hide mistakes, and the company loses response time.
The board is often used as a pressure element. Board members must support procedures even when the issue looks urgent.
Helpdesk is a target because it can reset passwords, help with access and manage accounts.
Attacks change quickly. Training should be updated after incidents, new scenarios and changes in how work is done.
A services company notices an increase in suspicious messages sent to finance and sales. The messages are well written, refer to real customers and look like normal communication. One email asks for a supplier bank account change, while another contains a link to an alleged customer brief.
The company does not stop at another phishing presentation. It creates an AI-powered phishing readiness programme. Finance practices bank account changes and urgent payments. Sales practices fake customer briefs. IT practices a call from someone asking for password reset. The board practices voice cloning and time pressure.
After 90 days, the company sees more reports, fewer decisions made under pressure and better use of second-channel verification. Employees do not need to recognize whether the message was written by AI. It is enough that they know when to stop, verify and report.
ccyber.io helps companies prepare employees for AI-powered phishing, vishing, voice cloning, deepfakes, fake invoices, MFA code theft and authority-based fraud. We do not focus only on theory. We build scenarios, procedures, exercises and behavior metrics.
We can support your organization with:
The best first step is an AI Phishing Readiness Workshop. In a short workshop, the company can identify which teams are most exposed, which scenarios are realistic, which procedures need improvement and which exercises should be launched in the first 30 days.
It is more like a new version of a known problem. AI helps fraudsters create more convincing messages, voices, documents and scenarios, but the goal remains similar: money, data, passwords, access or MFA code.
Sometimes, but this should not be relied on. A stronger protection is procedure: second channel, reporting, two-person approval and no MFA code sharing.
Messages can be grammatically correct, personalized, multi-channel and better matched to company context.
Finance, accounting, IT, helpdesk, HR, sales, customer service, executive assistants and people who approve payments, access or data transfers.
No. AI-powered phishing may include phone calls, voice messages, messengers, QR codes, online meetings, fake documents and deepfakes.
Measure reports, second-channel verification, refusals to share MFA codes, correct reactions in exercises, response time and procedure exceptions.
Do not act under pressure. If a request concerns money, data, access, password or MFA code, verify it through a second channel and report the suspicious situation.
Start with a company-specific AI phishing scenario list, second-channel rule, MFA code sharing ban, simple reporting channel and training for high-risk teams.
AI changes phishing because it removes many old warning signs. Messages can be correct, voice can sound familiar and documents can look professional. This does not mean employees are helpless. It means they must be trained differently.
The best training is not about guessing whether something was generated by AI. It is about practicing behavior: stop, verify through a second channel, do not share MFA codes, do not bypass procedure, report suspicious contact.
Companies that prepare employees for AI-powered phishing will detect attacks faster, reduce losses and build a culture where caution is part of professional work, not an obstacle to action.
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.