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.
Ransomware Checklist for Companies
A ransomware checklist helps a company prepare for an attack, reduce the impact of data encryption and return to operations faster. The key elements are backups, MFA, patching, segmentation, monitoring, incident response plan, crisis communication, contact list, recovery testing and clear board decisions before an incident happens.
Prepared by: CCyber Editorial Team
A ransomware checklist for companies should cover three stages: preparation before an attack, response in the first hours and safe recovery. Before an attack, the company needs tested backups, MFA, patching, segmentation, monitoring, contact list and communication plan. After ransomware is detected, the company must quickly isolate infected systems, preserve evidence, activate the crisis team, assess the attack scope, protect backups and recover systems only from clean sources.
July 2026
Ransomware is a type of malware or attack that blocks access to systems or encrypts data and demands payment to unlock it. In many modern attacks, criminals also steal data and threaten publication, contact with customers, media exposure or further business disruption.
Ransomware impact may include:
Ransomware is a business problem, not only a technical one. It affects the board, finance, operations, legal, communications, IT, security, customers and suppliers.
The company must know which systems determine its survival after an attack. Not all systems are equally important. Email, finance, production, CRM, sales systems, ERP, code repositories and management documents require different treatment.
Prepare a list of:
Evidence to prepare: critical system register with recovery priority.
MFA should cover email, VPN, remote access, cloud systems, administrator accounts, financial systems and developer tools. A stolen password without MFA may be enough for an attacker to enter the environment.
Protect first:
Evidence to prepare: report of users and applications covered by MFA and exception list.
Ransomware often starts with compromised remote access, vulnerable VPN, exposed remote desktop or a supplier account. Remote access should be limited to what is necessary.
Check:
Evidence to prepare: remote access, supplier and exception register.
Vulnerabilities in VPNs, firewalls, mail servers, remote access systems and public applications are especially dangerous. These are often the first places attackers check.
Patch priority:
Evidence to prepare: vulnerability report and patch status of critical systems.
Ransomware spreads faster when users and administrators have excessive permissions. The more access a compromised account has, the greater the impact.
Check:
Evidence to prepare: access review report and removed excessive permissions list.
Segmentation limits ransomware spread. If the whole company works in one flat network, attackers can more easily move between computers, servers, backups and production systems.
Separate:
Evidence to prepare: segmentation diagram and list of allowed connections between segments.
Backups are one of the most important controls. They must be regular, tested, separated from the main environment and protected against deletion by attackers.
A good backup strategy includes:
Evidence to prepare: latest recovery test report and critical system backup list.
Ransomware usually does not start with encryption. Before that, there may be phishing, account takeover, network scanning, lateral movement, disabling security tools, data theft and backup deletion.
Monitor:
Evidence to prepare: ransomware alert list and escalation procedure.
The plan should be short, practical and available even when the company cannot access email, network drives or the ticketing system.
The plan should include:
Evidence to prepare: ransomware response plan available offline.
During an attack, normal communication channels may not work. Email, chat, internet telephony or ticketing may be unavailable. The company needs an alternative communication plan.
Prepare:
Evidence to prepare: crisis communication plan and message templates.
Do not start with chaotic calls to everyone. Activate the predefined crisis team. It should include IT, security, board, legal, communications, operations and owners of critical systems.
Goal: one decision structure, one priority list, one version of the truth.
If infected devices are known, disconnect them from wired networks, Wi-Fi and other connections. Do not connect backup media to suspicious devices.
Note: do not blindly shut everything down if this may destroy evidence or make analysis harder. The shutdown decision should be made with the technical incident lead.
Immediately check whether the attacker has access to backup systems. If needed, separate backups from the production environment, block suspicious accounts and preserve backup metadata.
Block accounts used in the attack, accounts with suspicious logins and accounts whose credentials may have been compromised. Priorities are administrators, VPN, email, cloud accounts and supplier accounts.
Check VPN, remote desktop, administrative tools and supplier access. If an active attacker session is suspected, terminate it and preserve logs.
Save the ransom note, screenshots, encrypted file names, wallet addresses, attacker website addresses, logs, affected host list and detection time.
If corporate email is affected or may be monitored by attackers, switch the crisis team to an alternative communication channel.
Answer:
Common entry points are phishing, compromised account, vulnerable VPN, exposed remote desktop, public application vulnerability, supplier or stolen credentials.
If the entry point is not identified, the company may restore systems and the attacker may return through the same path.
Many ransomware attacks include data theft before encryption. Check unusual data transfer, access logs, archives created on servers, outbound connections and communication with unusual locations.
Not everything must be restored at once. First restore the minimum ability for the company to operate.
Example sequence:
Ransomware may trigger incident notification, personal data breach notification, customer notification, insurer notification, regulator notification, CSIRT notification or law enforcement reporting.
Involve legal, data protection, compliance and the board. Do not rely only on IT’s technical assessment.
Communication must be clear, consistent and careful. Do not promise that data was not stolen if analysis is still ongoing. Do not publish technical details that may help attackers.
Prepare communications for:
Do not restore systems from a backup that has not been checked. Ransomware or attacker tools may have entered backups before the company detected the incident.
Before recovery, check:
Recovering business systems does not make sense if the core infrastructure is still compromised.
First rebuild:
Assume that some passwords and secrets may have been compromised. This includes user passwords, administrator passwords, service accounts, API keys, tokens, cloud credentials and supplier credentials.
After recovery, attackers may try to return. Monitoring should be increased for at least several weeks after the incident.
Monitor:
Recovery is not the end. If the company restores the environment with the same passwords, same remote access, no MFA and the same vulnerabilities, the risk of attacker return is high.
The decision to pay a ransom is a board, legal, operational and ethical decision. It should be made after consultation with legal counsel, insurer, incident response specialists and law enforcement where applicable.
Key facts:
The best strategy is to prepare the company so that paying is not the only survival option.
A backup that has not been tested is hope, not a strategy. The company must regularly check whether it can restore data and systems within an acceptable time.
Attackers often try to delete or encrypt backups. Backups should be protected against deletion, offline or immutable.
Without MFA, a stolen password may give an attacker access to critical systems. Administrators and remote access must be protected first.
The plan, contact list and procedures must also be available offline. If they are only on an encrypted network drive, they will not help during a crisis.
Lack of consistent communication may deepen the crisis. Employees, customers, media and regulators should receive clear, approved and current information.
If the company does not know how the attacker entered, it may restore the environment and be attacked again.
The hardest decisions should not be made for the first time at 3 a.m. The board should define principles for communication, payment, recovery priorities and authority contact earlier.
A manufacturing company has 250 employees. It has ERP, file server, cloud email, several production systems and remote access for suppliers. The board assumes backups work because the backup system sends positive daily notifications.
During a ransomware exercise, it turns out that nobody has tested ERP recovery for more than a year, file server backups are accessible from the same domain, a supplier has permanent VPN access without MFA and the response plan exists only on a network drive.
The exercise shows that the biggest problem is not the lack of one tool. The problem is lack of operational readiness.
The company implements MFA for administrators and VPN, separates critical data backups from the main environment, prepares an offline contact list, tests ERP recovery and creates a first 24-hour response plan.
After 90 days, the board sees a concrete change: the company knows what to recover first, how long it takes, who makes decisions, how to communicate with customers and which gaps still need to be closed.
ccyber.io helps companies prepare for ransomware practically, without excessive theory and without assuming that one tool solves the problem. We focus on operational readiness, backups, response plan, communication, board decisions and recovery testing.
We can support your organization with:
The best first step is a short ransomware readiness assessment. It helps check whether the company has working backups, a recovery plan, access control, prepared communication and board decisions for a real attack.
Ransomware is an attack where criminals block access to systems or encrypt data and demand payment. In many cases, they also steal data and threaten to publish it.
The most important protections are tested backups, MFA, patching, remote access restriction, segmentation, monitoring and an exercised response plan.
Not always. Backups must be offline or protected against deletion, regularly tested and checked before recovery. The company must also close the attacker’s entry point.
Activate the crisis team, isolate infected devices, protect backups, block suspicious accounts, preserve evidence and determine the scope of the attack.
There is no guarantee of data recovery after payment. The decision requires legal, operational and board-level analysis. The best strategy is to prepare the company so that payment is not the only option.
It depends on sector, country, data type and incident impact. Notification may be required to a regulator, CSIRT, data protection authority, insurer, customers or law enforcement.
At least once a year, and more often in higher-risk companies. Both the technical side and board decisions, communication and system recovery should be exercised.
The board should receive information about critical systems, backup status, recovery test results, MFA level, remote access, major gaps and the budget needed to reduce risk.
A ransomware checklist for companies should not be only a document in a security folder. It should be a practical tool that helps prepare the company, make quick decisions and return to operation after an attack.
The key elements are ransomware-resistant backups, MFA, patching, segmentation, monitoring, remote access restriction, response plan, crisis communication and regular exercises.
Companies that prepare these elements earlier do not eliminate risk completely, but significantly improve their chances of limiting losses, recovering faster and managing the crisis more calmly.
MFA for Companies: How to Implement It Without Chaos?
MFA, or multi-factor authentication, makes account takeover much harder even when a password is stolen. A good MFA rollout is not just switching it on for everyone at once. Companies need to prepare users, applications, backup methods, emergency access, administrators, exceptions, monitoring and a phased implementation plan.
Prepared by: CCyber Editorial Team
MFA for companies should be implemented in stages: first administrator accounts and critical systems, then email, VPN, cloud applications, financial systems and remaining users. To avoid chaos, companies should first prepare a list of users and applications, choose the right MFA methods, provide backup methods, define account recovery, train employees, run a pilot and only then enforce MFA in waves. The best long-term direction is phishing-resistant MFA, such as security keys and passkeys.
July 2026
MFA, or multi-factor authentication, is a login method that requires more than one proof of user identity. In simple terms: the password alone is not enough. The user must confirm the login using an additional factor.
Common authentication factors are:
MFA reduces account takeover risk because an attacker who steals a password still needs to pass additional verification. However, not every MFA method provides the same level of protection. Some methods can be bypassed through phishing, fake login pages, session theft, phone attacks or notification fatigue.
User accounts are one of the most common entry points into organizations. A compromised mailbox, administrator account, VPN account or cloud account may give an attacker access to data, documents, invoices, conversations, customers, systems and internal tools.
MFA helps reduce the risk of:
For boards, MFA is one of the most practical security controls because it directly reduces account takeover risk and is easier to implement than many advanced security projects.
MFA itself is not difficult. The difficult part is deploying it across the organization without blocking employees, administrators, integrations, legacy applications and business processes.
Common causes of chaos:
A good MFA rollout is an organizational project, not only an admin panel setting.
For administrators, board members, finance, IT, remote access and critical systems, the best direction is phishing-resistant MFA.
Best methods:
Phishing-resistant methods matter because they do not rely on copying a code from a phone into a fake website. They are bound to a specific domain or service, which makes classic credential phishing significantly harder.
For most employees, an authenticator app is a good starting point, especially if it supports number matching, login context or passwordless sign-in.
Practical methods:
SMS and voice calls are better than no MFA, but they should not be the target method for privileged accounts and critical systems.
SMS and voice limitations:
Practical recommendation: if a company starts with SMS, it should have a migration plan to stronger methods.
Administrator accounts should be protected first. A compromised administrator account may allow an attacker to disable security controls, add accounts, change access rules or steal data.
Email is one of the most important systems. A compromised mailbox can be used for phishing, payment fraud, password resets and document access.
Remote access without MFA is high risk. If a user password leaks, an attacker may try to log in to the company network.
Microsoft 365, Google Workspace, CRM systems, project tools, HR tools, code repositories and financial systems should be covered by MFA.
Finance, payment, invoice and banking accounts should use stronger methods because compromise may directly lead to financial loss.
Software houses and SaaS companies should protect code repositories, CI/CD systems, cloud accounts, ticketing systems and deployment tools with MFA.
The MFA project should have an owner. In a small company, this may be an IT administrator or security owner. In a larger organization, involve IT, security, helpdesk, HR, internal communication, system owners and the board.
The owner should coordinate:
Evidence to prepare: decision naming the MFA project owner, responsibility scope and supporting team list.
Do not start with configuration. First identify what the company has and what must be protected.
Prepare a list of:
Evidence to prepare: register of users, privileged accounts and applications covered by MFA.
Not all users have the same risk. An administrator, finance user, board member and standard office user should not have identical requirements.
Example grouping:
Evidence to prepare: user group list and required MFA methods for each group.
Match the method to risk, system and user experience. Do not choose a method only because it is the easiest to enable.
Example approach:
Evidence to prepare: MFA method matrix by user group and application type.
The company must have a plan for situations where an administrator loses a phone, security key or MFA method. Emergency access must not become a backdoor for attackers, but lack of emergency access may block the company during a crisis.
Prepare:
Evidence to prepare: emergency access procedure and emergency account test report.
Users will lose phones, change devices, forget PINs, travel abroad and need help. Account recovery must be secure and fast.
The procedure should define:
Evidence to prepare: MFA recovery procedure, authorized staff list and reset register.
MFA affects everyday work. Employees must know why the company is implementing MFA, what they need to do, by when, which method to choose and where to get help.
Communication should include:
Evidence to prepare: employee communications, instructions and training materials.
A pilot helps detect problems before deploying MFA across the whole company. The pilot should include different types of users, not only IT.
Include in the pilot:
Evidence to prepare: pilot report, issue list and decisions before broad deployment.
Do not deploy MFA to everyone on one day if the organization is not ready. Deployment waves are better: administrators, high-risk groups, email, VPN, cloud applications and then the rest of the company.
Example sequence:
Evidence to prepare: deployment wave schedule, enrollment status and exception list.
Some older applications may not support modern MFA. This does not mean they can be left unprotected. Risk must be reduced in another way.
Possible actions:
Evidence to prepare: legacy application list and risk reduction plan.
After MFA deployment, check who registered, which methods are used, who uses weaker methods and where login errors appear.
Monitor:
Evidence to prepare: MFA dashboard, enrollment report and exception report.
MFA exceptions should be rare, justified, time-limited and approved. Every permanent exception becomes a risk.
Regularly check:
Evidence to prepare: MFA exception register and monthly exception review.
In Microsoft Entra, MFA is usually best enforced through Conditional Access policies. This allows MFA to depend on user, application, risk, location, device and access type.
Administrator accounts should have MFA from the beginning. For administrators, stronger methods such as security keys, passkeys or other phishing-resistant methods are recommended.
A user should have more than one method. This reduces lockouts and helpdesk tickets.
MFA registration should be communicated in advance. Users should know where to register a method and how to check their settings.
Legacy authentication protocols may weaken modern controls. Check whether the organization has applications or mail clients using older login methods.
Google Workspace allows 2-Step Verification deployment for organizational units and groups. This supports phased implementation and pilots for selected teams.
Before enforcing MFA, check which users registered a method, who has not and which groups need support.
For administrators, finance and high-risk users, security keys or passkeys should be required where available and well supported by the environment.
Before enforcement, users should be informed, given time to enroll and supported if they lose access to their MFA method.
Without a pilot, the company may block users, applications, integrations and helpdesk. A pilot helps detect problems earlier.
Users lose phones, change devices and travel. Without a backup method, lockouts and support tickets increase.
An attacker may try to bypass MFA through helpdesk. MFA reset must include strong identity verification and decision logging.
Administrators should have stronger methods than standard users. Security keys or passkeys are preferable for them.
Exceptions often start as temporary and become permanent. Every exception should have an owner, reason and expiration date.
Legacy applications and protocols can weaken MFA deployment. They must be inventoried and a migration or compensating control plan should be prepared.
An employee who does not understand the change may click randomly, report issues or delay registration. Communication and instructions are part of security.
SMS may be a transitional method, but for high-risk accounts it should be replaced with stronger methods.
A services company has 120 employees and uses Microsoft 365, CRM, VPN, a financial system and several SaaS applications. The board wants to “enable MFA as quickly as possible” because a customer requires evidence of email and remote access protection.
The IT team first performs a short review. It turns out that administrators do not have separate accounts, some users use personal phones, several applications use legacy authentication and helpdesk has no MFA reset procedure.
The company does not enable MFA for everyone on one day. It first protects administrators, prepares communication, runs a pilot, creates an account recovery procedure, defines emergency accounts and selects MFA methods.
After 90 days, MFA covers email, VPN, the financial system and most cloud applications. SMS remains only as a transitional method for selected users, administrators have stronger methods and the board receives a report on enrollment, exceptions and the next migration plan toward phishing-resistant methods.
ccyber.io helps companies implement MFA without chaos, user lockouts and uncontrolled exceptions. We focus on a practical rollout plan, risk-based method selection, administrator protection, employee communication and evidence for customers and audits.
We can support your organization with:
The best first step is a short MFA readiness assessment. It helps identify which accounts and applications are most important, which MFA methods are available, where problems may appear and how to deploy MFA in the first 30, 60 and 90 days.
MFA means multi-factor authentication. It means login requires more than a password, for example an authenticator app, security key, passkey or another additional factor.
Not all MFA eliminates phishing. SMS and one-time codes can be phished. The best protection comes from phishing-resistant methods such as FIDO2/WebAuthn security keys and passkeys.
SMS is better than no MFA, but it should not be the target method for administrators, finance, board members and critical systems. It is better treated as transitional.
The best starting point is administrators, email, VPN, cloud systems and financial systems. Before broad deployment, prepare a pilot, communication, backup methods and account recovery.
No. The method should depend on risk. Administrators and users with confidential data access should have stronger methods than standard users.
Run a pilot, inform employees in advance, monitor registration, provide backup methods, prepare helpdesk and define a secure account recovery procedure.
Yes. Single sign-on simplifies access to many applications, but it also means one compromised account may provide access to many systems. MFA should protect the primary identity system.
Yes. MFA is a practical access management control and reduces account takeover risk. It can support requirements related to access control, system protection and risk management.
MFA is one of the most important foundations of company cybersecurity. It protects accounts even when a password is stolen, but only when it is planned, deployed and monitored properly.
The most important approach is staged implementation: administrators and critical systems first, then email, VPN, cloud and the rest of the users. At the same time, communication, helpdesk, backup methods, account recovery, emergency accounts and exception register must be prepared.
Companies that want to avoid chaos should treat MFA as an identity management project, not a one-time settings change. Long term, high-risk accounts should move toward phishing-resistant methods.
Shadow AI: The Hidden Risk of AI Tools in Organizations
Shadow AI means the use of AI tools in an organization without the company’s knowledge, approval or control. It may include personal AI accounts, unapproved apps, plugins, transcription tools, coding assistants and AI agents. The biggest risks are data leakage, confidentiality breaches, lack of vendor control, wrong decisions, legal issues and missing compliance evidence.
Prepared by: CCyber Editorial Team
Shadow AI occurs when employees use AI tools without the organization’s knowledge, approval or control. This usually happens when the company does not provide safe tools, clear rules and a simple approval process. Shadow AI may lead to leakage of customer data, source code, confidential documents, personal data, company secrets and information covered by contracts. The best response is not a ban alone, but visibility, an AI use policy, data classification, approved tools, training, monitoring and an AI incident response process.
July 2026
Shadow AI means using AI tools in an organization outside official company control. It may involve personal accounts, free tools, browser extensions, mobile applications, transcription tools, coding assistants, presentation generators, chatbots or AI agents without approval from IT, security, compliance or legal teams.
Shadow AI is similar to Shadow IT, but the risk can be higher. With Shadow IT, an employee may store files in an unapproved application. With Shadow AI, an employee may enter data into a system that analyzes, processes, summarizes, stores it in chat history, uses it in integrations or passes it further through plugins and external connections.
Examples of Shadow AI:
Shadow AI appears because AI tools genuinely help employees work faster. Employees do not always want to bypass rules. They often want to write an email faster, prepare an offer, summarize a meeting, translate a document, analyze data or generate code.
Common causes:
In practice, Shadow AI is a signal to the board: people want to use AI, but the organization has not yet created a safe and convenient operating model.
Employees may paste customer requests, contracts, correspondence, call recordings, project data, requirements, complaints or implementation documents into AI.
AI tools may receive data about employees, candidates, customers, patients, users or contractors. This may create personal data protection risk.
Developers may send code fragments, logs, errors, configurations, secrets, API keys, database queries or diagnostic data to AI.
AI is often used to summarize strategy, sales plans, board documents, financial information, product roadmaps or business secrets.
Customer data, technical documentation, contract terms, project information and materials covered by NDAs should not go into tools without checking the legal basis, contract and processing rules.
The most obvious risk is entering information into an AI tool that the company should not share with an external provider. This may include a contract, customer data, code, strategy document, financial information or technical secrets.
The problem is that the company may not know that such a data transfer happened. If the tool is used through a personal account, outside company control, it is hard to determine data scope, activity history and accountability.
If an employee enters personal data into an unapproved AI tool, the company may not know who the provider is, where data is processed, how long it is stored, whether it is used to improve the service and whether the right data processing agreement exists.
In technical teams, Shadow AI may lead to leakage of source code, API keys, tokens, configuration files, logs, database schemas and system architecture information.
This risk is especially important for software houses, SaaS companies and digital product manufacturers because code and architecture are part of business value and product security.
An AI tool may look like a simple application, but behind it there is a vendor, models, infrastructure, subcontractors, data storage, terms of use and security posture. Without vendor assessment, the company does not know whether the tool meets security, privacy and compliance requirements.
AI may generate answers that are convincing but incorrect. If an employee uses output without verification, the company may make a wrong legal, financial, technical, HR, sales or operational decision.
Shadow AI can lead to employees treating AI output as truth. This is dangerous when analyzing contracts, vulnerabilities, code, financial data, HR decisions, customer communications and risk assessments.
Shadow AI is not only public chatbots. More SaaS applications include AI features by default. A business team may enable such a feature without IT knowing, and the tool may analyze documents, conversations, support tickets, CRM data or customer history.
An AI agent may take actions, not only return text. If it has access to email, files, CRM, project systems, code repositories or calendars, its permissions should be controlled like the permissions of a technical user.
An unsafe AI agent may perform unauthorized actions, send data, download files, change records or act based on manipulated instructions.
The company may have a security policy, but if it does not know which AI tools are used, it has no control evidence. This makes audits, customer discussions, compliance and incident response more difficult.
Prompt injection is a technique for manipulating a language model application through specially crafted instructions. It may occur when AI processes user content, documents, websites, emails, files or data from external systems.
In the Shadow AI context, the problem is larger because the company may not know:
Unapproved AI tools should therefore be treated not only as a privacy risk, but also as a cybersecurity risk.
The simplest response is banning AI use. In practice, a ban alone often fails. Employees will continue to use tools if they see real value and the company does not provide a safe alternative.
A better approach:
A ban without an alternative creates hiding. Good governance creates visibility.
Shadow AI affects IT, security, legal, data protection, HR, procurement, finance and business teams. Without an owner, the topic will be fragmented.
The owner should coordinate:
Evidence to prepare: AI Security owner decision, responsibility scope and supporting team list.
You cannot control what you cannot see. The first practical step is determining which AI tools employees use and for what tasks.
Include:
Evidence to prepare: AI tool register, business owner, data type, purpose of use and approval status.
Not every AI use has the same risk. Improving the style of an email is very different from analyzing customer data, source code, CVs, medical documentation or contracts.
Example classification:
Evidence to prepare: AI use case register with risk rating.
Employees need to know what must not be entered into unapproved AI tools.
The prohibited list should include:
Evidence to prepare: data classification rules and prohibited data list for unapproved AI tools.
The company should create a list of AI tools allowed for work. Employees should know which tool they can use for which task.
The approved tool list should show:
Evidence to prepare: approved AI tool list and usage rules.
An AI vendor should be assessed like any important technology provider. The company should know where data is processed, how long it is stored, who can access it and which contractual terms apply.
Check:
Evidence to prepare: AI vendor assessment, approval decision and usage terms.
AI tools should be managed like other company systems. Access should be granted, reviewed and removed when an employee leaves.
Minimum baseline:
Evidence to prepare: AI tool user list, roles, MFA configuration and latest access review.
The company should monitor whether confidential data is sent to unapproved AI tools. This is not about reading every employee conversation, but about visibility into data movement and responding to policy violations.
Possible controls:
Evidence to prepare: AI monitoring report, violation list and corrective actions.
AI agents need separate rules because they can perform actions in systems. They should not have more permissions than necessary.
Control:
Evidence to prepare: AI agent register, permission scope, action logs and human approval points.
Shadow AI training should be practical. Employees need examples from their work, not generic slides about artificial intelligence.
Training should cover:
Evidence to prepare: training materials, attendee list, knowledge test and confirmation of policy acceptance.
The company should know what to do if an employee pasted confidential data into an unapproved tool, an AI agent performed an unwanted action or an AI tool disclosed data.
The process should define:
Evidence to prepare: AI incident procedure and AI incident or policy violation register.
Shadow AI should be visible to the board because it affects data, compliance, reputation, vendors and work efficiency. The report should not be technical. It should show risk and decisions.
The report may include:
Evidence to prepare: quarterly AI Security board report.
If employees need AI for work, a ban alone usually moves use to personal accounts and unapproved tools. A better approach combines rules, approved tools and monitoring.
Employees often do not know whether they can paste a contract, CV, customer data, code fragment or internal document into AI. Without a clear list, they will decide on their own.
Shadow AI affects legal, data protection, HR, procurement, sales, customer support and the board. IT alone cannot solve the problem without business support.
A company may block public chatbots while still using AI features in CRM, HR, marketing, customer support and document systems. These features also require assessment.
An AI agent with system access should have limited permissions, logs, approval points and an owner. It should not operate like an invisible unmanaged user.
If the approval process is unclear or too slow, employees will use tools without approval. The process should be simple, fast and understandable.
The company may have good intentions, but without a tool register, vendor assessments, training, logs and reports, it is difficult to show customers or auditors that AI is under control.
A services company has 180 employees. Employees use AI to write offers, translate emails, summarize meetings, analyze contracts and create marketing content. The board believes the company does not officially use AI because it has not bought any enterprise AI tool.
A short assessment shows that employees are using more than a dozen AI tools through personal accounts. Contract fragments, customer data, meeting notes, candidate CVs, code and proposal documents have been entered into these tools. There is no tool list, no vendor assessment, no AI policy and no training.
The problem is not that employees want to use AI. The problem is that the company has not provided them with a safe operating model.
Within 90 days, the company creates an approved tool list, prohibits confidential data in unapproved tools, assesses vendors, enables company login, trains employees and creates a process for requesting new AI tools.
After implementation, the company does not block innovation. Employees still use AI, but in a more controlled way, aligned with risk and explainable to customers and auditors.
ccyber.io helps companies identify and reduce Shadow AI without blocking sensible use of artificial intelligence. We focus on visibility, data, vendors, employees, AI agents, processes and control evidence.
We can support your organization with:
The best first step is a short Shadow AI assessment. It helps determine which AI tools are already used, what data is at risk, which departments need support and which actions should come first.
Shadow AI is the use of AI tools in an organization without the company’s knowledge, approval or control. It may include personal AI accounts, public chatbots, browser extensions, transcription tools, coding assistants and AI features in SaaS applications.
Not every AI use is bad. The problem is lack of control over the tool, data, vendor, permissions and outputs. The goal should not be blocking AI, but managing AI use safely.
The highest-risk data includes customer data, personal data, financial data, confidential documents, business secrets, non-public financial information, restricted source code, passwords, API keys and technical secrets.
Usually not. A ban alone may move AI use to personal accounts and hidden tools. A better approach is approved tools, clear rules, training, monitoring and a simple approval process.
No. Shadow AI may include many tools: chatbots, content generators, meeting tools, coding assistants, AI features in SaaS, plugins, browser extensions and AI agents.
The best approach combines surveys, business team interviews, SaaS application analysis, traffic monitoring to AI tools, procurement review, browser extension control and employee reporting.
Shadow AI is uncontrolled AI use. AI governance is a system of rules, roles, processes, risk assessments, approvals and monitoring that enables controlled AI use.
The best starting point is an AI tool inventory, AI use policy, prohibited data list, approved safe tools, vendor assessment and employee training.
Shadow AI is one of the most important new organizational risks because AI entered daily work faster than policies, training and security controls.
The biggest problem is not artificial intelligence itself. The biggest problem is lack of visibility: the company does not know which tools employees use, what data goes into them, who has access and what vendor terms apply.
The best strategy combines security and usability: approved tools, clear rules, data classification, vendor assessment, access control, monitoring, training and board reporting. This allows the company to use AI faster, but without uncontrolled risk.
PLC, DCS and SCADA Security: A Simple Explanation for Boards
PLC, DCS and SCADA are systems that control production, industrial installations and critical processes. For boards, the key point is that a cyberattack on OT may mean not only data leakage, but downtime, operational losses, human safety risk, process failure and regulatory issues. We explain what management needs to know and where to start.
Prepared by: CCyber Editorial Team
PLC, DCS and SCADA are core elements of OT environments, meaning operational technologies that control physical processes. A PLC controls a machine or part of a process. A DCS coordinates a larger industrial process distributed across multiple controllers. SCADA provides supervision, visualization and data collection from installations or sites. For boards, the key point is that a cyberattack on these systems may stop production, disrupt quality, damage equipment, create human safety risk and trigger regulatory obligations.
July 2026
PLC, DCS and SCADA are elements of the OT environment. OT means operational technology, systems used to monitor or control physical processes. In practice, these systems may affect production, energy, water, transport, buildings, industrial installations, equipment and human safety.
A PLC, or Programmable Logic Controller, controls a specific machine, line, pump, valve, motor, conveyor, robot or part of a process.
A PLC receives signals from sensors, executes programmed logic and sends commands to actuators.
Example:
For the board, a PLC means one thing: if someone changes controller logic or gains unauthorized access to it, they may affect a real physical process.
DCS, or Distributed Control System, is used in larger process installations where many controllers work together as part of one process.
DCS is common in energy, chemicals, refineries, pharmaceuticals, food production, paper industry and other continuous process environments.
For the board, DCS means control of an entire process, not only one machine. Disruption of a DCS may affect product quality, installation safety, production continuity and downtime cost.
SCADA, or Supervisory Control and Data Acquisition, provides supervision, visualization and data collection. It allows operators to see process status, alarms, measurements and events. In some cases, it also allows control commands.
SCADA often connects many sites or devices, including geographically distributed ones.
Examples:
For the board, SCADA means visibility and supervision over the process. If SCADA shows false data or operators lose visibility, operational decisions may be wrong.
In practice, these systems often work together. A PLC may control equipment, SCADA may show the operator the status of that equipment, and DCS may coordinate a larger process where many controllers work together.
PLC, DCS and SCADA security is not only an automation or IT topic. It is a board-level topic because it affects business continuity, downtime cost, human safety, regulatory accountability, reputation and customer relationships.
A cyberattack on OT may cause:
In traditional IT, boards often ask about data, privacy and continuity of business systems. In OT, they must also ask about the physical process, safety, availability, configuration recovery and decisions to stop an installation.
Many organizations do not have a full list of controllers, operator panels, SCADA servers, engineering workstations, software versions, IT connections and vendors with OT access.
This is a basic governance issue: the company cannot protect systems it cannot see.
Automation vendors, integrators and maintenance teams often need remote access. The problem begins when access is permanent, shared, without MFA, without approval, without logs and without time limits.
From a board perspective, remote access to OT should be treated like access to critical systems.
If office and industrial networks are connected without proper controls, an IT incident may move into OT. Ransomware, a compromised account or a compromised laptop may then affect production.
Segmentation is not only one firewall. It means controlling traffic between zones, clear communication rules and exception monitoring.
OT systems often run for many years. Some devices cannot be updated easily because they are part of a process, have vendor restrictions or require a maintenance window.
The board should understand that lack of patching is not always negligence. Sometimes it requires compensating controls: segmentation, monitoring, access restriction and additional procedures.
In OT, normal office file backup is not enough. The company needs copies of PLC programs, DCS configurations, SCADA projects, HMI configurations, recipes, parameters and technical documentation.
Without these copies, recovery after an incident may take much longer than the board expects.
In IT, logins and files are often monitored. In OT, the company also needs to see controller logic changes, commands to devices, new devices in the network, unusual vendor sessions and communication between zones.
If nobody sees changes in PLC, DCS and SCADA, the company may discover the problem only when production stops or the operator sees an alarm.
An IT incident response plan is not enough for OT. OT decisions must include production, automation, maintenance, safety, vendors and the board.
The key question is: who can decide to isolate a segment, stop the process or operate in emergency mode?
A PLC is close to the physical process. It controls what actually happens to a machine, line or device. An attack on a PLC may mean changing control logic, stopping a process, incorrect parameters or loss of control over equipment.
A DCS controls a larger process, often continuous and critical. Failure or compromise of a DCS may affect many elements at once. In such environments, availability, stability, process safety and vendor cooperation are critical.
SCADA provides visibility, alarms, historical data and sometimes control. If SCADA stops working, the operator may lose situational awareness. If SCADA shows false data, the operator may make the wrong decision.
First, understand what exists in the environment. The inventory should include devices, systems, versions, locations, owners, vendors and connections.
Include:
Evidence to prepare: OT asset register with owner, location, criticality and vendor.
The board should know how OT connects to IT, vendors, cloud, ERP, MES, reporting systems and the internet. Many risks come from connections created over years and poorly documented.
Evidence to prepare: IT-OT connection diagram and data flow list.
Remote access to PLC, DCS and SCADA should be limited, approved, monitored and time-bound. A vendor should not have permanent uncontrolled access to critical systems.
Minimum controls:
Evidence to prepare: register of vendors with OT access and latest remote access review.
The OT environment should be divided into zones. Not every office computer should communicate with control systems. Not every OT system should communicate with every other OT system.
Practical actions:
Evidence to prepare: zone description, communication rules and exception list.
In OT, backups must cover not only data, but also configurations and control logic. Without the current PLC program or SCADA project, recovery may be difficult, expensive and slow.
Check backups of:
Evidence to prepare: configuration backup register and recovery test result.
An OT change can stop the process. Every change in PLC logic, DCS configuration, SCADA project, network rules or vendor access should be controlled.
The change process should include:
Evidence to prepare: OT change register and approvals for critical changes.
OT monitoring should cover not only Windows systems and servers, but also industrial traffic, logic changes, new devices, unusual vendor sessions and communication between zones.
Monitor:
Evidence to prepare: OT monitoring scope, alert list and escalation procedure.
An OT incident response plan must include production, automation, maintenance, safety, IT, security, vendors and the board. A procedure written for an office IT incident is not enough.
The plan should answer:
Evidence to prepare: OT incident response plan and tabletop exercise result.
If the organization is an essential or important entity, or operates in a regulated sector, OT may be part of cybersecurity obligations. This is especially relevant for sectors such as energy, transport, water, wastewater, healthcare, manufacturing, chemicals, food and digital infrastructure.
The board should treat PLC, DCS and SCADA as part of cyber risk if these systems are important for service delivery, production or business continuity.
In practice, this means preparing:
OT systems have different priorities than IT. Not every update, scan or restart can be performed like in the office. Process, safety, availability and production must be considered.
If OT sits “between IT and production”, nobody makes decisions. The board should clearly define responsibility for OT security.
Automation vendors and integrators often have broad access. Without control, vendors may become one of the most important risk paths.
Companies often have office data backups, but not current backups of PLC programs, SCADA projects and DCS configurations.
An OT incident response plan that has not been exercised usually does not work well in crisis. A tabletop exercise helps test roles, decisions and communication.
Advanced tools do not replace fundamentals. The first investments should cover inventory, segmentation, access control, configuration backups, monitoring and procedures.
A manufacturing company has several lines, a SCADA system, dozens of PLCs, an automation vendor with remote access and an older DCS in its most important process. The board believes cybersecurity is under control because the company has a firewall, antivirus and office data backups.
An initial review shows that the controller list is not current, the vendor has permanent VPN access, PLC program copies are stored locally on an engineering workstation and nobody has tested SCADA recovery. The OT network has several IT connections that are not on the diagram.
The problem is not the lack of one tool. The problem is lack of visibility, access control and recovery planning.
The company starts with fundamentals. It creates an OT register, maps IT-OT connections, restricts vendor remote access, backs up PLC and SCADA configurations, tests recovery of one critical process and prepares an incident exercise for a ransomware scenario.
After 90 days, the board receives the first real report: which systems are critical, where the biggest risks are, which actions have been completed and what budget is needed for further segmentation and monitoring.
ccyber.io helps boards and technical teams understand and organize PLC, DCS, SCADA and OT security in a practical, business-focused and risk-based way.
We can support your organization with:
The best first step is a short OT Security board workshop. It helps quickly determine what is critical, where visibility is missing, which vendors have access and what decisions the board should make.
A PLC is a programmable logic controller that controls a machine, device or part of a process. It receives signals from sensors, executes logic and sends commands to actuators.
A DCS is a distributed control system used in larger industrial processes. It coordinates many process elements and is often critical for production continuity and installation safety.
SCADA is a supervision and data acquisition system. It provides operators with process visibility, alarms, measurements and often the ability to control selected elements.
Not in the traditional sense. They are elements of OT, or operational technology. They affect the physical process, so they require a different approach than normal office systems.
The biggest risk is downtime, loss of process control, loss of visibility, human safety risk, equipment damage, quality issues, delivery delays and regulatory obligations.
The best starting point is asset inventory, IT-OT connection mapping, remote access review, configuration backups, segmentation, monitoring and an OT incident response plan.
No. The board should understand business impact and ask the right questions: what do we have, what is critical, who has access, how do we monitor changes and how do we recover?
They may apply if OT systems support the activity of an essential or important entity, critical services, production, infrastructure or a regulated sector. In that case, OT should be included in risk assessment, security measures, incidents and audits.
PLC, DCS and SCADA are not hidden technical details inside a plant. They are systems that may determine production, human safety, product quality, service availability and business continuity.
For the board, the most important approach is simple: first know what the company has, which systems are critical, who has access, how the environment is separated, whether configuration backups exist and whether the company can respond to an incident.
Good OT Security does not start with buying a tool. It starts with visibility, responsibility, access control, segmentation, configuration backups, monitoring and the board’s decision that OT security is part of business risk.
Digital Europe Programme for Cybersecurity: A Guide for Companies
The Digital Europe Programme can fund projects related to cybersecurity, deployment of innovative solutions, AI in cybersecurity, SME cyber resilience, preparedness testing, post-quantum technologies, NIS2, CRA and critical infrastructure protection. Learn how a company should prepare its project, partners, budget and documents before submitting an application.
Prepared by: CCyber Editorial Team
The Digital Europe Programme is an EU funding programme supporting the deployment of digital technologies in the economy, public administration and society. In cybersecurity, it can be particularly relevant for companies that develop or deploy cyber solutions, support SMEs, build AI-based cybersecurity tools, prepare projects for NIS2, CRA, cyber resilience, post-quantum technologies, preparedness testing or critical infrastructure protection. A company should start from the project, not the form: objective, scope, partners, budget, outcomes and alignment with a specific call.
July 2026
The Digital Europe Programme is a European Union funding programme focused on deploying and expanding key digital capacities. It is not a typical research programme. Its main role is to support practical deployment of digital technologies, infrastructure, skills and solutions.
The programme covers, among other areas:
For companies, the most important point is that the Digital Europe Programme funds deployment, scaling and uptake of technologies. In cybersecurity, this means projects that strengthen cyber resilience, the market, skills, infrastructure and response capabilities in the EU.
The cybersecurity area in the Digital Europe Programme is implemented as Specific Objective 3: Cybersecurity and Trust. For 2025-2027, the cybersecurity work programme is handled by the European Cybersecurity Competence Centre, or ECCC, in cooperation with the network of National Coordination Centres, including NCC-PL in Poland.
The Digital Europe Cybersecurity Work Programme 2025-2027 covers, among other areas:
For a company, this means a funding opportunity, but only if the project matches a specific call. It is not enough to write “we want to improve cybersecurity”. The proposal must show what problem the company solves, what outcome it will deliver and why the project matters for the market, users, SMEs, regulated sectors or EU resilience.
Providers of cybersecurity services, tools and technologies can look for calls related to deployment of innovative solutions, AI in cybersecurity, preparedness testing, SME support, NIS2, CRA, critical infrastructure protection and skills.
Companies developing digital products can look for funding related to CRA, product security, Secure SDLC, vulnerability management, SBOM, security testing, secure updates and customer cyber resilience.
SMEs can be project beneficiaries, participants in support programmes, recipients of cascade funding or users of deployed cybersecurity solutions. In many calls, SMEs are an important target group, even if they do not always apply directly as coordinators of large projects.
The programme supports directions related to AI in cybersecurity, such as threat detection, incident response, threat intelligence, automation of security processes and protection of AI systems themselves.
Entities in OT, manufacturing, energy, transport, water, healthcare or other regulated sectors can participate in projects related to preparedness testing, resilience, monitoring, NIS2, Cyber Hubs or critical infrastructure protection.
Many projects in the Digital Europe Programme require cooperation between different entities. Companies can participate in consortia with universities, research institutes, public administration, technology providers, end users and industry organizations.
Projects may involve tools and services using AI for threat detection, incident analysis, response automation, threat intelligence processing, AI system security and compliance with EU regulations.
Example topics:
The programme may support projects that make cybersecurity tools, services and skills more accessible to small and medium-sized companies. For technology companies, this may mean creating or deploying solutions for SMEs.
Example projects:
Companies developing software, IoT, hardware or products with digital elements may look for calls related to CRA preparation, standards, testing, technical documentation, vulnerability management, SBOM and lifecycle product security.
Projects may support NIS2-covered organizations or their suppliers: risk assessment, preparedness testing, incident response, information sharing, exercises, monitoring and cross-sector cooperation.
The programme may support preparedness testing, simulations, exercises, crisis scenarios and preparing organizations for cyberattacks.
A separate direction concerns migration to post-quantum cryptography, testing solutions, validation, infrastructure and system migration.
The programme also covers projects related to critical infrastructure protection, Cyber Hubs, submarine cables, cyber solidarity mechanisms and cross-border cooperation.
The most common mistake is starting with the application form itself. First, the company needs a project that makes business, technical and programme sense.
At the beginning, answer:
Evidence to prepare: short project card with problem, objective, target users and expected outcomes.
The Digital Europe Programme has different calls, and each has its own scope, conditions, budget, action type, evaluation criteria, eligibility and deadlines. A project that fits one call may not fit another.
Check in call documents:
Evidence to prepare: table mapping the project to call requirements.
In many European projects, a consortium increases credibility and impact. It is not always formally required, but often helps show that the project has real users, technology partners and implementation capacity.
Typical partners:
Evidence to prepare: list of partners, their roles, contributions and justification for why they are needed.
A good project must clearly show why it should receive funding. In the Digital Europe Programme, the private interest of one company is not enough. The project should show broader impact: for the market, SMEs, a sector, users, EU resilience or regulatory implementation.
Show:
Evidence to prepare: impact justification and measurable outcome description.
The budget must follow the activities, not the amount the company would like to receive. Each task should have a cost, justification and responsible partner.
The budget may include, depending on the call:
Evidence to prepare: budget by tasks, partners, costs and outcomes.
The proposal should show that the project is feasible. The timeline cannot be a list of generic statements. It should include tasks, milestones, deliverables and dependencies between partners.
Example work packages:
Evidence to prepare: work plan with milestones, deliverables and responsibilities.
Evaluators must believe that the team can deliver the project. The company should show skills, experience, partner roles, resources and implementation readiness.
Prepare:
Evidence to prepare: team profile, experience, references and project risk management plan.
General evaluation criteria in the Digital Europe Programme include three areas: relevance, implementation and impact. Specific criteria may vary by call, so call documents should always be checked.
The project must fit the call objective. Evaluators check whether the project responds to the described needs, supports EU policies and strategies, strengthens the digital technology supply chain or helps overcome financial barriers where relevant.
The project must be realistic. Project maturity, quality of the plan, efficient use of resources and the ability of applicants or consortium to deliver are important.
The project must matter. Evaluators consider whether it will achieve expected outcomes, strengthen competitiveness, bring societal benefits, disseminate results and remain useful after funding ends.
The funding rate depends on the action type and the specific call. A single funding rate should not be assumed for the whole programme.
The work programme includes, among others:
The most important point: funding rate, own contribution, eligible costs, subcontracting limits and reporting rules must always be checked in the documents of the specific call.
A strong direction may be a project that helps many SMEs deploy specific cybersecurity controls or meet NIS2, CRA or B2B customer requirements.
Companies developing software, IoT or products with digital elements can prepare projects on product security: SBOM, vulnerabilities, updates, testing, documentation and Secure SDLC.
If the company has a real AI technology supporting threat detection, analysis or response, it can prepare a deployment project with partners and pilot users.
Regulated organizations can prepare projects involving exercises, preparedness testing, crisis communication, response plans and sector cooperation.
Industrial companies and cybersecurity providers can prepare projects on segmentation, monitoring, remote access, resilience testing and protection of physical processes.
The Digital Europe Programme funds projects aligned with programme objectives and specific calls. A tool purchase without a broader project, outcome and impact will usually be weak.
Even a good project can lose if it does not address the call topic. Alignment with objective, scope and expected outcomes is critical.
Statements such as “we will increase cybersecurity” are too weak. The proposal must show what exactly will be created, for whom, how it will work and how impact will be measured.
In many topics, technology alone is not enough. Users, deployment organizations, sector partners or recipients are needed to show real demand.
Costs must follow tasks and outcomes. The budget cannot look like a wish list.
Preparing a strong project, partners and documents takes time. Waiting until the last week of the call usually results in a weak proposal.
Evaluators want to know what will happen to the results after the project. The project should include a plan for maintaining, scaling or using the outcomes.
A cybersecurity company is developing a tool that helps SMEs assess CRA readiness and manage vulnerabilities in digital products. The team wants to find funding from the Digital Europe Programme.
Instead of starting from the form, the company prepares a project: an SME platform, pilot with several dozen companies, SBOM process integration, vulnerability reporting module, training materials and readiness reports for digital products.
Then the company looks for partners: an SME organization, software houses, a research entity and an industry organization. The project is matched to a call on uptake of innovative cybersecurity solutions for SMEs.
The project’s main advantage is not the technology alone. It is alignment with the programme objective: SMEs, CRA, deployment, cyber resilience, measurable outcomes and scalability after funding ends.
ccyber.io helps companies prepare cybersecurity projects for the Digital Europe Programme in a practical, business-focused way aligned with the logic of EU calls. We do not start from the form. We start from the problem, project value, call fit and delivery capacity.
We can support your organization with:
The best first step is a short grant-readiness workshop. It helps determine whether the company has a project that realistically fits the Digital Europe Programme, which documents must be prepared and whether partners should be sought for a consortium.
Yes. Cybersecurity and trust is one of the areas of the Digital Europe Programme. For 2025-2027, the cybersecurity work programme includes AI, post-quantum technologies, SME cyber resilience, preparedness testing, Cyber Hubs, NIS2, CRA and critical infrastructure.
It can, if the project fits a specific call and shows broader impact than developing one company’s product. Deployment, users, partners, market impact, SMEs, regulated sectors or EU resilience are important.
No. The programme also supports SMEs, and many actions directly or indirectly concern small and medium-sized enterprises. In some action types, SMEs may have more favorable funding conditions.
It depends on the call. Some topics may require a consortium, others may not. Even when a consortium is not mandatory, partners often strengthen the project, especially if they show real deployment and impact.
Current calls should be checked primarily on the Funding & Tenders Portal. In Poland, NCC-PL and the National Contact Point for Digital Europe at CPPC are also worth monitoring.
The Digital Europe Programme is more focused on deployment and uptake of digital capacities than classic research. Research and innovation projects more often fit Horizon Europe. In practice, the two programmes can complement each other.
General criteria include relevance, implementation and impact. In practice, this means call fit, project maturity, plan quality, team capacity, expected outcomes and broader project impact.
The best starting point is a project card: problem, objective, target users, solution, partners, outcomes, budget and alignment with a specific call. The application form should be the final stage, not the beginning of project thinking.
The Digital Europe Programme can be an important funding source for companies active in cybersecurity, but it requires strong preparation. It is not a programme for random tool purchases. It is a programme for projects that strengthen Europe’s digital capacities, cyber resilience, market, skills and technology deployment.
For cybersecurity companies, SaaS companies, software houses, AI providers, product companies and regulated entities, the strongest projects are well aligned with the call, measurable, deployment-oriented and based on real market or sector needs.
The best approach is simple: prepare the project early, find the right call, build partnerships, show impact, prepare the budget and submit before the deadline. In European funding, the winner is not the company that starts writing latest, but the one with a mature, justified and ready project.
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.