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.
Secure SDLC Checklist for SaaS Companies and Software Houses
Secure SDLC helps SaaS companies and software houses build security into the entire software development lifecycle: from requirements and architecture, through coding, testing and CI/CD, to release, monitoring, updates and vulnerability handling. Use this practical checklist to reduce risk, prepare evidence and meet customer and regulatory requirements.
Prepared by: CCyber Editorial Team
Secure SDLC is a secure software development lifecycle, meaning an approach where security is present from requirements and architecture to deployment, monitoring, updates and vulnerability handling. SaaS companies and software houses should start with a checklist covering product security ownership, security requirements, threat modeling, coding standards, code reviews, SAST, DAST and SCA testing, SBOM, CI/CD security, secrets management, vulnerability management and evidence.
July 2026
Secure SDLC means secure software development lifecycle. It means embedding security into every stage of product development: idea, requirements, architecture, development, testing, deployment, maintenance, updates and vulnerability handling.
In practice, Secure SDLC answers the following questions:
Secure SDLC does not have to slow development down. Implemented well, it reduces chaos, limits late-stage rework and helps find problems earlier, when they are cheaper to fix.
SaaS companies and software houses build software that often processes customer data, integrates with external systems, uses cloud, APIs, open-source components and automated deployments. This creates a large attack surface.
Customers increasingly expect not only a statement that “we care about security”, but specific evidence:
Secure SDLC is also increasingly important from a regulatory perspective. The Cyber Resilience Act introduces cybersecurity requirements for products with digital elements, and customers covered by NIS2, DORA or ISO/IEC 27001 may transfer security requirements to technology suppliers.
Product security cannot belong to nobody. The company should have an owner for application or product security. In a small company, this does not need to be a separate department, but responsibility must be clear.
The owner should coordinate:
Evidence to prepare: decision naming the product security owner, responsibility scope and supporting team list.
You cannot secure a product that is not described clearly. SaaS companies and software houses should maintain a list of products, repositories, applications, APIs, services, libraries, components and environments.
The register should include:
Evidence to prepare: product and repository register with owners and criticality classification.
Security should not be an add-on to functionality. It should be part of requirements. Product owners, architects, developers and security should know what security requirements the product must meet.
Example requirements:
Evidence to prepare: product security requirements linked to backlog, risk and tests.
Threat modeling helps the team answer: what can go wrong and how can we prevent it? Not everything needs to be modeled immediately. Start with high-risk features.
Threat modeling is useful for:
The output should be concrete requirements, backlog tasks and tests.
Evidence to prepare: data flow diagram, threat list, control decisions and remediation tasks.
A secure coding standard should be simple, practical and aligned with the technologies used by the team. It should not be a document nobody reads.
The standard should cover:
Evidence to prepare: coding standard, pull request checklists and team training confirmation.
Passwords, API keys, tokens, certificates and other secrets should not end up in code repositories, tickets, documentation, chat tools or unprotected configuration files.
Minimum rules:
Evidence to prepare: secrets policy, vault configuration, scanning results and rotation register.
Modern applications use many libraries and packages. This accelerates work, but introduces software supply chain risk.
The company should know:
Evidence to prepare: dependency register, SCA results and procedure for updating vulnerable components.
SBOM, or Software Bill of Materials, helps show what the product is made of. It is important for supply chain security, CRA, customer discussions and rapid response to new vulnerabilities.
A good SBOM should be:
Evidence to prepare: SBOM for the main product and the SBOM update process.
The code repository is one of the most important assets of a technology company. Repository compromise can lead to source code leakage, secret exposure, code tampering or attacks on customers.
Minimum controls:
Evidence to prepare: repository configuration, MFA status, branch protection rules and access review report.
The CI/CD pipeline can become an attack path into the product. If an attacker compromises the build or deployment process, they may introduce malicious code into a legitimate product release.
Control:
Evidence to prepare: pipeline documentation, permission list, secrets configuration, deployment logs and production approval rules.
Security testing should be part of the development process, not only a pre-release activity. For SaaS companies and software houses, the minimum baseline is a combination of several testing methods.
In practice:
Not every tool warning is critical. A triage process is needed to decide which findings are real and require remediation.
Evidence to prepare: SAST, DAST, SCA and secret scanning results, triage decisions and remediation status.
In SaaS products, API is often the most important attack surface. Authorization, object access control, rate limits and customer data separation issues can lead to serious incidents.
API testing should cover:
Evidence to prepare: API test plan, test results, vulnerabilities and remediation confirmation.
Configuration errors are one of the most common causes of incidents in cloud and SaaS services. Development, test and production environments should be separated and managed according to clear rules.
Check:
Evidence to prepare: environment standard, configuration review results and production access control report.
The product should generate logs that help detect incidents, analyze events and prove what happened. No logs means no visibility.
Useful events to log:
Logs must be protected from tampering, available for analysis and retained according to company rules and customer requirements.
Evidence to prepare: list of logged events, log retention, alerts and monitoring report.
Vulnerabilities do not end on release day. The company must have a process for receiving reports, assessing issues, fixing them, communicating and documenting them.
The process should include:
Evidence to prepare: vulnerability management procedure, vulnerability register, remediation status and retest reports.
A good Secure SDLC checklist ends with evidence. Customers, auditors and regulators increasingly ask not only whether the company “does security”, but whether it can prove it.
Key evidence:
Evidence to prepare: Secure SDLC evidence pack ready for customers, audits or conformity assessment.
If security appears only at the end, the team has little time for fixes and costs increase. Security should be part of requirements, design and daily work.
A small software house does not need to build a large corporate programme immediately. It is better to start with a minimum that works and gradually increase maturity.
If nobody owns Secure SDLC, security tasks will be postponed. The owner does not need to do everything alone, but must coordinate the process.
The modern delivery process is a critical security element. A compromised pipeline can be as dangerous as an application vulnerability.
An application may be well written and still vulnerable because of a library, package or third-party component. That is why SCA and SBOM matter.
A product’s life does not end on deployment day. Vulnerabilities will appear later, so the company needs a process for detection, assessment, remediation and communication.
The team may do many good things, but without evidence it is hard to show maturity to a customer, auditor or regulator.
A SaaS company develops a platform for B2B customers. It has several development teams, fast deployments, many API integrations, a cloud environment and increasing customer security requirements.
Until now, security was based mainly on annual penetration testing. After each test, the team received a long list of vulnerabilities that had to be fixed under time pressure.
After implementing Secure SDLC basics, the company changes its approach. It introduces security requirements into the backlog, performs threat modeling for high-risk features, adds secret and dependency scanning to CI/CD, prepares an SBOM and creates a vulnerability handling process.
After 90 days, the company is not “perfectly secure”, but it has much better control. It knows which products are critical, which vulnerabilities are open, which dependencies are used and what evidence it can show to customers.
ccyber.io helps SaaS companies and software houses implement Secure SDLC in a practical, lightweight way aligned with how development teams actually work.
We can support your organization with:
The best first step is a short Secure SDLC assessment. It helps identify which parts of the process already work, where the biggest gaps are and what should be implemented in the first 30, 60 and 90 days.
No. Small and medium-sized companies can also implement Secure SDLC, but they should start with simple practices: security requirements, code reviews, dependency scanning, secrets control and vulnerability handling.
No. Penetration testing is important, but it does not replace a secure development process. Secure SDLC helps find and fix issues earlier, before they reach production.
The best starting point is a product register, security owner, security requirements, repository control, secret and dependency scanning and a pilot on one product.
Secure SDLC describes the full secure software development lifecycle. DevSecOps is a practical way of embedding security into DevOps work, automation, CI/CD, testing and deployment.
SBOM is increasingly useful, especially for companies selling software to B2B customers, preparing for CRA, serving regulated sectors or managing many open-source components.
Yes. Secure SDLC helps prepare processes and evidence needed for product security: risk assessment, security requirements, testing, vulnerability management, SBOM, documentation and updates.
Threat modeling should be performed for new high-risk features, major architecture changes, new integrations, new data types and changes affecting access or permissions.
At the beginning, tools for secret scanning, dependency scanning, code scanning, configuration scanning and application testing are usually enough, combined with a code review and vulnerability management process. Tools should support the process, not replace risk thinking.
Secure SDLC for SaaS companies and software houses should not be a heavy bureaucratic process. It should be a practical checklist of actions that help build safer products and respond faster to customer, audit and regulatory requirements.
The most important elements are security requirements, threat modeling, secure coding, secrets control, dependency management, SBOM, repository and CI/CD security, security testing, vulnerability management and evidence.
Companies that implement Secure SDLC early reduce technical risk, limit the cost of late fixes and build a sales advantage as more trustworthy software suppliers.
Cyber Resilience Act for Software Houses: What Should Be Prepared in 2026 and 2027?
The Cyber Resilience Act turns digital product cybersecurity from a best practice into a regulatory obligation. Software houses should prepare product risk assessment, secure development lifecycle, vulnerability management, technical documentation, SBOM, update process, incident reporting and a compliance roadmap for 2026 and 2027.
Prepared by: CCyber Editorial Team
A software house should start preparing for the Cyber Resilience Act by checking whether the software it develops is a product with digital elements made available on the EU market and what role the company plays: manufacturer, subcontractor, component provider or service provider. In 2026, the key priorities are vulnerability handling and reporting processes, product cybersecurity risk assessment, secure software development lifecycle, technical documentation, SBOM, update rules and a compliance plan before the main CRA obligations apply in 2027.
July 2026
The Cyber Resilience Act, or CRA, is an EU regulation introducing cybersecurity requirements for products with digital elements. Its goal is to increase the security of products available on the EU market and ensure that vulnerabilities are handled throughout the product support period.
In practice, CRA means that cybersecurity of a digital product cannot be added at the end of the project. It must be included in planning, design, development, testing, release, updates, vulnerability handling and user communication.
For software houses, CRA matters because many technology companies no longer sell only “software development services”. They build applications, components, platforms, SaaS products, integrations, libraries, modules, firmware, mobile applications, IoT systems or software made available on the market under their own brand or a customer’s brand.
The key question is not “do we develop software?”, but “do we make a product with digital elements available on the EU market under our own name or trademark?”.
A software house may act in different roles:
If the company only develops software for a customer, and the customer places the product on the market under its own brand, manufacturer obligations may primarily apply to the customer. This does not mean that the software house can ignore CRA. The customer will likely transfer part of the requirements to the supplier through contracts, development processes, documentation, testing, vulnerability handling and security evidence.
CRA covers products with digital elements, meaning software or hardware and related remote data processing solutions, if the product is made available on the EU market and its intended or reasonably foreseeable use includes connection to a device or network.
Examples that may require CRA analysis:
The fact that a company develops software does not automatically mean that CRA applies. Each case should be assessed based on the business model, product availability, company role, product type and customer contracts.
From this date, provisions concerning conformity assessment bodies apply. For a software house, this matters mainly if a product requires the involvement of a notified body or belongs to an important or critical product category.
From this date, reporting obligations apply for actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
In practice, the manufacturer should have a process for:
From this date, most CRA requirements will apply. Products covered by CRA will need to meet cybersecurity requirements, undergo the appropriate conformity assessment, have technical documentation, an EU declaration of conformity, CE marking and a defined support period.
A software house should start with a map of products and roles. Without this, it is difficult to determine which obligations apply directly to the company and which will result from customer contracts.
Check:
Evidence to prepare: product register, product owner, company role, market, product type, availability model and initial CRA classification.
CRA requires a risk-based approach. The manufacturer should assess the cybersecurity risks of the product and use the outcome of that assessment in design, development, delivery and maintenance.
The risk assessment should cover:
Evidence to prepare: product risk assessment report and list of security requirements resulting from the assessment.
A software house should organize the development process so that security is part of daily work, not a one-off test before release.
A secure development lifecycle should include:
Evidence to prepare: secure software development process description, procedures, checklists and test results.
CRA strengthens manufacturer obligations for vulnerability handling. The company needs a process to detect, analyze, prioritize, fix and communicate vulnerabilities.
The process should define:
Evidence to prepare: vulnerability management procedure, vulnerability register, remediation status and reporting decisions.
The company should allow customers, security researchers and users to report vulnerabilities in a controlled way. In practice, this means preparing a clear contact channel, handling rules and internal responsibilities.
Prepare:
Evidence to prepare: vulnerability disclosure policy, contact channel, report register and handling metrics.
SBOM, or Software Bill of Materials, helps determine which libraries, packages and components make up the product. It is important for vulnerability management, software supply chain security and rapid response to new vulnerabilities in components.
A software house should know:
Evidence to prepare: product SBOM, SBOM update process and link with vulnerability management.
Technical documentation is one of the most important elements of CRA preparation. It should show that the product meets cybersecurity requirements and that the company can prove it.
Documentation may include:
Evidence to prepare: complete product technical documentation aligned with CRA requirements and ready to be shown to market surveillance authorities.
From 11 September 2026, manufacturers will have to report actively exploited vulnerabilities and severe incidents affecting the security of products with digital elements.
The company should have a process that answers:
Evidence to prepare: CRA reporting procedure, roles, note templates, escalation path and reporting register.
In 2027, the company should move from planning to full readiness. The product should have implemented security requirements, an update process, technical documentation and test evidence.
Key readiness elements:
Before placing the product on the market, the manufacturer should perform the appropriate conformity assessment. For many products, self-assessment may be possible, but some important or critical product categories may require a stricter route, including involvement of a notified body.
The software house should check:
For products covered by CRA, the manufacturer should prepare an EU declaration of conformity and affix CE marking if the product meets the requirements. This requires earlier preparation of documentation, testing, risk assessment and evidence of conformity.
CRA does not end on release day. The manufacturer must handle vulnerabilities and updates during the support period. This requires people, process, tools and budget.
In 2027, the company should have ready:
Most obligations apply in 2027, but reporting obligations begin earlier. In addition, preparing processes, documentation and tests can take many months.
CRA has legal consequences, but the challenge is also technical and organizational. Lawyers can help interpret the regulation, but product, technical and security teams must implement processes.
If a software house develops a product for a customer, it must be clear who is responsible for risk assessment, technical documentation, testing, SBOM, vulnerability handling and product conformity.
Modern digital products use many external libraries and components. Without an SBOM, it is difficult to quickly assess whether a new vulnerability affects the product.
If security testing appears only before release, fixing issues is more expensive and harder. Security should be part of the entire product lifecycle.
The product must be maintained after release. Updates, reports, vulnerability monitoring, user communication and documentation are required.
Even if the team follows good practices, it must be able to show them. Lack of documentation, registers and test results weakens readiness for conformity assessment, customer discussions and controls.
A software house develops a SaaS platform for B2B customers. The product includes a web application, API, customer integrations, mobile application and a component installed in the customer environment. Until now, the company focused on features and delivery time, while security was checked mainly through periodic penetration tests.
After an initial CRA analysis, the company discovers that it needs to organize much more than a security test. It needs a product register, risk assessment, threat modeling, SBOM, vulnerability handling process, reporting procedure, technical documentation and update rules.
The biggest change is not buying a new tool. The biggest change is moving from “testing before release” to “security is part of the entire product lifecycle”.
Within 90 days, the company can prepare the foundation: product map, risk assessment, vulnerability reporting process, SBOM for the main product, basic technical documentation and an action plan for 2027.
ccyber.io helps software houses and product companies prepare for the Cyber Resilience Act in a practical, technical and business-focused way. We do not limit the work to regulatory interpretation. We help translate CRA into processes, documentation, testing and evidence.
We can support your organization with:
The best first step is a short CRA readiness workshop. It helps determine which products may be covered by CRA, what role the company plays, what evidence already exists and what actions should be completed before the 2026 and 2027 deadlines.
It may apply. If a software house places a product with digital elements on the EU market under its own brand, it may act as a manufacturer. If it develops a product for a customer, requirements may be transferred contractually by the customer.
It depends on the product model and service delivery. CRA may cover related remote data processing solutions if they are necessary for the function of a product with digital elements. Each SaaS case should be assessed individually.
CRA has a special approach to free and open-source software. Non-commercial open-source distribution is treated differently from a product made available on the market as part of commercial activity. If a company monetizes an open-source product or places it on the market, scope analysis is needed.
The key priority is to prepare the process for reporting actively exploited vulnerabilities and severe incidents affecting product security. The company should define roles, deadlines, reporting channels and decision documentation.
The company should prepare full readiness for the main CRA requirements: product risk assessment, secure development lifecycle, vulnerability handling, technical documentation, conformity assessment, declaration of conformity, CE marking, support period and user information.
CRA increases the importance of component visibility and vulnerability management. In practice, SBOM is one of the most important tools for demonstrating control over components, dependencies and software supply chain risk.
No. Penetration testing is important, but not sufficient. CRA requires an approach covering the full product lifecycle: risk assessment, design, development, testing, documentation, updates, vulnerability handling and post-release support.
The best starting point is product and role mapping, CRA scope analysis, gap assessment and a 2026-2027 action plan. Then the company should organize secure development, vulnerabilities, SBOM and documentation.
The Cyber Resilience Act changes how technology companies should think about product security. Security is no longer only a best practice, sales advantage or requirement from a large customer. It becomes part of conformity, documentation, risk assessment and manufacturer accountability.
Software houses should use 2026 to prepare the foundation: product mapping, vulnerability handling process, risk assessment, secure development lifecycle, SBOM, technical documentation and reporting procedures.
In 2027, the organization should move to full readiness: conformity assessment, evidence of meeting requirements, user information, support period, declaration of conformity and post-release product security maintenance.
Cybersecurity Grants in 2026: Where Should Companies Start?
Cybersecurity grants can help fund audits, testing, training, digital product security, preparation for NIS2, CRA, DORA, AI Security, OT Security and cyber resilience improvements. Learn where to start, how to prepare a project, what documents to collect and how to increase your chances of using available funding.
Prepared by: CCyber Editorial Team
Preparing for cybersecurity grants should not start with randomly searching for a call. It should start with defining the project: what problem the company wants to solve, what risk it wants to reduce, what requirements it needs to meet and what evidence it must prepare. The best grant projects have a clear objective: NIS2/KSC, CRA, DORA, AI Security, OT Security, security testing, training, incident response, backup, PAM, MFA, cloud security or secure software development. Only then should the company match the project to an active funding call and check cost eligibility.
July 2026
Cybersecurity is becoming one of the main investment areas for companies, public institutions and critical sectors. The reasons are regulation, increasing incidents, ransomware, customer requirements, supply chain security, artificial intelligence and the Cyber Resilience Act for digital products.
For many companies, the main barrier is not lack of awareness, but cost. Grants can help reduce this barrier and launch actions the company should take anyway: audits, gap analyses, testing, training, documentation, product security, compliance preparation or implementation of key controls.
The most important rule is this: funding should accelerate a sensible cybersecurity plan, not replace strategic thinking.
Do not start with the question “which grant is available?”. Start with: what cybersecurity problem do we need to solve?
Example problems:
Evidence to prepare: short description of the problem, business impact, risk and expected project outcome.
Different programmes target different types of entities. A company must determine whether it fits as an SME, digital product manufacturer, cybersecurity provider, public entity, hospital, NIS2 entity, research organization or consortium member.
Check:
Evidence to prepare: basic organization eligibility card.
Cybersecurity is a broad area. The same programme may finance very different projects: deployment of tools for SMEs, penetration testing, AI in cybersecurity, secure-by-design, resilience of critical infrastructure, cyber skills or CRA-related actions.
Common funding directions:
Evidence to prepare: project-to-funding direction map and explanation of why the project fits the call.
A good grant project must have a specific scope. It is not enough to write “we will improve cybersecurity”. The company must show what exactly will be done.
Example project scope may include:
Evidence to prepare: scope of work, deliverables, timeline and responsibilities.
The budget should follow the scope, not the other way around. First define what needs to be done, then assign costs to it.
Depending on the call, costs may include:
Every call has its own eligibility rules. Before submitting an application, check the call regulations, limits, required own contribution, implementation period and reporting rules.
Evidence to prepare: project budget divided into tasks, costs and justification.
Companies often lose time because they start looking for documents only after finding a call. It is better to prepare the pack earlier.
Start with:
Evidence to prepare: project folder ready to be updated for a specific call.
The project may include status self-assessment, gap analysis, risk assessment, documentation, incident procedures, training, supplier review and compliance evidence preparation.
This is a good direction for companies that are or may become essential or important entities, as well as suppliers serving regulated sectors.
For software houses, SaaS companies, IoT, embedded, hardware and digital product manufacturers, preparing for CRA is a strong topic.
The project may include:
Security testing is easy to justify because it produces concrete outcomes: a vulnerability report, recommendations, priorities and evidence of execution.
A good project should include not only testing, but also remediation planning and retesting.
The project may include an incident response plan, tabletop exercise, backup review, recovery test, crisis communication plan and board readiness assessment.
This is a strong direction for companies that need to show customers or insurers they can survive a cyberattack.
AI projects may follow two directions: using AI for cybersecurity or securing AI systems.
Examples:
Industrial companies, water utilities, energy, transport and critical infrastructure organizations can justify projects through the impact of cyberattacks on continuity, human safety and physical processes.
The project may include:
Training can be part of a broader cyber resilience project. It works best when connected with risk, phishing, NIS2, AI, incident response procedures and training evidence.
A training project should have measurable outcomes: number of people trained, knowledge test, phishing simulations, materials and post-training report.
The Digital Europe Programme funds digital transformation projects, including cybersecurity, AI, advanced digital skills and digital trust. In the cybersecurity area for 2025-2027, NCC-PL indicates a budget of EUR 355 million over three years.
This is one of the most important programmes to monitor for companies and institutions interested in cybersecurity.
The ECCC publishes cybersecurity calls under the Digital Europe Programme. The Cyber 09 call covered, for example, cybersecure AI-based tools and services, uptake of cybersecurity solutions for SMEs, preparedness testing and regional submarine cable hubs.
Even if a specific deadline has passed, these calls are worth analyzing because they show which types of projects may be attractive in future funding rounds.
The SECURE project, co-financed by the Digital Europe Programme, launched support for micro, small and medium-sized enterprises that want to improve the cybersecurity of digital products and prepare for CRA. An example call included grants of up to EUR 30,000.
This is a good example of funding for product, software, hardware, IoT and embedded companies that need to implement secure-by-design, vulnerability management, testing and certification.
Horizon Europe is more focused on research, development and innovation than on standard company implementations. NCC-PL described a Cluster 3 call with a budget of EUR 56.2 million, covering software and hardware security, AI Security and advanced cryptographic solutions.
This direction is particularly interesting for technology companies, universities, research institutes, consortia and innovative cybersecurity providers.
Some calls are aimed not at end users of cybersecurity, but at organizations specializing in testing, vulnerability assessment, security services and support for entities covered by NIS2.
For example, NCC-PL described grants of up to EUR 200,000 per project for cybersecurity-related organizations, with the mission of conducting penetration testing and vulnerability assessment for NIS2-covered entities and other organizations.
In addition to EU programmes, companies should monitor national and regional programmes supporting digitalization, innovation, skills and resilience. Not every programme will use the word “cybersecurity”, but cybersecurity costs may appear as part of a broader project on digitalization, product security, automation, cloud, AI or operational resilience.
Not every call fits every company. If the project is artificial, weakly justified or not based on real risk, the chances of success decrease.
Statements such as “we will improve the company’s cybersecurity” are too weak. The application must show a specific problem, actions, results and evidence.
The application must show how the project will be delivered. It needs a budget, tasks, deadlines, owners and measurable outcomes.
A grant may fund implementation, but the company must know what happens after the project. Tools, licenses, monitoring and processes must be maintained.
It is useful to have an assessment, gap analysis, test results, customer requirement, risk map or regulatory reference. This strengthens the justification.
Calls have deadlines. A company that starts from scratch only after a competition is announced often cannot prepare a strong application, offers and documents on time.
A software house builds a SaaS application for B2B customers. The company hears about CRA and knows that the product will need to meet higher cybersecurity requirements. The team wants to use grant funding, but does not know where to start.
Instead of looking for a random call, the company prepares a project around “digital product security”. The scope includes secure SDLC, threat modeling, application testing, vulnerability management, SBOM, responsible disclosure procedure, developer training and product security documentation.
Then the company checks whether it fits programmes supporting SMEs covered by CRA, Digital Europe, Horizon Europe or other digital product calls. Even if one call is already closed, the company has a ready project and can quickly adapt it to the next funding round.
The company’s biggest advantage is not that it found a grant. It is that it had the project, budget and justification ready before the right deadline appeared.
ccyber.io helps companies prepare cybersecurity projects that make business, regulatory and technical sense. We do not start from the form. We start from the problem, risk and scope of actions.
We can support your organization with:
The best first step is a short cybersecurity funding workshop. It helps determine whether the company has a project suitable for grant funding, what documents should be collected and which calls should be monitored.
No. Each call has its own criteria: entity type, company size, country, project scope, eligible costs, deadlines and formal requirements. This is why company and project eligibility must be checked first.
The best starting point is project preparation: problem, risk, objective, actions, budget and outcomes. Only then should the company match the project to an active call.
Some programmes may support projects related to cyber resilience, NIS2 requirements, training, testing, risk assessment or tools for regulated organizations. The rules of each call must be checked individually.
Yes, programmes appear that support SMEs in preparing digital products for CRA requirements, including secure-by-design, vulnerability management, testing and certification. Deadlines and conditions must always be checked on official websites.
In certain calls, yes. Penetration testing and vulnerability assessment are common elements of cybersecurity projects, but specific conditions, target groups or entity types may apply.
Sometimes yes, especially as part of a broader cyber resilience, awareness, regulatory preparation or procedure implementation project. The call must confirm whether training is an eligible cost.
No. Eligibility rules and dates should be checked first. A purchase made before the eligible cost period may not be accepted.
At least monthly, and more often during call announcement periods. It is worth monitoring NCC-PL, CPPC, ECCC, Funding & Tenders, PARP, regional programmes and EU programme websites.
Cybersecurity grants in 2026 can be a strong way to accelerate actions the company should implement anyway. The strongest projects are specific, measurable and connected with real risk: NIS2, KSC, CRA, AI Security, OT Security, testing, training, backup, incident response and secure software development.
The best approach is simple: do not wait passively for the perfect call. Prepare the project, scope, budget, evidence and justification. When the right grant appears, the company will be ready to act quickly.
A well-prepared cybersecurity project helps not only with funding. It also improves discussions with the board, customers, auditors, insurers and suppliers.
OT Security Explained: How Is It Different from IT Security?
OT Security protects industrial, production and infrastructure systems that control physical processes. Unlike traditional IT Security, OT prioritizes human safety, availability, process continuity and control over devices such as PLCs, SCADA, DCS, HMI and automation systems.
Prepared by: CCyber Editorial Team
OT Security is the cybersecurity of operational and industrial systems that monitor or control physical processes. In IT, we usually protect data, applications and users. In OT, we protect production, equipment, human safety, operational continuity and process stability. That is why OT cannot simply copy IT security methods. Patching, scanning, restarting, segmentation, monitoring and incident response must be adapted to production, automation and critical infrastructure realities.
July 2026
OT, or Operational Technology, refers to systems, devices and software used to monitor, control or automate physical processes. OT is used in manufacturing, energy, transport, water utilities, logistics, buildings, healthcare, chemical industry, food production and critical infrastructure.
OT environments may include:
Simply put: IT manages information, while OT manages the physical process.
OT Security protects OT systems from cyber threats, errors, unauthorized access and actions that could disrupt a physical process.
OT Security protects:
In OT, a cyberattack can have physical consequences. It can stop a production line, change process parameters, disrupt water or energy supply, disable a transport system or create risk for operators.
In traditional IT, the focus is often on confidentiality, integrity and availability. In OT, the order is different. Human safety, process availability, control stability and then data confidentiality are usually the priorities.
In IT, an incident may mean data loss. In OT, an incident may mean production stoppage, equipment damage, loss of process visibility, loss of control or safety risk.
IT systems are replaced relatively often. Laptops, servers and applications usually have lifecycles measured in years.
OT systems may operate for 10, 15, 20 years or more. Some controllers, operator panels and SCADA systems run for decades because they are part of a production line or industrial installation.
This means that OT often includes older systems, older protocols and limited ability to install modern security controls.
In IT, system updates are often routine. In OT, an update may require a maintenance window, testing, production approval, vendor involvement and rollback planning.
An untested patch can stop a process, change system behavior or affect certification. That is why OT patch management must be connected with change management and operational risk assessment.
In IT, vulnerability scanning is a typical security activity. In OT, aggressive scanning can disrupt older devices, overload industrial networks or affect controller communication.
In OT, passive asset discovery, traffic analysis, controlled testing and coordination with automation and production teams are preferred.
In IT, restarting a server or laptop is usually an organizational problem. In OT, restarting a controller, HMI or SCADA server may stop a line, interrupt a process or require a startup procedure.
Technical decisions in OT must therefore consider the technological process, not only the operating system state.
IT focuses on digital services, data, users and applications. OT focuses on processes, machines, operators, production and physical safety.
A good OT Security programme must connect both worlds. It does not work when IT imposes rules on automation teams without understanding the process. It also does not work when OT rejects every security requirement as an obstacle.
PLC, or Programmable Logic Controller, is used to control a machine or process. It receives signals from sensors, executes control logic and sends commands to actuators.
Example: a controller starts a pump, opens a valve, stops a conveyor or controls temperature.
SCADA, or Supervisory Control and Data Acquisition, is a system for supervision, visualization and data collection. It allows operators to observe a process, respond to alarms and sometimes send control commands.
SCADA often integrates many devices and geographically distributed sites.
DCS, or Distributed Control System, is used in large process installations, for example in energy, chemical, pharmaceutical, food and refinery environments.
DCS manages the process as a whole, while control is distributed across multiple controllers.
HMI, or Human Machine Interface, is the interface between an operator and a machine. It displays process state, alarms, measurements and allows selected actions.
ICS, or Industrial Control System, is a broad term for industrial control systems. It includes SCADA, DCS, PLC, HMI and industrial networks.
IIoT, or Industrial Internet of Things, refers to networked industrial devices used for monitoring, predictive maintenance, production optimization and data collection.
In the past, many OT systems were isolated. Today, production, maintenance, reporting, cloud, ERP, MES, remote service and data analytics increasingly require IT and OT connectivity.
This increases efficiency, but also creates new attack paths.
Vendors, integrators and maintenance teams often need remote access to industrial systems. If this access is not controlled, it can become one of the most important entry points for attackers.
Many OT devices were designed with the assumption that they would operate in isolated networks. Some industrial protocols do not include built-in encryption, strong authentication or integrity controls.
A ransomware attack may start in IT, but stop OT. If planning systems, engineering workstations, HMI, historians, recipe systems, backups or intermediate servers are encrypted, production may stop even without direct encryption of PLCs.
A company cannot protect systems it does not know. Without a list of PLCs, HMIs, engineering workstations, SCADA servers, network connections and suppliers, risk cannot be controlled.
Permanent supplier VPN, shared accounts, no MFA, no logs and no session approval create high risk for OT.
If office and industrial networks are connected without control, an attack from IT can move more easily into OT. Segmentation and security zones limit traffic and incident impact.
OT systems often run for a long time and cannot always be updated quickly. This requires compensating controls such as segmentation, access control, monitoring and exposure reduction.
Office data backup is not enough. OT also requires backup of PLC configurations, controller programs, SCADA projects, HMI configurations, recipes and device settings.
In OT, what matters is not only who logged in, but also what commands are being sent to devices and whether process behavior is normal.
An IT incident procedure is not enough. OT response must include production, automation, safety, maintenance and decisions about process shutdown.
First, understand what exists in the environment. OT inventory should include devices, systems, networks, protocols, software versions, suppliers and process owners.
Include:
Evidence to prepare: OT asset register with owner, location, criticality and connections.
A good OT approach is to divide the environment into zones with similar risk and security requirements. Communication between zones should be controlled.
In practice, this means:
Evidence to prepare: OT network diagram, zone description, communication rules and exception list.
Remote access to OT should be approved, time-limited, monitored and protected with MFA. Permanent supplier access without control is one of the biggest risks.
Minimum controls:
Evidence to prepare: supplier access list, permissions, MFA, logs and approval process.
OT monitoring should include industrial communication and process behavior. Monitoring only Windows logins is not enough.
Observe:
Evidence to prepare: OT monitoring scope, alerts, logs and escalation procedure.
In OT, every change can affect the process. Updating software, changing firewall rules, modifying a PLC program or changing HMI configuration should be controlled.
The change process should include:
Evidence to prepare: OT change register, approvals, tests and rollback plan.
OT backup is not only office files. The company must protect configurations, controller programs, SCADA projects, recipes, device parameters and technical documentation.
Check backup of:
Evidence to prepare: OT backup list, latest backup date, recovery test result and responsible person.
An OT incident cannot be handled only by IT. The plan must involve automation, maintenance, production, safety, management and suppliers.
The plan should answer:
Evidence to prepare: OT incident response plan, contact list, scenarios and tabletop exercise result.
NIS2 and the amended Polish KSC Act increase the importance of cybersecurity in sectors such as energy, transport, water, wastewater, healthcare, digital infrastructure, manufacturing, chemicals, food and public administration.
For industrial and infrastructure organizations, this means that OT Security may become part of risk management, board responsibilities, audits, incidents and compliance evidence.
IEC 62443 is a series of standards for industrial automation and control systems security. It is one of the most important reference points for OT Security because it reflects the specific nature of industrial systems, stakeholder roles, risk assessment, zones, conduits and technical requirements.
In practice, IEC 62443 helps answer:
Not every IT practice fits OT. OT requires consideration of process, safety, production windows, legacy systems and physical risk.
IT talks about vulnerabilities and logs. OT talks about process, availability and operator safety. Without a shared language, conflict replaces cooperation.
Many organizations do not have an up-to-date list of PLCs, HMIs, engineering workstations, remote connections and suppliers. Without this, risk cannot be managed.
Permanent supplier access, no MFA and no logs are among the most important OT Security gaps.
A company may have office data backup, but not a current copy of the PLC program, SCADA project or HMI configuration. After an incident, this can significantly delay recovery.
If the response plan has not been tested, the team may not know who decides about process shutdown, segment isolation or supplier communication.
A manufacturing company has modern IT systems, but its OT environment developed separately over the years. The plant has several production lines, PLCs, HMI panels, a SCADA server, engineering workstations and remote access for a maintenance supplier.
During an initial assessment, it turns out that nobody has a full list of OT devices. The supplier has permanent VPN access, some passwords are shared, PLC project backup has not been tested and IT does not know the details of the industrial network.
The problem is not the lack of one tool. The problem is lack of visibility, segmentation, access control and a shared IT-OT process.
The company starts with basics: inventory assets, map connections, restrict remote access, test configuration backup and prepare an OT incident response plan. Only then does it implement monitoring and advanced controls.
ccyber.io helps companies understand and organize OT Security without copying IT methods one-to-one into industrial environments.
We can support your organization with:
The best first step is a short OT Security assessment. It helps determine which processes are critical, what IT-OT connections exist, which suppliers have access and where risk is highest.
OT Security is the protection of operational and industrial systems that control or monitor physical processes. It applies to PLCs, SCADA, DCS, HMI, industrial networks, robots and automation systems.
IT focuses mainly on data, applications and users. OT focuses on physical processes, production, availability, human safety and equipment control.
An OT outage can stop production, disrupt service delivery, affect human safety or damage equipment. That is why availability and process stability are often more important than classic data confidentiality.
Not always. Aggressive scanning can disrupt older devices and industrial communication. OT requires controlled testing, passive analysis and agreement with automation and production teams.
Sometimes yes, but in practice many OT environments have connections to IT, suppliers, cloud, reporting systems or remote service. Do not assume an air gap exists unless it is verified.
IEC 62443 is not always legally mandatory, but it is one of the most important OT Security standards. It can support risk assessment, segmentation, supplier requirements and building an OT Security programme.
They may. Organizations in sectors such as energy, transport, water, wastewater, healthcare, manufacturing, chemicals, food and digital infrastructure may have cybersecurity risk management obligations that also include OT systems if those systems are critical to service delivery.
The best starting point is OT asset inventory, IT-OT connection mapping, identification of critical processes, remote access review and configuration backup check.
OT Security differs from IT Security because it protects not only systems and data, but primarily the physical process, human safety, availability and operational continuity.
The biggest mistake is treating OT like normal IT. In industrial environments, every change, update, scan, restart and isolation decision must be coordinated with production, automation and safety.
Good OT Security starts with visibility: asset inventory, process understanding, connection mapping, segmentation and remote access control. Advanced tools, monitoring and a full IEC 62443 roadmap come after that.
AI Security for Companies: Where Should You Start?
AI Security does not start with banning artificial intelligence. It starts with an inventory of AI tools, acceptable use rules, data classification, access control, vendor assessment, data leakage prevention, training and monitoring risks such as shadow AI, prompt injection, deepfakes and overreliance on AI outputs.
Prepared by: CCyber Editorial Team
Companies should start AI Security with a simple and practical programme: identify which AI tools employees use, what data is entered into them, which processes depend on AI, who approves tools and what controls are required. The first priorities are an acceptable AI use policy, data classification, access control, vendor assessment, employee training, shadow AI monitoring, LLM application security and an AI incident response plan.
July 2026
AI Security means securing systems, processes and data related to artificial intelligence. It includes secure use of ready-made AI tools as well as security of applications, models, integrations, training data, prompts, outputs, AI agents and automation.
In practice, AI Security answers the following questions:
AI Security is not about blocking innovation. The goal is to help the company use AI faster, but without uncontrolled risk.
Artificial intelligence has entered companies faster than many other technologies. Employees use it to write emails, analyze documents, summarize meetings, generate code, prepare offers, translate content, analyze data and support customers.
The problem is that many organizations do not know:
This creates shadow AI risk, meaning the use of AI tools outside the knowledge and control of the organization. Shadow AI is especially risky when employees paste customer data, personal data, source code, company secrets, contractual documents or financial information into public tools.
You cannot secure what you cannot see. The first step is an inventory of AI tools used officially and unofficially.
The inventory should include:
Evidence to prepare: AI tools register, business owner, vendor, data type, purpose of use and approval status.
The tool name alone is not enough. What matters more is how the company uses AI. The risk level depends on the use case.
Example use cases:
Not every use case has the same risk level. AI used to improve the style of an email has a different risk profile than AI used for candidate selection, customer assessment, financial data access or automated action in business systems.
Evidence to prepare: list of AI use cases with risk rating: low, medium, high.
The biggest starting issue is data. Employees often do not know whether they can paste a contract, customer data, CV, source code, financial report or strategy document into AI.
The company should clearly define what must not be pasted into public or unapproved AI tools.
Commonly prohibited data should include:
Evidence to prepare: data classification and rules for using data in AI tools.
An AI policy does not need to be 50 pages long. At the beginning, it should be short, clear and understandable for employees.
A good policy should answer:
The policy should be supported by training. A document alone is not enough if employees do not understand examples from their daily work.
Evidence to prepare: AI use policy, employee acceptance confirmation and training materials.
AI often operates as an external service. This means data, prompts, files, outputs and metadata may be sent to a vendor. The company should understand how the vendor protects data and what contractual terms apply.
When assessing an AI vendor, check:
Evidence to prepare: AI vendor assessment, accepted contractual terms, DPA and tool approval decision.
AI tools should be managed like other business systems. Access should be controlled, monitored and removed when an employee leaves.
Minimum access controls:
If an AI tool has access to email, files, CRM, code repositories or financial systems, it should be treated as a high-risk system.
Evidence to prepare: AI user list, SSO/MFA configuration, roles, administrators and latest access review.
If the company builds its own chatbot, LLM application, AI agent or model API integration, the risks are higher than when using a ready-made tool.
Consider at least:
An LLM application should be treated as high risk if it has access to sensitive data, users, payments, internal systems or can automatically take actions.
Evidence to prepare: AI application threat model, data list, integration list, permission controls, prompt injection tests and activity logs.
In many processes, AI should support humans, not replace decisions without control. This is especially important for decisions about customers, employees, finances, security and legal matters.
Human-in-the-loop means that a human:
The biggest mistake is treating AI output as automatically true. AI can produce convincing but incorrect answers.
Evidence to prepare: decision process description, human role, approval points and AI output verification rules.
AI Security does not end with policy and training. The company should monitor whether tools are used according to rules and whether incidents occur.
Monitor:
For AI applications, it is useful to log prompts, outputs, decisions, tools used and actions performed by the AI agent, while respecting privacy and data minimization principles.
Evidence to prepare: AI incident register, usage logs, alerts and periodic AI risk report.
The best AI policy will not work if employees do not understand how AI can harm the company. Training should be practical and example-based.
Training should cover:
Evidence to prepare: training attendance list, materials, knowledge test and refresher schedule.
Shadow AI is the use of AI tools outside the knowledge and control of the organization. It can involve public chatbots, browser extensions, mobile apps, transcription tools, presentation generators or coding plugins.
The risk is that the company does not know what data is sent to the tool, where it is processed and who can access it.
An employee may paste customer data, a contract, personal data, code, a strategy document or financial information into AI. Even if done with good intentions, the company may lose control of the information.
Prompt injection is an attempt to manipulate an LLM application through specially crafted instructions. It can lead to data disclosure, rule bypass, undesired action or ignoring system instructions.
An AI agent that can take actions in systems creates higher risk than a chatbot that only returns text. If the agent has access to email, files, CRM, internet, financial systems or code repositories, its permissions must be limited.
AI makes it easier to create fake images, voices and video. This increases the risk of executive impersonation, urgent payment fraud, bank account change fraud and employee manipulation.
AI can generate convincing errors. Overreliance on AI outputs can lead to poor business decisions, legal mistakes, code defects, incorrect data analysis and wrong customer communication.
An AI vendor may change terms, model behavior, processing location, data usage or security posture. The company should monitor critical AI vendors like other technology suppliers.
Employees should know which AI tools are allowed for work. If they want to use a new tool, there should be a simple approval path.
Personal data, customer data, company secrets, passwords, API keys, restricted code and confidential documents should not be pasted into public or unapproved AI tools.
AI output should be treated as a suggestion, not as automatic truth. Before using an output in a decision, offer, code, analysis or customer communication, it should be verified.
If an AI tool has access to email, files, CRM, code repositories or production systems, its permissions should be limited to the minimum necessary.
Employees should know where to report situations where they pasted the wrong data into AI, a tool behaved suspiciously or AI output caused an error.
A complete AI ban often leads to shadow AI. Employees will still look for tools that help them work faster. A better approach is clear rules, approved tools and training.
A company cannot manage risk if it does not know where AI is used. Inventory is the foundation of every AI Security programme.
The key question is not only “which tool do we use?”. The more important question is: what data goes into AI and what impact does AI output have on business decisions?
AI can be wrong, and incorrect answers often look convincing. Human verification is required in business processes.
An AI agent with access to systems can take real actions. Without limits, logs and approvals, it can become a new source of operational risk.
AI vendors process data and may become critical to business processes. They should be assessed for security, privacy, contracts, data retention and incident handling.
The AI Act introduces a risk-based approach and distinguishes between prohibited AI systems, high-risk systems, transparency risks and minimal-risk systems. For companies in the EU, this means assessing whether a specific AI use case may be subject to regulatory requirements.
ISO/IEC 42001 concerns AI management systems. It is useful for organizations that want to structure policies, roles, processes, risks, documentation and continual improvement in AI.
NIST AI RMF helps manage AI risk through the Govern, Map, Measure and Manage functions. It is a practical way to translate AI from broad principles into a risk management process.
OWASP LLM Top 10 helps technical teams understand key LLM application risks, including prompt injection, insecure output handling, data poisoning, model denial of service, supply chain vulnerabilities, sensitive information disclosure, excessive agency and overreliance.
A service company has 120 employees. Employees use public AI tools to write proposals, analyze contracts, translate documents and generate marketing content. IT does not have a full list of tools, and the board assumes the topic is not urgent because the company does not build its own AI model.
A short assessment shows that employees have pasted customer data, contract fragments, confidential documents and source code into AI tools. Some tools operate as browser extensions, some have access to email and some accounts were created with private email addresses.
The problem is not the use of AI itself. The problem is the lack of rules, risk ownership, data classification, approved tools and access control.
Within 30 days, the company can reduce risk: create an AI tool register, prohibit pasting confidential data into public tools, approve secure enterprise versions, train employees and introduce a process for approving new tools.
ccyber.io helps companies use AI safely, practically and without blocking innovation. We focus on real risks: data, employees, vendors, LLM applications, governance and control evidence.
We can support your organization with:
The best first step is a short AI Security workshop. It helps quickly determine where the company already uses AI, what data is at risk, which tools need approval and which actions should be implemented first.
Usually not. A total ban often leads to shadow AI. A better solution is to define approved tools, prohibit confidential data in unapproved systems and train employees.
The best starting point is an inventory of AI tools, use cases, data classification, acceptable AI use policy and employee training.
Shadow AI is the use of AI tools outside the knowledge and control of the organization. It can include public chatbots, browser extensions, SaaS apps and AI tools used through private accounts.
Passwords, API keys, personal data, customer data, confidential documents, company secrets, non-public financial data and restricted source code should not be pasted into public or unapproved AI tools.
Prompt injection is a technique that manipulates an LLM application through specially crafted instructions. It can lead to data disclosure, rule bypass, ignored system instructions or unwanted actions.
No. AI Security also applies to companies using ready-made AI tools, chatbots, copilots, SaaS applications with AI features or model integrations through APIs.
Not every AI use has the same level of obligations. The AI Act follows a risk-based approach. A company should check whether its AI use is high-risk, requires transparency or falls under specific rules.
At least quarterly and whenever a new tool, use case, vendor, system integration or data processing method is introduced.
AI Security for companies should not start with panic or bans. It should start with visibility, rules and controls. The company must know where AI is used, what data goes into tools, who approves use and what risks are accepted.
The most important first actions are AI tool inventory, acceptable use policy, data classification, employee training, vendor assessment and LLM application security.
Organizations that implement AI Security early will be able to use AI faster, more safely and with greater trust from customers, employees and the board.
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.