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.
Funded Cybersecurity Projects: Training and Delivery with CCyber
Preparing a funding proposal, delivering an awarded grant or looking for a consortium partner? CCyber supports training, risk assessment, compliance, implementation and cybersecurity team development. This guide presents collaboration models for beneficiaries, integrators, training providers and funding advisers. It explains how services can relate to the 2026 calls, how to define delivery roles and what to include in a request for a proposal. Supplier selection, cost eligibility and evidence of delivery remain part of the project from the start.
Prepared by: CCyber Editorial Team
CCyber welcomes collaboration on publicly funded cybersecurity projects, from defining the scope through training and implementation to verifying outcomes and supporting project documentation. Engagements can cover a defined delivery scope, subcontracting, specialist support or participation in a consortium.
You do not need to outsource the entire project. Your requirement may concern one training course, a management workshop, risk assessment, safeguard implementation or specialists supporting a larger programme. The scope and participation model must fit the relevant funding conditions.
Already have a project or request for proposals? Send a short description to kontakt@ccyber.io. Include the programme, project stage, required support and deadline. Initial discussions do not require passwords, customer information or vulnerability details.
20 September 2026
The funding reference is CPPC’s overview of cybersecurity calls in 2026. Programme information is distinguished from proposed CCyber engagements. Describing a possible service does not establish its eligibility in every project or guarantee a funding award.
Companies and institutions preparing proposals or delivering funded projects. It also addresses consortium coordinators, IT integrators, technology providers, training organizations, universities, industry bodies and advisers helping clients obtain funding.
The invitation covers individual assignments and larger delivery scopes. Beneficiary or partner eligibility follows the call conditions, not membership of one of these groups alone.
The European Cybersecurity Competence Centre, ECCC, opened DIGITAL-ECCC-2027-DEPLOY-CYBER-11 with a EUR 96 million budget. Applications close on 14 January 2027 at 17:00 CET. Dates and scope are confirmed in the ECCC announcement.
These are European competitions, not a funding allocation reserved for Polish companies. The deadline concerns proposal submission. It is not a common completion date for training, implementation or procurement across every project.
Organizations considering participation should establish who will deliver the required outcomes. The project description needs to connect activities, resources, timing and evidence of results, as explained in the European Commission’s application preparation guidance.
Have you secured funding and need training, risk assessment, documentation or implementation? Send the assignment scope. We can prepare a delivery proposal covering outputs, timing and acceptance arrangements.
You do not need another funding application merely to request delivery of an approved activity. However, its fit with your project and the applicable supplier-selection requirements still need confirmation.
Are you implementing infrastructure, a platform or a service and need the cybersecurity component? We can discuss a defined assignment covering requirements analysis, architecture review, access management, user training or operational procedures.
This model requires clear responsibilities with the prime contractor. Establish who communicates with the customer, approves changes and contributes to the final report. Subcontracting must comply with the funding documentation and contractual arrangements.
Are you developing a project and seeking an organization responsible for skills, implementation security or outcome evaluation? We welcome discussions about a defined CCyber work package.
A beneficiary partner performs its own tasks, has an allocated budget and contributes to reporting. This differs from selling a service. Participation requires confirmation of formal conditions, resources, financing and the legal entity signing the agreement.
Not every role described as a partner receives grant funding. An associated partner does not receive grant funding on the same basis as a beneficiary. The distinctions are explained in the Commission’s participant guidance.
Do you need temporary expertise rather than a complete managed assignment? CCyber’s team augmentation services provide a starting point for discussing capability gaps. Describe the tasks, expected independence, duration and required availability.
Trainer or expert participation in selected workshops can also be agreed. Establish the project’s accounting treatment before engagement. Calling an arrangement team augmentation does not automatically make it an eligible personnel cost.
Are you delivering a development programme but need a specialist cybersecurity module? We can discuss curriculum, materials, teaching and evaluation of learning outcomes.
If you are preparing a customer’s proposal, involve us in defining the technical scope, effort and deliverables. CCyber’s actual involvement should be disclosed according to the project requirements. A joint commercial proposal does not replace the formal identification of beneficiaries, suppliers or subcontractors.
The following proposals develop CCyber’s published service scope. They are examples to tailor, not a catalogue of automatically reimbursable costs.
CCyber’s training offer includes cyber hygiene, phishing, regulations, cloud security, DevSecOps and OT. Programmes can be aligned with employees, management and technical teams.
An agreed learning outcome might be the ability to report an incident, assess a suspicious request or conduct an access review. Define participant tasks, entry requirements and how the result will be checked.
Remote, on-site or hybrid delivery, teaching language, group numbers and access to materials should be agreed before pricing. Not every topic requires a full-day course, and attendance alone does not demonstrate competence.
Cybersecurity project support can cover risk assessment, gap analysis, access-management arrangements, procedures and action planning.
An illustrative package combines a service-owner workshop, risk register and prioritized actions. Connect documents to an actual process rather than commissioning a fixed policy count without an intended use.
Readiness reviews should be distinguished from statutory audits or certification, which may require separate qualifications and independence.
The project offer includes IAM, PAM, MFA, segmentation, cloud security and application security. Implementation discussions need defined environment boundaries, supplier dependencies and acceptance criteria.
We propose connecting technical changes with operating instructions and a controlled test. For example, access controls can be checked through successful authorized activity, denial of out-of-scope operations and effective permission removal.
Industrial testing must be agreed with the process owner. Funding an activity does not authorize interference with operational equipment.
An engagement can also cover security coordination and expert support. CCyber’s managed services include monitoring, response and vCISO support, providing an external security-management function.
A funded project needs a defined service period and arrangements for subsequent financing. Do not assume the grant will pay for indefinite operation. Plan the transfer of knowledge, configurations and responsibilities when the engagement ends.
The following retains the order of CPPC’s topics. Each proposed discussion area describes possible collaboration, not official approval of an individual purchase.
DUALUSE: civilian and defence technologies. Discuss security requirements, risk assessment and user preparation. This is not a commitment to deliver any type of defence technology.
AI4SME: AI solutions for SME cybersecurity. Discuss user needs, pilot security, workshops and verification that participants can use the solution.
EULEG: implementing EU cybersecurity requirements. Discuss compliance scope, procedures, training and evidence of completed activities.
CYBERAI: AI-powered cybersecurity tools. Discuss use cases, access requirements, risk assessment and preparation of operational teams.
REGCABH: submarine cable security. Discuss defined skills-development and organizational activities. The required composition includes competent authorities from at least two Member States, so ordinary collaboration between two companies is insufficient.
COORDPREP: preparedness testing and related actions. Discuss risk assessment, decision exercises, training and agreed safeguard verification. The implementation role must fit the relevant component.
NCC: developing National Coordination Centres. Discuss educational programmes and expert support for the community. NCC involvement is mandatory. The possibility of support to third parties does not mean every such funding opportunity is already open.
Before deciding, check the complete topic conditions, including security restrictions. Alignment of expertise does not establish organizational eligibility.
We welcome enquiries concerning existing projects and approved activities, including those outside this Digital Europe round. Send the assignment scope, delivery conditions and deadline. There is no need to wait for another call to discuss missing expertise.
Adding a provider or changing the scope may require an appropriate procedure. We therefore establish the participation conditions before agreeing a start date.
A full European project may not be the appropriate route for one training requirement. Separately consider programmes using Poland’s Database of Development Services, BUR, and its funding operators, or the National Training Fund, KFS. KFS has local application rounds and conditions to check with the relevant labour office.
Do not transfer funding rates between programmes. For an individual course, verify the permitted scope, provider status, required registrations and eligible start date. Identifying this route does not confirm that every CCyber service already has an active BUR listing.
Training organizers using these instruments are also welcome to discuss participation by CCyber experts. The arrangement must comply with current programme rules, including the delegation of part of a service.
EU grants do not allow action tasks to be subcontracted between beneficiaries of the same grant. Establish partnership around actual participation and budget allocation, not as another label for buying a service. This is explained in the Commission’s participant guidance.
Purchasing a supporting service and subcontracting a project task can fall into different cost categories. The distinction is explained in the Annotated Grant Agreement. An invoice description does not replace assessment of the actual assignment.
The AGA requires best value for money or the lowest price and absence of conflicts of interest. Organizations subject to public procurement law also follow the relevant national provisions. An existing business relationship does not automatically justify direct award.
If CCyber contributes to preparing a procurement procedure, subsequent participation requires assessment of fair competition. Article 85 of Poland’s Public Procurement Law addresses advantages arising from earlier involvement. A discussion or indicative quotation does not reserve a contract.
The scope must fit the approved project, eligibility period and budget category. Check required change approvals and restrictions on double funding of the same costs. Do not assume reimbursement for work performed before an eligible start date.
Documentation depends on the funding model. The Commission distinguishes cost records from evidence of completed work, particularly for lump-sum grants. See its record-keeping guidance.
Illustrative CCyber scenario. A project coordinator needs to prepare teams at several institutions to report and handle incidents. An integrator supplies the technology, but the organizational component is missing.
The proposed CCyber scope can cover role identification, a workshop, procedure refinement and an announced exercise. The objective is not attendance alone. It is verifying that a report reaches the correct person and triggers the agreed response.
Deliverables to agree: a curriculum, materials, training-delivery records, an updated procedure and an exercise report identifying improvements. Participant information should reflect project requirements and data protection principles.
CCyber can discuss this assignment as a contractor or substantive consortium participant. Formal status and budget must be established separately. The same work should not be declared both as a beneficiary’s own project costs and through a subcontracting invoice.
Provide the programme, project stage and assignment requiring support. This may be a proposal concept, a request for a budget estimate or a published procurement procedure.
Agree the audience, activities, outcome and verification method. For training, define groups and delivery format. For implementation, examine the environment and dependencies. The proposal should distinguish fees, VAT and any additional expenditure.
Establish responsibilities, material rights, confidentiality, system access, scheduling and acceptance. Starting work also depends on the applicable procurement and project arrangements.
Activities are accepted against agreed criteria. Records should establish what was done, the scope of testing or training and remaining actions. Reporting support is defined in the contract without promising automatic acceptance of costs by the funding body.
Programme and stage: the call name, topic identifier or procurement link, and whether you are preparing a proposal, hold an award or are delivering a contract.
Required scope: training, assessment, documentation, implementation, testing, specialists or partnership. For courses, include participant and group numbers, language, location or remote format.
Timing and budget: the proposal deadline, expected delivery window and available budget, where known. Include the required supplier qualifications.
Collaboration model: contractor to a beneficiary, integrator subcontractor, consortium partner or a role still to be defined. An unresolved role does not prevent an initial discussion.
A suitable email subject is “Funded project: training, services or partnership”. A non-confidential description is sufficient for an initial review.
The Cybersecurity Funding and Grants category includes guidance on preparing and delivering a Digital Europe cybersecurity project. Practical team development is explored in the Training and Cyber Awareness category. These links lead to Polish-language resources.
Support for funded projects includes funding-route selection, project preparation and agreed assistance with delivery and reporting. You can begin with one assignment rather than commissioning a complete security programme.
We welcome beneficiaries, consortium coordinators, integrators, training organizers and funding advisers. Send your requirement to kontakt@ccyber.io. Explain the outcome you need and your current project stage.
Yes. We can discuss scope, effort and potential outcomes. Initial arrangements do not guarantee funding or supplier selection. Starting work and payment terms require separate agreement.
Yes, an enquiry can concern one assignment. Public funding depends on the project, programme and supplier-selection conditions.
We welcome that discussion. Identify the integrator’s scope and the missing activity so that responsibilities, access and acceptance can be agreed without duplicating work.
No. The role, eligibility, budget and participation conditions must be confirmed. Naming an organization in a concept does not establish entitlement to a grant or a delivery contract.
No. Documentation supports evidence of the agreed work. Eligibility also depends on programme rules, supplier selection, costs and grant agreement conditions.
A funded cybersecurity project may need people, procedures and verified results alongside technology. These are areas in which CCyber’s involvement can be planned when defining the proposal or delivering approved activities.
Define the outcome, select the right collaboration model and connect delivery with evidence. A course, implementation module or consortium contribution should address a real project need rather than merely use an available budget line.
NIS2 Assessment or Readiness? Scope, Costs and Delivery
Does your organization need a NIS2 readiness assessment or help implementing the required changes? This guide compares two service models: NIS2 Diagnoza, focused on assessment, and NIS2 Gotowość, covering readiness and implementation. It explains the process from kick-off and document review to reporting and delivery, together with indicative costs, timelines and conditions to agree before starting. An incident-procedure example illustrates the difference between identifying a gap and verifying that it has been resolved.
Prepared by: CCyber Editorial Team
NIS2 Diagnoza identifies the organization’s gaps and required actions. NIS2 Gotowość extends the work to agreed implementation activities. The appropriate choice depends primarily on whether the organization understands its current position and can deliver improvements itself.
Both models should start with an agreed scope, responsibilities and verification criteria. An assessment should not end with generic observations, while implementation should not be considered complete merely because documents have been prepared.
The practical distinction is straightforward: an assessment establishes what needs to change. Completed and verified implementation demonstrates what has improved.
20 September 2026
The service names, four process stages and indicative price and duration ranges come from the service-model description supplied for this article. They are not market-rate research or a binding quotation for every organization. The proposed deliverables, acceptance criteria and scenario below are CCyber recommendations to be agreed in the engagement.
Business owners, boards, IT managers and people coordinating preparation for NIS2 and Poland’s National Cybersecurity System Act, known as KSC. It is particularly relevant to organizations comparing advisory proposals, working with existing documentation or seeking help implementing earlier recommendations.
Before assessing the organization’s current state, establish the applicable requirements. For a Polish organization, this involves its activities, KSC applicability criteria, entity status and relevant special provisions. This approach is reflected in the Ministry of Digital Affairs guidance on essential and important entities.
Applicability analysis and gap assessment are different tasks. The first determines which duties apply. The second compares the current state with those requirements. A proposal should specify whether applicability analysis is included or whether the engagement relies on an existing assessment.
The NIS2 applicability guide in the Cybersecurity for SMEs category provides further background.
The purpose is to understand the organization and agree how the engagement will operate. Discuss services, important systems, providers, existing documentation and the intended outcome. Establish who can supply information and approve decisions.
Proposed output: confirmed scope, an information request, contacts and a schedule. A one-hour meeting does not replace detailed applicability analysis or examination of the entire environment.
In the process description, assessment is the evaluation stage. Materials are compared with the agreed requirements, and declarations are checked against available information about systems and operational processes.
Proposed scope to agree: review policies, registers, reports and selected configurations, then clarify discrepancies with responsible personnel. The result should distinguish verified information, missing implementation and areas that could not be checked.
The 3-5-day range does not promise complete testing of every application and location. Assessment does not automatically include penetration testing, active scanning or production changes. Such activities require separately agreed scope and safety arrangements.
The report should help determine what to improve, why it matters and which actions take priority. “Improve access security” is inadequate without identifying the affected system, the problem and the intended result.
Proposed output: a management summary, justified findings and an action plan. Each action should identify an owner, dependencies, a deadline and a verification method. Establish which conclusions require further investigation.
Following the assessment, the organization can implement actions internally or agree further support. In this model, the broader implementation stage corresponds to NIS2 Gotowość.
The objective goes beyond supplying another set of recommendations. Scope should distinguish policy development, configuration, coordination and outcome verification. Each party needs to understand what the consultant delivers, what requires an administrator and what depends on management approval.
Proposed output: implemented and verified actions within the agreed scope, followed by operational handover. Activities outside the engagement should be identified rather than hidden behind an overall “ready” status.
Model scope: NIS2 readiness assessment and identification of gaps, risks and required actions.
Indicative budget: PLN 10,000-20,000.
Duration range: 5-30 days.
This model addresses the need: “We do not know where we stand or how much work remains.” It can support decisions about budgets, responsibilities and commissioning specific improvements.
It is also worth considering where documentation exists but has not been checked against actual operations. The objective should not be to rewrite everything automatically, but to establish which materials remain useful and what is missing.
Boundary: identifying a gap does not fix it. The report can support programme planning, but does not activate safeguards or independently establish full compliance.
Model scope: preparing the organization for NIS2 requirements through practical recommendations, an action roadmap and agreed implementation.
Indicative budget: PLN 15,000-40,000.
Duration range: 1-12 months.
This model addresses the need: “We understand some of our gaps but need help resolving them and coordinating delivery.” The roadmap should establish the sequence of work and its dependencies.
An agreed scope might include updating procedures, implementing access arrangements or preparing and testing incident handling. Specific activities, system coverage and delivery responsibilities must be defined in the proposal.
“Gotowość”, meaning readiness, describes the engagement’s objective, not an unconditional guarantee of a favourable inspection outcome. Identify which requirements the project covers and which evidence supports the assessment. Purchasing the package does not automatically fulfil every organizational obligation.
The process description gives 3-5 days for analysis, while the Diagnoza model gives 5-30 days. It does not specify whether these are working days, calendar days or team effort. They should neither be treated as equivalent nor added together without clarification.
Agree in the proposal: the event that starts the schedule, expected report date, time for providing information and arrangements for reviewing findings. Separating analytical effort from elapsed project time is useful, but must be confirmed in the delivery plan.
The supplied model does not specify VAT treatment. The PLN 10,000-20,000 and PLN 15,000-40,000 figures should therefore be treated as indicative ranges requiring clarification. An individual proposal should state the price, VAT and billing method explicitly.
Nor is it confirmed whether the Diagnoza fee is included in Gotowość, credited towards it or billed separately. Do not automatically add the figures or assume a combined discount.
Before commissioning, establish whether the quotation covers licences, hardware, work by the existing IT provider, testing, travel and subsequent operation. The stated ranges do not settle those questions.
A 1-12-month duration does not mean unlimited team availability for the same price. The proposal should define activities, availability, acceptance and change approval. A larger scope may require a different quotation.
For organizations meeting the criteria when the amendment entered into force on 3 April 2026, the relevant transition period provides for implementation by 3 April 2027. Entities required to self-register must also meet the 3 October 2026 deadline. Details are provided in the official Ministry of Digital Affairs timetable.
A twelve-month project starting in autumn 2026 cannot assume that activities required by April 2027 will be delivered only at its conclusion. Similarly, waiting for an assessment report does not justify missing an earlier registration deadline.
CCyber recommendation: distinguish actions required before the applicable deadline from subsequent operation and improvement. Organizations following another route or meeting the criteria later need a separately established schedule.
Appoint one coordinator to collect information and route questions to the appropriate people. That person does not need to know every configuration, but should know who can verify it and who approves decisions.
Prepare initially: a business and critical-service overview, system and supplier lists, existing policies, the risk register and earlier review results. Mark unavailable material as missing. Do not create misleading evidence merely to complete an information request.
Technical questions can be supported by current reports or controlled demonstrations of configurations. Direct access, site visits and tests should follow the agreed needs and scope. Being able to hold an online meeting does not establish that every assessment can be completed entirely remotely.
Agree a secure repository, authorized recipients and access termination arrangements. Do not send passwords, private keys or complete customer databases as ordinary attachments for an introductory discussion.
We recommend a report identifying scope, assessment date, requirement sources, verified findings, unassessed areas and actions. Every significant gap should describe the consequence and a proposed response.
Do not confuse missing evidence with evidence that a safeguard is absent. Where a configuration was unavailable, the appropriate conclusion may be “unverified”, not automatically “met” or “not met”.
Agree which materials will demonstrate completion: an approved procedure, configuration, test result or operating record. When the project ends, the organization should know who maintains the safeguard and when it needs checking again.
Evidence examples and mappings are available in ENISA’s NIS2 Technical Implementation Guidance. It supports implementation of Regulation 2024/2690 for specified entities. It is not automatically a complete checklist for every organization covered by KSC.
Distinguish “planned”, “implemented” and “verified”. For remaining gaps, identify the next decision, owner and deadline. Completing 90% of project tasks does not independently establish 90% statutory compliance, particularly where the remaining gap affects an important service.
Illustrative CCyber scenario. A services company has an incident-response document naming its administrator. However, no deputy or alternative contact method has been agreed for a business-email outage.
During Diagnoza, the team records the gap, its scope and the possible consequence: delayed response. It recommends assigning a deputy, agreeing communication and verifying the process. The problem has been identified, but not yet resolved.
During Gotowość, the organization and provider deliver the agreed changes. Management approves responsibilities, the provider confirms availability and the procedure is updated. An announced exercise follows, without sending a fictional incident through an authority’s production reporting channel.
Acceptance criterion: the right person receives the report, understands their role and starts the agreed actions within the established time. The result covers the tested scenario, not every possible incident.
Exercise preparation is explored in the Incident Response and Business Continuity category.
A consultant can assess, recommend and deliver agreed activities. The organization must still make decisions, ensure relevant personnel participate and maintain the resulting processes.
Outsourcing the work does not remove management’s statutory accountability. Articles 8c-8d of KSC address responsibility where duties are entrusted to others, together with decisions, resources and oversight.
Identify the implementer, approver and operational owner separately. Do not assign every action to the consultant when delivery depends on a system provider or a business decision.
The EU Cyber Regulations and Compliance category explores obligations and evidence in greater detail. This article supports selection of an engagement scope and delivery arrangements rather than repeating the entire NIS2 checklist. The linked CCyber blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with implementing policies, procedures and controls. An engagement can focus on understanding the current state or delivering agreed improvements.
Choose the outcome you need: an assessment or implementation support. Prepare a description of the business, important systems, current progress and the applicable deadline. This supports agreement on scope, time calculations, the full price and acceptance arrangements before the project starts.
Not automatically. An audit under Article 15 has specified assessor and independence conditions. A readiness assessment or implementation engagement does not become that audit merely by changing its name. The proposal should identify the type of assessment explicitly.
Implementation support is optional in the described model. Agree the report format and recommendation detail so that the internal team or another provider can translate findings into tasks.
Do not assume so. First check the scope, current requirements, evidence quality and environmental changes. Earlier work may be reusable, but should not be treated as current solely because of the document date.
There is no basis for an unconditional promise. The engagement can define outcomes, acceptance criteria and evidence for an agreed scope. The authority assesses applicable obligations and the organization’s actual position, not simply whether it purchased a package.
Agree prompt escalation and identify the decision-maker. A significant threat or suspected incident should not wait for the final report. Technical action still requires impact assessment and appropriate authorization.
NIS2 Diagnoza supports decisions based on identified gaps. NIS2 Gotowość adds delivery of agreed improvements. The four-stage process connects understanding the organization with reporting and optional implementation.
Compare proposals through scope, responsibility and outcomes, not price or elapsed days alone. A well-defined engagement shows what was checked, what improved and which activities remain with the organization.
What Do Regulators Expect? Cybersecurity Controls and Documentation
ISMS, risk management, IAM, cryptographic keys, penetration testing, disaster recovery, business continuity, SOC monitoring and incident response: how do these areas form one programme? This guide explains how to prepare for regulatory assessment, distinguish legal requirements from implementation choices and organize the supporting documentation. It covers risk registers, RACI, control matrices and technical reports. An encrypted-database recovery example shows why separate policies cannot replace testing the complete service.
Prepared by: CCyber Editorial Team
Preparing for regulatory assessment means demonstrating that the organization understands its applicable obligations, manages risk and performs the required activities. Documentation should explain the rules and show that they have been followed. A list of purchased tools or a folder of signed policies is insufficient.
ISMS, IAM, key management, testing, recovery and monitoring need to connect with specific services and responsibilities. However, not every institution needs an identical SOC, the same penetration test or the same number of documents.
Establish the requirement first. Then define implementation and evidence that genuinely demonstrates the outcome.
20 September 2026
This article develops the supplied notes, retaining their ten security areas and documentation topic. The notes do not identify a specific regulator, jurisdiction or type of exchange. NIS2, Poland’s KSC and DORA examples are additional context supported by official sources, not an assertion that every reader is subject to all these regimes.
The review questions, evidence examples and documentation model are CCyber recommendations. They are not an official checklist or a complete catalogue of obligations.
Boards, institutional leaders, CISOs, IT teams, compliance professionals and auditors. It is particularly relevant to organizations preparing a regulatory programme, licensing application, inspection or internal review, and to buyers commissioning security documentation and services.
The statement “the regulator expects” needs an identifiable basis. Requirements may arise from legislation, authorization conditions, supervisory decisions or applicable guidance. Customer commitments and voluntarily adopted standards are separate sources.
NIS2 requires appropriate and proportionate risk-management measures. In Poland, the applicable duties must be established under KSC. DORA concerns specified financial entities and contains special arrangements and exclusions. Do not apply every requirement together without assessing scope.
The word “exchange” alone does not establish the regulatory regime. Identify the legal entity, its services, authorization basis and jurisdiction. Capital-market infrastructure should not be equated with every exchange or trading platform.
Prepare a register linking entity, service, obligation, source, deadline and owner. This helps avoid both missing requirements and commissioning work whose purpose nobody can explain.
ISMS means Information Security Management System. ISO/IEC 27001 addresses establishing, implementing, maintaining and improving that system. It includes people, processes and technology, not merely a document called “Security Policy”. Its scope is explained by ISO.
Implementing an ISMS is also identified among the obligations of relevant KSC entities. This should not automatically be equated with a requirement to obtain ISO certification.
Review: system scope, management accountability, objectives, reviews and remediation arrangements. Proposed evidence includes approved rules, decisions and operating records rather than an implementation declaration alone.
Article 21 of NIS2 connects safeguards with risk, operational scale and potential incident consequences. It does not reduce assessment to a vulnerability count or the purchase of a particular product. See the NIS2 Directive.
Review: does the risk describe a possible event and its service consequences, have an owner and lead to a treatment decision? “No MFA” identifies a gap. It does not yet explain which permissions could be compromised or what that means for the organization.
In the proposed register, connect the scenario with an action, deadline and assessment of the risk remaining after safeguards are applied. Risk acceptance should not be used as a substitute for meeting a legal duty.
IAM means identity and access management. For entities subject to the relevant DORA requirements, Articles 20-21 of Delegated Regulation 2024/1774 specify identity and access arrangements, including account lifecycles. This is a regulatory example, not a requirement to purchase a product labelled IAM.
Review: who approves access, how are role changes and departures handled, and does coverage include administrators, suppliers and application accounts?
Proposed evidence connects the request, decision, configuration and verification of access removal. An active-account report alone does not establish that every account is necessary. Further guidance is available in the Identity, Access and Cloud Security category.
“The data is encrypted” does not describe key management. Articles 6-7 of Regulation 2024/1774 address cryptography and key lifecycles within the applicable DORA scope, from creation and storage to renewal, revocation and destruction.
Review: who can use a key, how would loss or unauthorized use be identified, and how would the ability to decrypt information be recovered after a failure?
Proposed evidence includes assigned ownership, access configuration and controlled test results. Audit documentation should identify protected material and its location, not disclose private-key values or passwords.
Penetration testing, compliance auditing and vulnerability scanning are different activities. Under DORA, penetration testing is one testing method. Advanced threat-led penetration testing, or TLPT, applies to designated entities. The scope is established in DORA Articles 24-26.
Review: does the test cover the relevant service, is its scope authorized and do findings lead to remediation and verification?
The proposed evidence package includes test scope, findings, treatment decisions and retest results. A penetration-testing invoice does not demonstrate that vulnerabilities were fixed. Testing that could disrupt production needs separate authorization and safeguards.
Disaster recovery, or DR, concerns restoring technical capabilities after a major disruption. Its relationship with broader contingency planning is explained in NIST SP 800-34 Rev. 1. This is technical guidance, not a universal Polish legal requirement.
Review: does the plan include applications, information, configurations, identities, keys and supplier dependencies? Agree recovery-time requirements and acceptable loss of data currency.
Proposed evidence is restoration in an agreed environment with confirmation that the result is usable. Successful completion of a backup job is not that test.
Business continuity asks a broader question: how will the organization maintain necessary functions during disruption? NIST discusses alternate locations, equipment and temporary operating methods in its contingency-planning resources.
Review: service priorities, people, deputies, communications and acceptable operating limitations. Where appropriate, the plan should also define conditions for safely suspending a service.
Proposed evidence is an exercise involving the process owner. Do not treat a running server as proof of continuity when users still cannot serve customers or complete a required operation.
A Security Operations Centre, or SOC, is a way of organizing security operations. The supplied notes do not identify a legal basis requiring every company to operate its own centre.
For example, Annex point 3.2 of Regulation 2024/2690 requires monitoring, logging and appropriate response from entities within its scope. Its detailed requirements should not be generalized to every organization.
Review: log sources, system coverage, service hours, escalation and authority to act. Internal teams and external services both need explicit responsibilities. Proposed evidence is a controlled test from event to response, not merely an alert-volume chart.
A scan provides information but does not replace vulnerability management. Patching in particular requires identification, prioritization, deployment and verification. This process is described in NIST SP 800-40 Rev. 4.
Review: can the finding be connected to a system owner and the service it supports? Are remediation deadlines, exceptions and temporary safeguards justified?
Proposed evidence links detection and change records with reassessment. A task closed by its implementer should not automatically mean that the issue no longer exists.
Incident preparation should connect with risk management, detection and recovery. This approach is described in NIST SP 800-61 Rev. 3.
Review: who assesses events, contains consequences, preserves information and makes business decisions? Separately assign external reporting obligations, including their triggers, recipients and deadlines.
Proposed evidence is the timeline of a real incident or a clearly labelled exercise. A supplier’s phone number alone does not establish readiness. Practical exercise guidance is available in the Incident Response and Business Continuity category.
The supplied notes include this range without a source, organizational description or counting method. We do not treat it as a verified industry benchmark or a legal requirement.
One count might include an overarching policy, instructions for dozens of systems, forms, annexes and local versions. Without a common definition, file counts reveal little about scope or quality.
This does not make documentation unnecessary. A required policy or procedure remains an obligation even where the technical safeguard operates. Conversely, an extensive document catalogue does not establish that its activities have been performed.
A better purchasing criterion: request a defined set of obligations, documents and outcomes rather than a “200-procedure package”.
The following structure connects security policies, risk registers, process descriptions, RACI, control matrices, operating procedures and technical reports. It is a proposed working model, not a folder structure imposed by every regulation.
These establish objectives, scope, accountability and principles. For example, an access policy identifies who approves permissions and how exceptions are handled. It does not need to contain click-by-click instructions for every application.
The risk register explains what needs managing. The process description shows the workflow, inputs, decisions, participants and output. Connect the two so that the reason for an activity is clear.
RACI distinguishes the people performing a task, the accountable owner, those consulted and those informed. The roles are explained in the official Section508.gov guidance. It is used here to explain the method, not as the basis of cybersecurity obligations.
In practice, establish who authorizes urgent access removal and who performs it. Putting “IT” in every cell does not resolve the relationship between an administrator, provider and service owner. A RACI assignment does not transfer statutory accountability.
These connect the requirement, safeguard, scope, owner, assessment method and evidence. One control can support several obligations, but only to the extent that it actually meets them.
ENISA publishes evidence examples and requirement mappings for implementing Regulation 2024/2690. The material is useful, but its scope is not a universal catalogue for every company and institution.
These explain how to perform activities such as removing access, renewing a key, restoring a service or escalating an alert. They should establish triggers, permissions, steps and completion criteria. Test them with the people expected to use them.
These show a state or result: configuration, a completed review, penetration-test findings, incident activity or recovery. Identify dates, scope, limitations and follow-up work. A report without decisions on significant findings leaves work outstanding.
We recommend linking requirement → risk → rule → procedure → execution → result → remediation.
Each document should have an owner, scope, version, approval status and review arrangements. A service change should trigger consideration of related materials, not merely a new date on the cover.
When consolidating documentation, do not remove required content in the name of brevity. Duplicates can be reduced while preserving necessary approvals, scope and the ability to reconstruct earlier decisions.
Also establish access and retention arrangements. Documentation can reveal weaknesses, suppliers and architecture. Provide it to the authority under the applicable request through a secure channel, without adding unnecessary secrets or information.
Illustrative CCyber scenario. An organization has an encryption policy, a disaster recovery plan and a report confirming a successful database backup. Each document has been approved separately.
An agreed exercise reveals that the recovery team has no available route to use the key needed for decryption. Access depends on an identity service that is also unavailable in the failure scenario. Consequently, the backup cannot support restoration within the intended time.
The organization updates dependencies, emergency permissions, key ownership and recovery instructions. It then repeats a controlled test and obtains application acceptance from the business owner. It does not solve the issue by writing the key into a broadly accessible document.
The lesson: separate confirmations of encryption, backups and IAM do not establish that the complete recovery scenario works.
Establish the basis and scope. Identify the regime, assessment stage, systems and services. A pre-launch authorization process may need different material from an evaluation of several months of operation. Do not present planned implementation as completed work.
Select an end-to-end scenario. Follow one important service through access, keys, monitoring, incidents and recovery. This does not replace the full required assessment scope, but can expose inconsistencies.
Assess documentation and operation separately. Distinguish missing rules, missing implementation, missing evidence and a failed test. These are different problems requiring different actions.
Approve remediation. Each significant gap needs an owner, deadline and reassessment method. A remediation plan records the response to a gap, but does not automatically turn non-compliance into compliance.
Detailed guidance on obligations, Statements of Applicability and evidence is available in the EU Cyber Regulations and Compliance category. This article connects the security scope with documentation rather than replacing a detailed implementation guide. The linked CCyber blog resources are in Polish.
Through its EU regulatory compliance services, CCyber supports gap assessment, policy preparation and updates, responsibility mapping, registers and audit materials.
Check whether your documentation reflects actual operations. Prepare the applicable obligations, important services and open issues to define the review. The objective should be a plan for closing specific gaps rather than increasing the file count.
That should not be inferred merely from a monitoring obligation. Check the applicable rules, coverage and response availability. An internal team or external service may form part of the solution where the relevant requirements are met.
Scope and frequency depend on applicable rules, risk and changes. DORA distinguishes a testing programme from advanced TLPT. Do not apply one schedule to every organization and system.
No. A certificate concerns a defined management-system scope. Applicable legal obligations still need assessment, including registration, notifications and sector-specific requirements.
It can provide a starting point, but must be adapted to services, roles and configurations. Before approval, check that the organization can perform the described activities and is not claiming safeguards that have not been implemented.
No. They reflect the supplied notes. A complete assessment may need other areas, such as assets, suppliers, training, physical security or software development. Additions should follow applicable requirements and risk.
Regulatory preparation connects management, technology and documentation. ISMS, risk, IAM, keys, testing, recovery, continuity, monitoring, vulnerabilities and incident response should operate as connected processes.
Do not begin with a document count. Begin with what the organization must be able to do and how it will demonstrate that capability. Documentation should support performance and verification, not replace them.
NIS2 Changes in 2026: What the EU Proposal Means for SMEs
The European Commission has proposed targeted NIS2 amendments covering technical requirements, ransomware reporting, certification, supervision and regulatory scope. This guide explains which changes could benefit SMEs, how small mid-caps differ from SMEs and why the proposal does not postpone Poland’s current KSC deadlines. It includes a business scenario and a regulatory change record to help organizations prepare for reform without prematurely stopping their compliance programme.
Prepared by: CCyber Editorial Team
The proposed NIS2 amendments could reduce some administrative burdens and change the classification of certain businesses. They are not a blanket SME exemption or a reason to postpone existing obligations.
For a Polish company, two assessments must remain separate: what Poland’s National Cybersecurity System Act, known as KSC, requires today and what a future reform could change. Leave room to update the programme, but do not remove obligations on the basis of an announcement.
The practical benefit lies in the specific mechanism, not the word “simplification”: fewer additional national requirements, a narrower sector definition or reduced duplication of audits.
20 September 2026
The starting points are the European Commission announcement of 20 January 2026 and the Global Policy Watch analysis of 23 January 2026. We retain the analysis’s six areas of change while checking details against COM(2026) 13 and EU institutional sources.
The legislative status, separate Omnibus IV developments and Polish deadlines supplement the original materials. The scenario, recommendations and change record are CCyber proposals. This article does not replace an individual applicability assessment.
SME owners and boards, IT providers, compliance professionals and companies growing beyond the SME category. It is particularly relevant to businesses already implementing KSC that want to determine whether the proposed reform should affect their scope or budget.
The package includes a proposed revision of the Cybersecurity Act, commonly called CSA2, and separate targeted amendments to NIS2. The Commission connects these with simplified compliance, certification and a stronger role for ENISA, the EU cybersecurity agency.
The Commission estimates that the simplifications would affect 28,700 companies, including 6,200 micro and small enterprises. These are EU-wide projections, not a count of Polish beneficiaries or companies automatically leaving regulatory scope. The source is the official Commission announcement.
Do not combine every announcement into one legal change. The January NIS2 proposal and CSA2 proposal are separate instruments. The proposed single-entry point for incident reporting originates in the earlier Digital Omnibus. Their relationship is explained on the Commission’s NIS2 proposal page.
COM(2026) 13 remains a legislative proposal. The checked procedure record for 2026/0012(COD) indicates that a parliamentary committee decision is awaited. The final scope may differ from the January text.
The draft provides 12 months for Member States to transpose the future directive after it enters into force. This is a proposed deadline for national lawmakers, not an additional year granted to every company from the press-release date.
Planning implication: keep current obligations separate from developments being monitored. Do not turn a potential future simplification into a present-day “not applicable” decision.
The proposal calls for regular assessment of whether further implementing acts are needed. Where the Commission establishes the relevant requirements, Member States would not be allowed to add further technical, methodological or sectoral requirements within that scope. The mechanism appears in the proposed amendment to Article 21(5) in COM(2026) 13.
Potential business effect: less duplicated work when operating across Member States. This does not make every national provision, form and obligation identical. The restriction would apply to the specified requirements and entities covered by the relevant implementing act.
CCyber recommendation: record the source of each requirement. Distinguish EU law, national law and customer commitments. This will make genuine duplication easier to identify after a change, rather than removing activities merely because their descriptions sound similar.
The proposal distinguishes information to be included in future reporting implementing acts from information supplied when requested by the relevant CSIRT or authority. The first category concerns ransomware detection, the attack vector and mitigation. The second concerns ransom demands and any payment associated with a significant incident.
This is not an automatic instruction to immediately submit every detail of every extortion attempt. The conditions in proposed Article 23(12) and (13) matter. A duty to provide information about a payment is not authorization to make that payment.
Clarification of the source article: detailed EU incident rules are not entirely a future development. Implementing Regulation 2024/2690 already addresses matters including incident significance for specified digital providers. Defining significance and harmonizing notification formats are different issues.
CCyber recommendation: organize the recording of demands, decisions and available information. Identify the authority contact and protect the relevant records. Do not replace the current reporting channel with an announced solution whose arrangements have not yet taken effect.
The proposal concerns European certification of an entity’s cybersecurity posture, not merely a product. A certificate demonstrating specified Article 21 requirements would limit additional supervisory audits of those same requirements. Member States could also require the relevant certification.
This does not mean “ISO 27001 instead of NIS2”. The applicable European scheme, certificate validity and exact requirements covered would matter. The organization remains responsible for compliance, as reflected in proposed Article 24(4)-(6).
CCyber recommendation: before budgeting for savings, establish which audit would be replaced and under what legal mechanism. Do not abandon current obligations or purchase a service advertised as a future exemption without a verified legal scope.
ENISA would support cooperation between national authorities and analysis of risks involving entities operating across borders. This direction is also described in the official proposal overview.
This does not make ENISA the sole regulator of every company or establish a universal GDPR-style one-stop-shop. Joint supervisory work does not automatically remove obligations towards the relevant national institutions.
CCyber recommendation: organize information about legal entities, services, countries of operation and system locations. A controlled, consistent dataset will be more useful than several conflicting descriptions prepared separately for each request.
The January proposal refers to Commission Recommendation 2025/1099. It covers enterprises that are not SMEs, employ fewer than 750 people and satisfy at least one of two financial ceilings: annual turnover not exceeding EUR 150 million or an annual balance sheet total not exceeding EUR 129 million.
This expands the abbreviated definition in Global Policy Watch. Employee count and turnover alone do not fully describe the category. The applicable calculation rules for partner and linked enterprises also matter.
Under the proposed model, some Annex I entities could move from essential to important status. Other classification grounds and exceptions would remain. It is incorrect to conclude that every company below 750 employees would leave NIS2 scope.
A classification change can affect supervision. It does not mean security requirements start only after an incident. The distinction between supervision of essential and important entities is established in NIS2.
CCyber recommendation: separately assess applicability, entity category and the resulting duties. “Important rather than essential” and “outside the legislation’s scope” are different conclusions.
On 9 June 2026, the Council announced a provisional small-mid-cap agreement under the separate Omnibus IV package, using fewer than 1,000 employees and ceilings of EUR 200 million turnover or EUR 172 million balance sheet total. See the Council announcement.
Do not automatically import those figures into current Polish KSC rules or the January NIS2 text. Check the specific act, final wording and application date first.
The proposal removes automatic coverage of DNS providers regardless of size. This could matter to micro and small providers, but other grounds for inclusion would still require assessment.
For chemicals, the proposed annex removes distribution from the sector description and refines the covered activities through REACH references. This is more than a change of heading. Details appear in the annex to COM(2026) 13.
The package does not only narrow scope. It also introduces or clarifies categories involving European identity wallets and submarine data-transmission infrastructure. A company assessment must therefore consider all relevant services.
The proposed Article 26(3) amendment extends the representative requirement to essential or important entities not established in the EU but offering services within it. Global Policy Watch notes that the wording’s scope would benefit from further clarification.
This does not mean a Polish company needs another representative merely because it sells services abroad. Establishment and regulatory status are central, not the existence of overseas customers alone.
CCyber recommendation: assign services to specific legal entities within an international group. Do not assume that one EU-established group company automatically settles the position of every other group entity.
The proposal describes planned guidance on supplier security information. Its purpose includes limiting unjustified burdens passed on to companies outside NIS2 scope. This direction appears in the explanatory material and recitals, not as an immediate legal right to reject every customer questionnaire.
CCyber recommendation: connect customer requirements with the service they concern. Prepare current assurance material with an explicit scope and sharing rules. Explain questions that do not apply rather than making inaccurate compliance declarations.
Do not confuse customer requirements with the company’s statutory status. The NIS2 applicability guide in the Cybersecurity for SMEs category explores that distinction.
The EU proposal does not independently change current KSC deadlines. For entities covered by the relevant transitional arrangements, self-registration is due by 3 October 2026 and implementation by 3 April 2027. Not every entity follows the self-registration route. Scope and conditions are explained in the Ministry of Digital Affairs timetable.
CCyber recommendation: do not stop work on access control, data recovery and incident handling solely because classification might change. Separate necessary safeguards from expenditure on activities whose statutory status could genuinely be affected.
Illustrative CCyber scenario. A company employs 120 people and only distributes chemicals. For this example, assume its current assessment established important-entity status solely through that activity.
After reading about the reform, management considers stopping the KSC project. Instead, the team records a conditional assessment: the proposed narrowing may matter, but the final EU text, Polish provisions and absence of another inclusion ground must be checked.
The company continues its currently required activities. It separately marks expenditure for reassessment after a legal change. It does not remove register information or tell customers that its status has ended solely on the basis of the proposal.
It also maintains necessary access and recovery safeguards. Even a future change in regulatory scope would not demonstrate that data-loss or disruption risks had disappeared.
The following template is a CCyber recommendation. It records the reform’s potential effect without confusing the present position with a forecast.
Current obligation: the specific basis, entity, scope and deadline.
Proposed change: the proposal number, provision and document version supporting the assessment.
Conditions: sector, size, role, certification scope or other criteria requiring verification.
Potential effect: which activity, cost or reporting arrangement could actually change?
Decision now: what continues, what is prepared conditionally and what must not yet be treated as settled?
Owner and reassessment: who follows the development, and which event triggers an update, such as publication of the final act or a Polish amendment?
“The EU plans simplification” is not a sufficient status entry. The announcement needs to be connected with a specific organizational decision.
Current obligations, evidence and inspection preparation are explored in the EU Cyber Regulations and Compliance category. This article concerns managing a proposed change rather than replacing a full applicability assessment or KSC implementation plan. The linked CCyber blog resources are in Polish.
The CCyber NIS2 compliance programme covers gap analysis, maturity assessment, action planning and support with policies, procedures and controls.
Identify which activities are required today and which depend on future reform. Your current applicability assessment, service scope and project schedule provide a starting point. The objective is to update specific decisions without promising exemptions from rules that remain applicable.
That does not follow from the proposal. The threshold forms part of a definition also involving non-SME status and financial data. A possible move to important-entity status is not an exemption.
This cannot be assumed from the proposal. The mechanism concerns the relevant European certification and the requirements it covers. Current duties must be assessed under applicable law.
The proposal alone provides no basis for that. A company currently required to submit an application by a specified deadline should fulfil that obligation under the relevant provisions.
No. Different changes concern different groups. A small DNS provider, chemical distributor, cross-border operator and company growing beyond SME status may each have a different position.
The checked sources do not establish a certain completion date. Follow adoption and publication, then the relevant implementing and national provisions. A legislative forecast is not a statutory performance deadline.
The Commission proposal could reduce duplicated requirements and change the position of selected businesses. It is not a signal that SMEs can abandon KSC preparation.
A sound organizational approach has two parallel tasks: perform current obligations and maintain a documented assessment of future changes. This allows the company to benefit from actual simplifications when they apply without making premature decisions.
OT Security in 2026: Risk Assessment for PLC, DCS and SCADA
OT security protects not only systems but also the physical processes they operate. This guide explains PLC, DCS and SCADA roles and shows how to assess risk using IEC 62443 zones and conduits. It covers maintenance access, malware protection, recovery and evidence that safeguards work. It distinguishes NIS2 and Poland’s KSC obligations from DORA’s scope, and the potential of AI and digital twins from promises of automatic protection. An illustrative scenario connects a threat with a requirement and a safe verification method.
Prepared by: CCyber Editorial Team
OT security matters because compromise of an industrial system can affect a physical process: water pumping, production, temperature, pressure or service availability. Protection needs to address devices, software, communication and how they are operated.
A sound risk assessment starts with the process and potential consequences, not a tool purchase. Identify assets and connections, establish security zones, select safeguards and verify them without endangering production. The outcome should be an action plan with owners and evidence of completion.
20 September 2026
This article develops the supplied notes on OT security, risk assessment, evidence and PLC, DCS and SCADA systems. Definitions and requirements were checked against NIST, IEC, cybersecurity authority guidance and legislation. The scenario, acceptance criteria and proposed working method are CCyber recommendations.
Technologies mentioned in the notes, including AI, digital twins and automated simulations, are treated as possible supporting capabilities. We do not assume they are universally deployed or mandatory in every OT environment.
Industrial company boards, plant managers, control engineers, maintenance teams, IT and security teams, and integrators. It also supports infrastructure service operators preparing a risk assessment, modernization project or compliance review.
Connecting plants with analytics services, cloud platforms and remote maintenance creates additional dependencies. This does not automatically make an architecture insecure, but requires decisions about which data and commands can cross between environments. This approach is developed in the international secure OT connectivity principles published in January 2026.
The risk is not merely a forecast. In an announcement dated 30 July 2026, the FBI and EPA described attacks on internet-facing PLCs in the US water and wastewater sector. Configuration changes caused loss of visibility or control functions. This is a documented US example, not a measure of incident frequency in Poland.
Missing risk documentation does not itself cause a breach. However, an inadequate assessment can leave an access path, excessive permissions or recovery gap unidentified. The assessment should therefore lead to technical and operational decisions.
Security concerns protection against compromise and unauthorized activity. Safety concerns protecting people, the environment and equipment from hazardous process consequences. The disciplines need to work together, but are not interchangeable.
The international OT cybersecurity principles put safety first. NIST also emphasizes distinct safety, reliability and performance requirements in its OT Security guide.
Do not adopt a fixed rule that IT cares about confidentiality while OT cares only about availability. A running system reporting incorrect measurements can be dangerous. Engineering information also requires confidentiality.
Our proposed assessment asks: when may operation continue, when is a contingency mode needed and who authorizes a controlled shutdown? Answers must come from people who understand the process and its protections.
A Programmable Logic Controller, or PLC, performs programmed control functions using inputs and defined logic. It can support a machine, part of an installation or a more complex process. It is not limited to basic on/off operations. Functions are described by NIST.
Security question: who can change the program, configuration and controller behaviour, and how would an unauthorized change be detected?
A Distributed Control System, or DCS, distributes control functions across components associated with the process rather than placing all control in one central unit. See the NIST definition.
A DCS can integrate control, visualization and engineering tools. Its name alone does not guarantee redundancy or the absence of single points of failure. Those are properties of the actual implementation.
Security question: could compromise of a shared engineering workstation or management service affect several parts of the process?
Supervisory Control and Data Acquisition, or SCADA, collects and processes information while enabling supervision and higher-level control. It is also used for geographically distributed assets. It need not be one central application and is not limited to business reporting. See the NIST definition.
Security question: does the operator see a trustworthy process state, and can only authorized people issue commands?
A PLC is a control device, while DCS and SCADA describe broader systems. They can work together. Include operator interfaces, or HMIs, engineering workstations, historians and communication equipment in the assessment.
The following method is a CCyber recommendation. It connects the physical process with architecture, risk and safeguard verification.
Start with a service or process, such as water treatment or a selected production line. Identify assessment boundaries, the owner, dependencies and acceptable operating conditions.
Consider consequences for people, the environment, product quality and continuity of supply separately. Do not reduce every consequence to an hourly downtime cost. Record the effects that cannot yet be assessed.
Combine engineering documentation, configurations and operator knowledge with traffic observation. Include service modems, integrator devices, removable media and external service connections.
The guidance on maintaining an accurate OT architecture view recommends multiple information sources. It also warns that active scanning can overwhelm older devices. Select and validate the method before using it.
Output: a verified asset and dependency map with unknown areas identified. An absence of traffic during a short observation should not be the sole reason for removing a connection.
A zone groups assets with common security requirements. A conduit groups communications between zones for which shared security requirements are defined.
IEC 62443-3-2 covers defining the system under consideration, partitioning it into zones and conduits, assessing risk and establishing target security levels, or SL-T. Selecting a target does not demonstrate that it has been achieved.
In our proposed model: separate office systems, maintenance access and control areas according to process requirements. Record the purpose, direction, ownership and permitted communication for each connection. A diagram or VLAN name alone does not demonstrate effective separation.
Consider scenarios such as a compromised supplier account, an unauthorized configuration change, loss of trustworthy measurements and ransomware affecting a workstation needed to operate the process.
For each scenario, identify required access, weaknesses, existing safeguards and consequences. Do not assume that shutting down a plant requires encrypting the PLC itself. A scenario may involve unavailable supervisory systems or business dependencies instead.
Output: a reasoned priority rather than only a scanner score. Mark missing information as uncertainty, not low risk.
Choose actions that address the scenario: access restriction, segmentation, configuration protection, better monitoring or improved recovery. Assign an owner, deadline and verification method.
Where an update requires a maintenance window, include compatibility testing and rollback arrangements. If remediation cannot occur immediately, define interim protection and a reassessment date. “It cannot be patched” should not end the assessment.
Check that the safeguard operates and has not impaired process conditions. The risk owner should understand remaining limitations.
Reassess after significant changes, such as a new IIoT gateway, integrator access, PLC modernization or altered recovery arrangements. Periodic reviews complement these triggers rather than replacing them.
The secure OT connectivity principles recommend brokered access through a controlled gateway rather than direct external access to control assets. They also describe restricting functions and communication between zones.
Proposed evidence: an approved connection register, access-control configuration and an agreed technician-access test. Include denial of out-of-scope access and session termination.
The remote OT access guide in the OT, Industrial and Critical Infrastructure Security category explores these arrangements further.
Do not assume that a standard endpoint agent can be installed on every PLC or real-time system. Selection requires checking support, operational impact and maintenance conditions.
Proposed action: define the approved route for project files and updates, removable-media controls and verification of file origin and integrity.
Proposed evidence: platform compatibility, a test result and documented exceptions. An antivirus invoice does not demonstrate protection across the entire OT environment.
Agree which changes matter: a new connection, supplier access outside a maintenance window, project modification or communication loss. Identify who distinguishes scheduled maintenance from activity requiring a response.
Proposed evidence: a controlled alerting test with confirmation that the right person received it. A new IP address is not automatically an attack, but should be assessed against process and change information.
Recovery planning should cover more than office files. Include the appropriate controller projects, configurations, software versions and required engineering environment.
Proposed evidence: restoration in an agreed environment, with control engineers verifying configuration and required functions. Process restart should follow an approved commissioning or recovery procedure, not merely a “restore completed” message.
Illustrative CCyber scenario, not a real incident. A water treatment facility permits remote maintenance through an engineering workstation. The assessment investigates whether compromise of the maintenance account could allow unauthorized process changes.
Scenario: an unauthorized person uses maintenance access to perform an operation outside the approved task.
Potential consequence: loss of trustworthy control, a need to stop part of the process or a threat to water quality. The assessment must consider actual interlocks, alarms and independent measurements. We do not assume that every compromised account automatically results in contaminated water.
Requirement: access is restricted to agreed activities, changes need appropriate authorization and unwanted operations can be detected and addressed.
Verification: permission testing in a laboratory or another safely agreed scope, combined with an operator decision exercise. Do not deliberately alter the parameters of an operating treatment process.
Evidence: configuration version, test scope, result, action owner and remaining limitations. Testing one route does not constitute an assessment of the entire facility.
AI can support data analysis and anomaly detection, but integration also introduces risk. The joint principles for secure AI integration in OT address testing, oversight and safe failure arrangements.
Our recommendation: before automating connection blocking or device behaviour changes, test the consequences of false alarms and missing data. Response automation should not silently take over process safety decisions.
NIST described research combining a digital process model, machine learning and expert knowledge to detect attacks on a laboratory 3D printer. This demonstrates a research capability, not comprehensive protection for any industrial installation.
Our recommendation: check how accurately the model represents the device, which phenomena it reproduces and its limitations. Do not automatically extrapolate a simulation result to the production process.
Breach and Attack Simulation means simulating selected attacker activities to test protection. This article does not assume that BAS is mandatory for every OT assessment.
Our recommendation: begin in a laboratory with an agreed scope. Production testing requires process-owner authorization, impact assessment, stopping conditions and recovery arrangements. Do not run a standard IT testing profile against controllers without this preparation.
In ISO/IEC 27001:2022 Annex A, malware protection is referenced as A.8.7, while information transfer is A.5.14. Backups fall under A.8.13. Implementation guidance is developed in ISO/IEC 27002:2022, whose structure is visible in the public SIST preview.
A maintenance-file review can support assessment of these controls. It is not a certificate of PLC or plant security. The ISMS scope and Statement of Applicability matter.
IEC 62443-3-2 supports risk assessment during system design, while IEC 62443-3-3 specifies technical system security requirements and capability levels.
When commissioning work, identify the relevant part, system and criteria. A certified component does not automatically establish a secure integration. Zone diagrams should connect with requirements, configurations and verification.
Article 20 of NIS2 addresses management-body approval and oversight of cybersecurity risk-management measures. In Poland, Articles 8c-8d of KSC establish the manager’s accountability and duties. This is not an automatic penalty for every imperfect assessment or incident. The relevant obligation and grounds for liability must be established. See NIS2 and KSC.
Operating a PLC does not itself determine KSC applicability. For entities covered by the relevant transition period, important dates include self-registration by 3 October 2026 and implementation by 3 April 2027. Check organizational status and the official timetable.
DORA concerns the digital resilience of specified financial entities and includes requirements concerning ICT providers. Its scope is explained by ESMA.
It does not automatically apply to a water utility or manufacturing plant simply because their services are economically important. A DORA requirement in an OT engagement needs a specific role, service or obligation behind it, rather than being added to every critical-infrastructure audit.
We recommend linking process → risk scenario → requirement → safeguard → verification result → residual risk decision.
Each item should identify its scope, date, configuration version and owner. Retain failed tests and how findings were addressed. Do not present a new configuration as if it had been operating for months.
Distinguish readiness reviews, technical tests, audits against agreed criteria and certification. The label “OT audit” does not by itself establish what was examined or which conclusions can be drawn.
First: select one important process and bring together control engineering, maintenance, IT, security and the business owner. Agree the boundaries and safe working conditions.
Second: review the connection map, remote maintenance and configuration recovery. Address known serious threats promptly in coordination with operations rather than waiting for all documentation to be completed.
Third: approve priorities and deadlines. Report planned, implemented and verified safeguards separately. Do not measure improvement solely through the number of sensors installed.
Remote maintenance and segmentation are explored in the OT, Industrial and Critical Infrastructure Security category. Exercise planning can also draw on incident response and business continuity resources. These links lead to Polish-language material.
This article focuses on process risk assessment and evidence. Detailed network design and safeguard selection require assessment of the actual installation.
Through its cybersecurity project and implementation services, CCyber supports IT and OT risk assessment, segmentation, access control and audit preparation.
Start with a process whose loss would have the greatest impact on the organization. Prepare the installation description, available diagrams, supplier list and known limitations. The objective is an agreed protection plan and evidence, without testing that endangers people or production. Share technical information only after agreeing a secure channel.
That cannot be determined from internet connectivity alone. Review maintenance access, IT connections, supplier devices and file transfer as well. Claimed isolation must reflect the actual architecture.
No. It can provide some information, but does not independently establish process consequences, human safety implications or recovery arrangements. The scanning method also needs an OT impact assessment.
Do not copy an office-computer configuration onto every controller. Select mechanisms according to the platform and risk. Strong authentication may be enforced through a controlled administrative path, with device protection supported by communication and change restrictions.
Technical capability is not operational authorization. Before such automation, assess the consequences of disconnection, misclassification and missing inputs. The rules must account for safe process behaviour.
The scope should reflect the process and possible consequences. A small device count does not imply that control functions are unimportant. Start with a bounded review without presenting it as an assessment of the entire organization.
OT security in 2026 requires an understanding of the process, architecture and threats. PLC, DCS and SCADA perform different functions and should not receive one uniform set of safeguards without considering their use.
A useful risk assessment ends with a verifiable decision: what is protected, against which scenario, who owns the action and how the outcome will be checked without endangering the process. AI and new tools can support this work, but do not replace it.
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.