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.
WEF Global Cybersecurity Outlook 2026: 7 Priorities for Boards
What does the WEF Global Cybersecurity Outlook 2026 mean for board decisions? This guide examines seven areas: AI, geopolitics, fraud, cyber resilience, suppliers, capability gaps and emerging threats. It separates survey findings from CCyber recommendations and translates them into actions, ownership and measures. A board decision template and a shared-provider risk scenario help connect the report with practical planning. Global survey results are not treated as an assessment of an individual Polish company.
Prepared by: CCyber Editorial Team
The WEF Global Cybersecurity Outlook 2026 highlights that organizational resilience depends not only on internal safeguards, but also on decisions about AI, suppliers, skills and collaboration. It connects technology with economic and geopolitical considerations rather than reducing cybersecurity to another tool purchase.
For boards, we propose a practical application: select scenarios relevant to the business, verify response capabilities and decide what needs improvement. Survey findings should help frame better questions. They do not replace an organization’s risk assessment or evidence that its safeguards operate.
19 September 2026
This article draws on the Global Cybersecurity Outlook 2026, published on 12 January 2026 by the World Economic Forum in collaboration with Accenture. It follows the seven themes in the report’s main analysis. Proposed actions, the decision template and the business scenario are CCyber recommendations, not WEF research findings.
Boards, business owners, CISOs, IT managers and people responsible for risk, operations and procurement. It is particularly relevant to organizations that want to use research to establish priorities rather than simply add percentages to a presentation.
The survey ran from 25 August to 1 October 2025. Its qualified dataset comprised 804 participants from 92 countries, including 105 CEOs and 316 CISOs. Expert discussions and workshops supplemented the survey. Details appear in the WEF methodology.
“2026” in the title does not mean every response was collected in 2026. Some questions looked back over 12 months, while others concerned expectations. Comparisons between editions should not be assumed to track an identical group of companies. Global findings are not a representative assessment of Poland’s market.
Cyber-enabled fraud and phishing rank first among CEOs’ concerns in the report. Ransomware remains first for CISOs, followed by supply chain risk. This ranks concerns, not incident volumes. The comparison appears in the chapter on CEOs’ perspectives.
CCyber recommendation: when setting the budget, ask finance, operations and security to describe the consequences of the same scenarios. For a fraudulent payment, examine losses and approval arrangements. For ransomware, examine the ability to fulfil orders. Do not decide which function is right solely by comparing positions in a ranking.
WEF finding: 94% of respondents expected AI to be the most significant driver of cybersecurity change in the coming year. Processes for assessing AI tool security were reported by 64%, compared with 37% in the previous edition. See the WEF key findings.
CCyber recommendation: separate three questions: how you protect your own AI applications, how you use AI for security and how you prepare for its use by attackers. Select one operational use case and review its input data, permissions, responsibility for outputs and the ability to stop automation.
For an alert-analysis tool, do not assess speed alone. Test an incorrect recommendation and establish who can challenge it. For an agent performing actions, check which operations need approval and who can revoke its access.
Evidence of progress: a documented assessment of the specific use case and a test of its limits. “AI approved” does not describe the scope of a decision. Further examples are available in the AI Security and Emerging Threats category.
WEF finding: 64% of surveyed organizations account for geopolitically motivated attacks in their risk-mitigation strategies. The report also examines technology dependencies and digital sovereignty. Context is provided in the WEF overview of cyber risk in 2026.
CCyber recommendation: do not begin with a general declaration that geopolitical risk is high. Identify a service whose loss would materially disrupt operations. Examine dependencies on infrastructure location, provider support, connectivity and data portability.
When choosing a local or sovereign solution, require an explanation of the specific problem it should resolve. A provider change should not be treated as a completed risk action without migration testing and assessment of new dependencies.
Evidence of progress: a defined service-loss scenario, an agreed response and verified limitations of the fallback option.
WEF finding: 73% of respondents said that they or someone in their professional or personal network had been affected by cyber-enabled fraud during the previous 12 months. That is the question shown in Figure 21. It does not mean that 73% of surveyed companies suffered a breach.
CCyber recommendation: review supplier bank-detail changes, urgent transfers and account recovery with the finance team. Design verification through a previously agreed channel rather than a number or link supplied in a suspicious message.
Run an authorized exercise using test data. Include time pressure and deputy arrangements. Do not base approval of an important operation solely on recognizing a voice, image or writing style.
Evidence of progress: the payment-approval test result and a list of exceptions that still permit the procedure to be bypassed. Employee preparation is explored in the Training and Cyber Awareness category.
WEF finding: the resilience chapter connects cybersecurity with economic value. Among organizations with industrial environments, only 16% reported informing their boards about OT security issues. The data and context appear in Section 3.4.
CCyber recommendation: select a service important to revenue, customer commitments or process safety. Establish how long it can remain unavailable, what is needed to restart it and who authorizes contingency operation.
Connect recovery testing with acceptance by the business process owner. In an industrial environment, agree the scope with operations and those responsible for human safety. Do not conduct destructive testing on a live installation.
Evidence of progress: a record confirming the agreed service capability, not merely restoration of a server. See the resources on incident response and business continuity.
WEF finding: 65% of large companies by revenue identified third-party and supply chain vulnerabilities as their greatest resilience challenge, compared with 54% in the previous edition. WEF also highlights concentration risk. These findings are summarized in the report’s accompanying announcement.
CCyber recommendation: beyond assessing each provider individually, check whether several important services use the same subcontractor, cloud infrastructure or authentication mechanism. Two separate contracts should not be the sole evidence of independence.
Ask providers about practical incident cooperation: contacts, information sharing, data recovery and participation in exercises. Supplement the questionnaire with verification of a selected scenario.
Evidence of progress: a map of shared dependencies for a critical service and the result of an agreed provider exercise. Record information gaps explicitly rather than replacing them with an assumption of security.
WEF finding: in its comparison of smaller and larger organizations, 46% and 29% respectively reported cybersecurity skills shortages. The broader disparity in access to capabilities is described as cyber inequity. See the WEF analysis. This grouping does not correspond to Poland’s legal SME definition.
CCyber recommendation: list activities the organization cannot currently perform instead of assessing the gap only through vacancy counts. Examples include evaluating an incident, conducting recovery and verifying permissions.
For each gap, choose an approach: develop the internal team, obtain specialist support or use a managed service. Agree availability and outcomes. With a smaller partner, consider a joint exercise or phased requirements rather than sending only an extensive questionnaire.
Evidence of progress: a defined activity has an owner, a deputy and a verified delivery method. Hiring someone or signing a subscription does not by itself complete that assessment.
WEF outlook: Section 3.7 considers scenarios through 2030 involving autonomous systems and robotics, digital currencies, space and undersea infrastructure, climate and quantum technologies. These are forecasts, not confirmation that every described outcome has occurred. See the final part of the trends chapter.
CCyber recommendation: select areas genuinely connected with your business. A manufacturer of long-lived devices could begin with update capabilities and cryptographic dependencies. A logistics company could examine positioning, connectivity and automated decisions.
Do not justify an expensive purchase merely because a technology appears in the report. First identify the asset, its expected lifetime, potential consequences and the condition that should trigger further action.
Evidence of progress: an emerging-risk register with owners and reassessment dates, rather than a general slide about future threats.
We recommend discussing a few scenarios connected with specific services rather than presenting every statistic in sequence. Prepare a short decision record for each one.
Service and consequence: what would stop working or could be lost?
Dependency: which system, provider, access path or capability gap matters?
Current knowledge: what was verified, on which date and what remains unknown?
Decision: what action is proposed, and which alternatives are being rejected?
Ownership and resources: who delivers the result, who accepts it and what support is required?
Acceptance criterion: how will the organization establish that the action achieved its intended outcome?
This template does not prescribe a universal cybersecurity percentage of the IT budget. First describe the need and alternatives. Then estimate implementation, operation, internal staff time and testing.
Illustrative CCyber scenario, not a description of a real client. A company purchases customer management and order-processing applications from two different suppliers. Its documentation treats them as independent.
A review establishes that both use the same infrastructure subcontractor. A service-loss exercise shows that one disruption could stop both order intake and fulfilment. The team has contacts for both suppliers but has not agreed the sequence for restoring operations.
The company does not automatically decide to change technology. It first establishes data-export options, an acceptable manual operating mode and communication arrangements. Only then does it use the exercise results to assess whether another technical option is necessary.
The value of the review lies in identifying a shared dependency and testing the response, not merely expanding the supplier register.
Select an important service and its associated AI use case, payment process or provider. Collect existing assessments and evidence. Record gaps, but do not assume that every missing document means the underlying safeguard is absent.
Conduct an agreed response exercise, recovery test or operational approval check. Include the process owner and relevant provider. Adapt the test to the environment so that normal operations are not put at risk.
Recheck corrections, present remaining limitations and approve further priorities. Extend the review to other services according to risk. This is a proposed work plan, not a reason to postpone action on an active incident.
We suggest tracking the proportion of important services with successful recovery tests, AI use cases with current assessments, critical providers with tested escalation and significant activities with an assigned owner and deputy.
Every measure needs a scope, denominator and date. Do not extrapolate one application’s result to the entire environment. Measure recovery against an agreed start and finish, not only the tool’s processing time.
Separate declaration, implementation and verification. This is a practical rule for our proposed reporting model, not a new WEF metric.
Strategy, accountability and supplier management are explored in the Cyber Risk, Governance and vCISO category. The AI and incident-response guides help move from priority selection to detailed implementation. The linked CCyber blog resources are in Polish.
This article reviews the report and proposes how to use it in planning. It does not replace an assessment of the organization’s applicable regulatory obligations.
Through its vCISO service, CCyber supports strategy, risk and supplier management, security measures and board reporting.
Translate the report into priorities for your own organization. Important services, the current security plan and unanswered questions can provide a starting point for defining the engagement. The objective should be decisions and verifiable actions, not another trends presentation.
It should not be interpreted that way. It covers a global respondent group rather than a representative sample of Polish enterprises. It can help identify questions for your own review.
WEF identifies differences between CEO and CISO priorities. It does not determine which threat must matter most to an individual organization. That requires assessment of its processes and potential consequences.
A trend alone is insufficient. First define the task, intended outcome and consequences of incorrect operation. Then test the solution within a controlled scope and plan how it will be operated.
We do not recommend that approach. Select related scenarios affecting important services. One exercise may reveal gaps in ownership, access and supplier cooperation without requiring three separate initiatives.
No. They are forward-looking perspectives. Distinguish survey data from opinions and scenarios, and update decisions as new information becomes available.
The WEF conclusion emphasizes leadership, skills and collaboration in collective resilience. Its perspective extends beyond an individual organization’s protection in isolation from its partners.
Our recommendation is to finish reading with a decision to test a specific scenario. Select the service, identify dependencies, assign responsibilities and verify the outcome. That makes the global research useful to the business rather than leaving it as a collection of statistics.
ISO 27001 Annex A: 93 Controls and a Practical Statement of Applicability
ISO/IEC 27001:2022 Annex A contains 93 controls, but it is not an identical shopping list for every organization. This guide explains the four control themes, correct references for selected controls and the difference between a requirement, implementation and operating evidence. Learn how to select controls, prepare a Statement of Applicability and justify exclusions. A supplier-access example connects risk with a specific activity, ownership and verification.
Prepared by: CCyber Editorial Team
ISO/IEC 27001:2022 Annex A contains 93 controls organized into four themes: organizational, people, physical and technological. It provides a reference set for checking that necessary protection has not been overlooked. It does not replace risk assessment or the complete information security management system.
An organization should determine which controls are necessary within its ISMS scope, justify their selection and identify their implementation status. These decisions are recorded in the Statement of Applicability, or SoA. They must then be translated into operating processes and safeguards.
The important question is not “How many boxes have we checked?”. It is “Do the selected controls address our needs, and can we demonstrate that they operate?”.
19 September 2026
This article refers to ISO/IEC 27001:2022 with Amendment 1:2024 and ISO/IEC 27002:2022. The starting point is Copla’s Annex A guide. We retain its four-theme structure while checking references and applicability principles against the standards and IAF material.
The examples, acceptance criteria and sample record below are CCyber recommendations. They are not the complete text of the 93 controls or an official reproduction of the standard.
ISMS implementation owners, IT managers, CISOs, process owners and teams preparing for certification. It is particularly relevant to organizations that have a control spreadsheet but cannot yet connect it with risks, accountability and the actual scope of protection.
ISO/IEC 27001 establishes ISMS requirements. Clauses 4-10 concern management of the system, not merely technical safeguards. They cannot be excluded when claiming conformity. This is explained in the official IEC description of ISO/IEC 27001.
Annex A is part of ISO/IEC 27001. It supports comparison of the controls an organization needs against an organized reference set. It does not restrict the organization to that set alone.
ISO/IEC 27002 provides implementation guidance. It is not a separate ISMS certification standard. The relationship is explained by ISO.
Keep references precise. A.8.2 in Annex A concerns privileged permissions. Clause 8.2 in the main body of ISO/IEC 27001 concerns a different subject. Omitting the prefix and document reference can direct a team to the wrong requirement.
The structure and numbering can be checked in the public preview of ISO/IEC 27002:2022. The examples below illustrate a proposed working approach, not the complete wording of individual controls.
The references run from A.5.1 to A.5.37. This theme covers areas including responsibilities, information-handling rules, suppliers, incidents and continuity.
Practical example: before purchasing a cloud service, agree which data it may process, who manages access and how the relationship will end. Approving an invoice does not document those decisions.
Question for the process owner: who decides, and what demonstrates that the agreed arrangements are followed?
The references run from A.6.1 to A.6.8. This theme covers the organization’s relationship with personnel, awareness, remote work and event reporting.
Practical example: following training, an employee should know how to report sending a document to the wrong person. An attendance record confirms participation, not necessarily the ability to perform that action.
Question for HR and security: are the rules also understood by new joiners and external personnel?
The references run from A.7.1 to A.7.14. They address premises, equipment, media and the physical conditions surrounding information protection.
Practical example: remote working does not remove questions about a stolen laptop, a document left in a shared workspace or a storage device sent for disposal.
Question for the organization: are we assessing the actual places where information is used and stored, or only the registered office?
The references run from A.8.1 to A.8.34. This theme includes access, devices, vulnerabilities, configuration, backups, event records, networks and software development.
Practical example: a security-tool licence does not establish whether every important system is covered or who handles detected issues.
Question for IT: which technical and operational result would demonstrate that the safeguard works across its declared scope?
The Copla article requires reference corrections. Backup belongs under A.8.13, not A.8.8. A.6.8 concerns reporting information security events rather than privileged permissions. In working documentation, verify the reference, subject and standard edition together.
A.8.2 concerns privileged permissions, while A.8.5 concerns secure authentication.
Our recommendation: separately check whether a person can establish their identity and whether they receive appropriate permissions. Successful authentication does not justify administration of the entire environment.
A.8.8 addresses technical vulnerabilities, while A.8.9 addresses configuration management.
Our recommendation: compare patching results with configuration reviews. An installed patch does not demonstrate that access is appropriately restricted or unnecessary functionality disabled.
A.8.15 addresses logging, while A.8.16 addresses monitoring activities.
Our recommendation: verify not only that records exist, but also who receives significant signals and how they are handled. A folder containing logs does not identify who will notice an unauthorized change.
Further account-management examples are available in the Identity, Access and Cloud Security category.
The purpose explains the outcome a control is intended to support. However, a descriptive “Control Objective” column in an online guide should not be treated as the standard’s official wording.
IAF MD 26 explains the structural change: ISO/IEC 27002:2022 provides a purpose for individual controls rather than retaining the earlier arrangement of objectives for control groups.
We recommend separating the standard reference, the organization’s implementation and the acceptance criterion. This prevents an internal procedure from being presented as a verbatim ISO requirement.
Not automatically, but no entry should be overlooked without consideration. The organization first determines necessary controls and then compares them with Annex A to identify potential omissions. IAF confirms this comparison role.
The starting point should be the ISMS scope, risks and applicable requirements. Organization-specific controls or controls from other sources may also be needed. Annex A is not the maximum permissible extent of protection.
CCyber recommendation: do not use one field to indicate both whether a control is necessary and whether it has been implemented. “Not implemented yet” does not mean “not applicable”. Similarly, implementation priority is not an exclusion decision.
Clause 6.1.3(d) requires a document identifying necessary controls, the reasons for including them, their implementation status and justifications for Annex A exclusions. The provision is available in the public preview of the standard.
The SoA does not replace the risk treatment plan. The standard also requires risk owners to approve that plan and accept residual risks. Residual risk is the risk remaining after the selected treatment is considered.
Beyond the required content, we suggest linking each record with its owner, systems, procedures, evidence and open actions. These can be maintained in separate connected registers. The entire documentation set does not need to be placed in one spreadsheet cell.
Important: detailed implementation notes, test dates and ticket references are practical additions to the proposed model. We do not present them as mandatory column names prescribed by ISO.
A justification should reflect the actual scope and protection needs. “We have no budget” or “nobody has asked before” is insufficient. The following examples show how to examine these decisions.
Establish what remains with the organization: user devices, permissions, service configuration and provider oversight. Instead of excluding an entire theme, describe the allocation of activities and relevant assurance.
Determine whether the company commissions development, maintains its own integrations or makes significant modifications. The absence of an employed developer does not by itself resolve the applicability of development-related safeguards.
Distinguish non-applicability from external delivery. In the proposed register, identify the service, retained responsibilities and evidence covering the provider’s activities. Do not mark implementation complete solely on the basis of marketing material.
Illustrative CCyber scenario, not a description of a particular client. A company uses an external application-support provider. Its assessment identifies a need to improve support permissions. The following record illustrates how the SoA can connect with delivery.
Reference: A.8.2, privileged permissions.
Reason for inclusion: support personnel can change application configuration and affect service availability. Their access therefore needs restriction and oversight.
Scope: the specified production application and external administrator accounts. Other systems require separate assessment.
Status: necessary control, partially implemented. Authentication operates, but the permission review and removal arrangements remain incomplete.
Proposed action: establish required roles, the access approver, activation conditions and termination arrangements. Perform a controlled check using a test account.
Acceptance criterion: the account can perform the agreed tasks, cannot perform activities outside its approved scope and cannot regain access through the tested route after permissions are removed.
Evidence: the owner’s decision, role configuration, review record and test result. Materials are retained in an approved repository without passwords or secrets.
This record may link to authentication and logging activities, but it does not automatically establish fulfilment of every related control.
We recommend distinguishing three perspectives: rules, configuration and performed activities. A policy describes expected behaviour. A configuration shows settings. A process record or test report helps demonstrate the result within a defined scope.
Example: a rule requires access reviews, and a system can generate the relevant report. However, a completed review with decisions and implemented changes demonstrates that the activity actually took place.
NIST SP 800-53A can support assessment design. It is a control-assessment methodology, not a substitute for ISO/IEC 27001 or a requirement to adopt the entire NIST control catalogue.
Evidence should make its scope and date clear. Do not present a test of one application as a result for every system. Share sensitive configuration material only with authorized recipients.
Saying “we implemented 80 of 93 controls” does not establish whether selection was appropriate, which gaps matter or whether the management system operates.
We suggest separately reporting applicability decisions needing clarification, necessary controls not yet implemented, implementations awaiting verification and overdue remediation.
Define each measure. “The proportion of verified controls within a selected scope” differs from “the company’s overall ISO 27001 compliance level”.
First establish the baseline: confirm the standard edition, control references and ISMS scope. Do not update an old spreadsheet merely by changing the date in its header.
Then examine the reasons: select several risks and check whether they lead to specific controls. Reverse the exercise and ask why each selected control is necessary.
Finally verify operation: choose a representative service and compare declarations with its actual state. Record gaps, owners and closure criteria. Do not postpone urgent protection until the entire register is finished.
The EU Cyber Regulations and Compliance category explores requirements and evidence preparation. Product-security examples are available in the Secure Software and Digital Product Development category. These links lead to Polish-language resources.
This article focuses on selecting and implementing Annex A controls. It is not a complete certification schedule or an assessment against a specific law.
The CCyber ISO/IEC 27001 readiness assessment covers gaps, priorities, required policies and procedures, and a staged implementation plan.
Check whether your Statement of Applicability reflects the actual environment. The current SoA, ISMS scope and open-action list can support scoping the review. A readiness assessment helps prepare the organization, but it is not the issuing of a certificate by a certification body.
No. One procedure may support several controls, while one control may require several processes and configurations. Organize documentation around how the business operates while retaining traceability to the appropriate references.
Do not start with the tool. A controlled document or register can hold the SoA. Consistency, versioning, permissions and connections with implementation matter. Software does not make applicability decisions for the organization.
Not where the control is necessary. Non-implementation belongs in its status and action plan. An exclusion justification answers a different question from a task’s delivery deadline.
Do not treat a frequency stated in an online guide as an automatic requirement of the standard. Establish needs, roles and how competence and awareness will be demonstrated. Separate requirements applicable to the organization may specify a frequency.
In Annex A of ISO/IEC 27001:2022, with implementation guidance in ISO/IEC 27002:2022. Use the appropriate edition available through ISO, IEC or an authorized distributor. A descriptive blog overview does not replace the standard’s wording.
Annex A helps organize protection, but implementation value comes from decisions and operation. Correct references are the starting point. Justification, appropriate scope, ownership and verification must follow.
A useful Statement of Applicability connects what the organization needs with what it actually does. It does not hide gaps behind “not applicable” or treat a purchased tool as evidence of effectiveness.
Threat Modeling for Embedded Systems: 5 Practical Steps
How do you model threats to a device that combines electronics, firmware and network communication? This guide covers five analysis stages, practical use of STRIDE and the conversion of threats into requirements and tests. A temperature-logger example explores service access, key protection and software updates. It also explains why signed firmware does not solve every update risk, why CVSS does not replace risk assessment and why the threat model must evolve with the product.
Prepared by: CCyber Editorial Team
Threat modeling for embedded systems examines a device and its environment from the perspective of potential misuse. The team identifies what needs protection, the paths through which the product could be affected, the consequences that matter and the safeguards that must be designed or verified.
Reviewing only the application communicating with a device is insufficient. An embedded-system assessment also needs to consider firmware, memory, service interfaces, updates and physical access. Its outputs should include threat scenarios, risk decisions, requirements and tests linked to a specific product version.
19 September 2026
The starting point is Sii’s article on threat modeling for embedded systems. The five-stage structure follows that material. Technical elaborations use the cited sources, while the device example, workshop questions and threat record are CCyber proposals, not descriptions of an actual client or discovered vulnerability.
Device manufacturers, firmware and electronics teams, architects, testers and product security owners. It also supports integrators and industrial system owners who want to understand which security assumptions to discuss with suppliers.
This article focuses on the device and its lifecycle. The broader guide “Threat modeling: praktyczny przewodnik dla zespołów produktowych” is available in the Secure Software and Digital Product Development category.
Threat modeling is a structured examination of how a system’s security could be compromised. It is not simply a list of known issues from vulnerability databases. It can assess a design that has not yet been implemented.
OWASP describes a repeatable process involving system understanding, threat identification, response selection and validation. Data flows and trust boundaries matter: these are points where permissions, control or assumptions about an information source change.
Practical distinction: unauthorized modification of device configuration is a possible threat scenario. Missing authorization checks could be a weakness enabling it. Establishing whether that weakness actually exists requires examination of the design or implementation.
Here, an embedded system means the electronics and software performing a defined device function. We do not automatically equate every embedded system with an IoT device or critical infrastructure component.
A device assessment should distinguish network, local and physical interfaces. The OWASP IoT Security Testing Guide separately addresses memory, firmware, update mechanisms and different interface types. Reviewing a web dashboard alone does not cover that entire scope.
Design question: does a safeguard still operate when the device is serviced, reset or disconnected from its cloud service? The answer may require changes to hardware, production procedures or support arrangements rather than only an application patch.
We recommend recording the hardware and firmware versions, device purpose, intended use and the specific function under review. Prepare descriptions of interfaces, stored data, updates and service modes. Also record the actual memory, power and response-time constraints.
Include people who understand electronics, software, testing and product operation. The product owner should participate in prioritization. Where a device affects the safety of people or processes, involve the person responsible for that discipline.
Cross-functional work and examination of design assumptions are supported by Microsoft’s Secure by Design practices. A security specialist can facilitate the assessment but cannot replace the designers’ knowledge of the device.
Our example is a fictional temperature logger that stores readings locally, sends them to a cloud service and supports firmware updates. It also has a local service interface. We assume that it neither controls machinery nor performs a functional safety protection role.
Identify the functions, information and product properties requiring protection. In this example, they include trustworthy measurements, alarm-threshold configuration, device identity and the ability to resume operation securely.
Include the surrounding environment: the operator, technician, cloud service and the infrastructure preparing and distributing updates. Not every component needs detailed analysis in the same session, but its dependencies should remain visible.
Stage output: agreed scope, protected assets, product versions and explicit exclusions. An assessment limited to network communication must not later be presented as a complete hardware review.
For the logger, describe measurement, configuration and update flows separately. Identify processes, persistent storage, the boot component that starts firmware and the service interface.
Example data flow: the sensor supplies a reading to the device software, which stores the result and sends it to the cloud service.
Example update flow: a package travels from the distribution system to the device, undergoes verification and only then becomes eligible for execution.
At each transition, ask who is trusted and what supports that trust. Physically placing a connector inside an enclosure is not itself an authorization mechanism. The model should show local access as well as internet connectivity.
Stage output: a flow model with trust boundaries and a list of points requiring verification.
Distinguish the capabilities of an unauthenticated remote user, a technician with limited permissions and someone with physical access. Do not assume that every attacker starts with complete control.
The example can consider device impersonation, unauthorized alarm-threshold changes and installation of older firmware. Record the conditions, required access and possible outcome for each scenario.
Example statement: someone able to initiate an update attempts to install an earlier signed version that should no longer be permitted. This is a hypothesis to test, not a claim that a particular product is vulnerable.
Stage output: scenarios connected to the system model rather than a generic list of terms such as “ransomware” or “network attack”.
Consider required access, execution difficulty, detectability and consequences for one device and the wider product fleet. Distinguish confirmed information from assumptions.
The Sii article mentions CVSS. FIRST provides an important clarification: a CVSS Base score measures vulnerability severity and should not be used alone to assess risk. Deployment and threat context require additional consideration. See the CVSS v4.0 User Guide.
In our example, not controlling machinery does not eliminate business consequences. Incorrect readings could prevent a reliable assessment of storage conditions. That consequence needs evaluation in the product’s actual application.
Stage output: justified priorities and identified information gaps. Avoid giving a seemingly precise score to a scenario whose conditions are not understood.
For selected threats, determine the response: redesign, restrict functionality, add protection or document a residual risk decision by the authorized owner. Assign an implementation owner and acceptance criterion to each change.
For the logger, this could involve restricting the service interface, protecting credentials or enforcing firmware-version rules. Selection should follow the scenario and platform capabilities rather than a list of fashionable technologies.
For firmware, consider protection against unauthorized changes, detection and secure recovery. These three directions are described in NIST SP 800-193.
Stage output: requirements and tests linked to threats. Merely recording “cryptography implemented” does not establish what has been protected.
Sii lists STRIDE, DREAD, PASTA, TRIKE, VAST and OCTAVE. This example uses STRIDE to organize scenarios. It is not a mandatory choice for every project.
The categories come from Microsoft’s documentation. The logger-specific questions below are CCyber examples.
Can the cloud service distinguish the intended logger from another device presenting the same identifier? How are the technician’s identity and the update source verified?
Can stored readings, alarm thresholds or firmware packages be changed without detection? Where does an integrity check actually influence the decision to accept information?
After a configuration change, can the team establish who performed it and what happened? What happens to the record during offline operation, a reset or storage exhaustion? The presence of a log alone does not establish its reliability.
Could diagnostics or memory access expose credentials? Could a secret obtained from one unit be used against other devices?
Could communication handling exhaust resources needed for measurement? What behaviour is expected during overload or loss of the cloud connection?
Can a read-only user change configuration or install firmware? Does service mode bypass restrictions enforced during normal operation?
STRIDE does not guarantee completeness. Microsoft emphasizes challenging design assumptions beyond the categories themselves. Asking what happens when a safeguard fails remains part of the assessment.
Establish where credentials originate, who provisions them during manufacturing and how they are changed or revoked. OWASP describes risks associated with secrets embedded in firmware, including the possibility of affecting multiple devices and making post-exposure changes difficult. See the OWASP firmware section.
Our proposed review also asks what happens when a device is replaced or changes ownership. Do not assume that resetting it always removes every item of information and authorization.
Signing a package, verifying its signature and enforcing permitted versions address different problems. A correctly signed older version can still be unacceptable. OWASP separately addresses signature validation, update authorization and downgrade protection in its update mechanism test catalogue.
The proposed design also needs an agreed recovery path after an interrupted update. Protection against returning to an unsafe version should not be designed without considering an available, trusted repair mechanism.
Review production, service and recovery modes separately. For each, establish the available functions, permissions and ability to detect an unwanted change.
The NIST device cybersecurity capabilities catalogue distinguishes areas including identification, configuration, data protection, interface control and updates. It supports selection of requirements for IoT devices rather than prescribing identical safeguards for every product.
Illustrative CCyber scenario. Assume the team is testing a logger and an earlier test version contains a known flaw that must not be reintroduced. This does not describe a real vulnerability in a particular manufacturer’s product.
Identifier and scope: TM-UPDATE-01, with the specified hardware revision, boot-component version and update mechanism.
Protected asset: the integrity of running software and the trustworthiness of measurements.
Scenario conditions: a person can access the update function and possesses an earlier signed package. Compromise of the signing key is not assumed.
Unwanted outcome: execution of a version below the approved minimum security level.
Proposed requirement: the normal update mechanism rejects such a package even when its signature is valid. Emergency recovery rules are defined separately and must not create an uncontrolled bypass.
Test: on a laboratory unit, verify rejection of the withdrawn version and successful acceptance of an approved version. Record which version actually starts after reboot.
Evidence and ownership: a report identifying the hardware and software build, test result, remediation owner and person assessing residual risk.
This is a template to adapt. Tests that disrupt normal operation belong on an agreed test bench, not on a device supporting production or a critical process.
Link the model to architecture, hardware and software versions. When a change occurs, check whether it introduces an interface, authentication method, service mode or supplier dependency. An incident or significant vulnerability may also require revision. OWASP describes maintaining the assessment alongside the system.
We recommend distinguishing identified, safeguard planned, implemented and verified. Separately flag scenarios awaiting information and risks formally retained by an authorized owner.
Before release, check that significant scenarios have a decision and the required tests were performed against the appropriate configuration. Do not treat the number of closed records as proof of complete security.
OWASP Threat Dragon can support diagrams and threat records. It helps document the model, but it does not verify actual interface behaviour or hardware resilience on the team’s behalf.
Determine the scope of applicable standards separately from selecting a technique such as STRIDE. The distinctions below use official scope descriptions rather than a review of every normative requirement.
IEC 62443-4-1 describes secure product development for industrial automation and control, including hardware, software and firmware. This part addresses product developers and maintainers. Its requirements should not automatically be assigned wholesale to device users. The scope is published by IEC.
ISO/SAE 21434 concerns cybersecurity engineering for electrical and electronic systems in road vehicles. It is not a universal standard for every embedded device. See the ISO description.
CLC/TS 50701 concerns cybersecurity in railway applications and their lifecycle. The description available from BSI also makes clear that it does not replace functional safety requirements.
A threat diagram alone does not establish conformity with a standard. The relevant scope, activities and evidence still need to be determined.
Connect the product model with an assessment of its operating environment. Segmentation, remote servicing and plant dependencies are explored in the OT, Industrial and Critical Infrastructure Security category. The linked CCyber blog resources are in Polish.
Customer network safeguards should not automatically be treated as a replacement for device protection. Deployment assumptions should be explicit and verifiable.
Through its cybersecurity project and implementation services, CCyber supports risk assessment, application security, secure development processes and OT environments.
Start with one significant device function. To define the support scope, prepare the product description, interfaces and changes planned for the next release. This helps establish the required designer involvement, assessment scope and any laboratory testing.
No internet connection does not eliminate local access, updates from removable media or service interfaces. The assessment scope may differ, but should reflect the actual ways the device can be affected.
No. It supports requirements and test planning, but does not demonstrate that implementation matches the design. Testing can reveal defects or assumptions that require model updates.
No. STRIDE organizes threat types. Scenario conditions, consequences and safeguard adequacy still need assessment. The number of identified categories is not a risk measure.
A signature helps verify package origin and integrity when correctly validated against a trusted key. It does not prove the code has no defects or that every older version should remain acceptable.
There is no universal duration. It depends on scope, documentation and complexity. Begin with a bounded function and turn missing information into follow-up actions. One meeting does not necessarily complete the assessment of the entire product.
Embedded-system threat modeling should connect electronics, firmware, communication and device operation. The five stages move from scope and flows to scenarios, priorities and safeguards.
The most important output is a verifiable design decision. The team should know what the product is protected against, which assumptions support that conclusion and how safeguards will be checked. That makes the model useful for the next device release as well.
NIS2, DORA and GDPR: One Security Programme, Separate Legal Duties
NIS2, DORA and GDPR require structured security management, but they do not cover the same organizations, information and obligations. This guide explains how to establish applicability, distinguish statutory duties from customer requirements and reuse safeguards without creating three parallel projects. It also identifies what must remain distinct: risk assessments, statutory registers, deadlines and incident notifications. A sample requirement record shows how to connect obligations with responsibilities, implementation and evidence.
Prepared by: CCyber Editorial Team
NIS2, DORA and GDPR can be supported through a coordinated security programme, but not through one universal declaration of compliance. First establish which provisions apply to the organization and in which capacity. Work on access, recovery, suppliers, training and incident response can then be coordinated.
Legal bases, the scope of individual obligations, statutory registers and notification arrangements remain distinct. A recovery test report may support several assessments, but it does not replace an assessment of lawful processing or the register of information required under DORA.
The practical objective is to perform a properly designed activity once and use its result wherever it genuinely meets a requirement. It is not to copy the same document into three folders.
19 September 2026
This article develops the topic of EU regulation and cybersecurity requirements. It focuses on coordination rather than providing an exhaustive account of GDPR, DORA or Poland’s KSC obligations. The working model and requirement record are CCyber recommendations, not official forms.
Boards, IT managers, CISOs, compliance professionals, data protection teams and procurement managers. It is particularly relevant where different teams commission similar assessments, send separate supplier questionnaires and prepare reports about the same safeguards.
It also supports IT and SaaS providers receiving customer requirements labelled “NIS2”, “DORA” or “GDPR” who need to understand their actual significance.
NIS2 establishes cybersecurity risk-management requirements across specified sectors. In Poland, the practical legal basis is the National Cybersecurity System Act, commonly referred to as KSC.
Applicability is not determined simply by whether a company uses the internet or processes customer data. Sector, activity, size and exceptions matter. The scope is explained by the European Commission and the Polish Ministry of Digital Affairs.
Question for the organization: which services do we provide, and what is the legal basis for determining our obligations?
DORA applies to financial entities identified in the regulation, subject to exclusions and proportionality. It covers areas including ICT risk management, incidents, resilience testing and technology supplier risk. ICT means information and communication technology.
Digital resilience is not limited to defence against attackers. Outages, failed changes and supplier unavailability can also matter. DORA’s objectives and areas are explained by the European Securities and Markets Authority, ESMA.
Question for the organization: are we an in-scope financial entity, or a provider receiving requirements from such a customer?
GDPR is not solely a cybersecurity regulation. It also governs processing principles and individuals’ rights. For each relevant processing activity, the company should establish whether it acts as a controller, processor or in another applicable capacity.
A controller determines the purposes and means of processing. A processor acts on the controller’s behalf. This is a different role from an IT system administrator. The distinction is explained by the European Data Protection Board.
Question for the organization: whose data do we process, for what purpose and who decides how it is used?
For a defined scope, but not as a universal exemption from every KSC provision. Article 4 of NIS2 addresses sector-specific EU legislation. Article 1(2) of DORA identifies it as such legislation for the relevant financial entities. The legal references are NIS2 and the DORA regulation.
In Poland, Article 8i of KSC must also be considered. It establishes special arrangements for banking and financial market infrastructure, excluding certain provisions while retaining specified obligations.
Organizations should therefore neither implement two identical programmes without checking the relationship nor mark KSC as inapplicable solely because they implement DORA. The assessment should identify which obligations are displaced and which remain.
DORA requires specified provisions in ICT service contracts. They include matters such as service descriptions, processing locations, incident assistance and data recovery. Services supporting critical or important functions are subject to additional requirements under Article 30.
A provider may therefore receive bank requirements concerning availability, testing, subcontracting or exit arrangements. This does not automatically make it a financial entity. A separate mechanism applies to formally designated critical ICT third-party providers, as explained by the European Banking Authority.
We recommend labelling requirements in three categories: the company’s statutory duty, a customer contractual obligation or a voluntarily adopted practice. All may matter, but each requires a different justification and approach to change management.
NIS2, DORA and Article 32 of GDPR share areas such as risk management, access security, continuity and safeguard assessment. GDPR requires protection to be considered against risks to individuals. This perspective is emphasized in the EDPB guide to securing personal data.
The following is a proposed operating model. Shared delivery does not mean that each component has identical requirements under all three regimes.
Agree common identifiers for services, applications, owners and suppliers. Teams can then work from the same information instead of repeatedly establishing who operates an application.
Do not replace one register with another. Records of processing activities, asset inventories and the DORA register of information have different purposes and content. EBA explains that the DORA register covers contractual arrangements for ICT services.
Outcome: source information is shared, while each required record retains its appropriate structure.
An account compromise can simultaneously disrupt a service, expose personal data and breach a customer commitment. The event description can be shared, but its consequences should not be reduced to a single lost-revenue figure.
We recommend separately identifying effects on operations, service continuity and individuals’ rights. An absence of significant financial loss to the company does not establish low risk to the person whose information was exposed.
Outcome: one investigation informs several assessments without concealing differences between them.
Access control, patching, backups and monitoring can support multiple requirements. For each safeguard, record the systems covered, owner, operating procedure and verification method.
A report confirming MFA for office users should not be presented as evidence that every administrator account is protected. Similarly, recovering one application does not automatically demonstrate recovery of the complete service.
Outcome: evidence is reused only where its scope matches the requirement being assessed.
Teams can conduct a coordinated supplier security review. Separate the technical assessment from required contractual clauses, data-processing arrangements and requirements specific to a financial-sector customer.
A signed data-processing agreement does not demonstrate recovery capability. Conversely, a security test report does not determine subcontracting permissions or what happens to data when the service ends.
Outcome: the supplier receives coherent questions, while the organization preserves the separate decisions required for each area.
Where several assessments identify the same gap, create one remediation action and connect it to the relevant requirements. Identify the delivery owner, deadline, acceptance criteria and person verifying the result.
Foundational training can be shared, with role-specific modules added afterwards. Someone reporting a suspicious message needs different preparation from someone determining whether a personal data breach is reportable.
Outcome: less duplicated work without closing several obligations through an action that does not adequately address them.
A well-protected database can still be used unlawfully, for example outside the appropriate purpose or without a valid legal basis. A common cybersecurity programme does not replace individuals’ rights or the remaining data protection obligations.
The scope of those rights is explained in the EDPB guide to respecting individuals’ rights. Not every issue requires purchasing a security tool. A business-process change may be needed instead.
Do not retain every log and backup indefinitely simply because several regulations require records. Article 5 of GDPR establishes data minimization and storage limitation.
Determine retention for the particular information, purpose and applicable obligation. A requirement to retain an audit report does not automatically mean retaining forever every item of data examined during that audit.
A register entry, supplier report and management-system certificate answer different questions. None should automatically be treated as proof of complete compliance with all three regimes.
Preserve conditions, exceptions and sector-specific rules in the requirements register. Listing article numbers next to a safeguard does not itself establish that those articles have been satisfied.
We recommend a shared incident record and timeline, with distinct decisions about notification obligations. This does not mean automatically reporting every incident to every authority.
A controller notifies the competent authority without undue delay and, where feasible, within 72 hours of becoming aware of a breach, unless it is unlikely to result in a risk to individuals’ rights and freedoms. High risk also requires assessment of communication to affected individuals.
A processor informs the controller without undue delay. It should not assume it always has its own 72-hour window. Breaches not requiring notification to the authority must also be documented. The rules are explained in the EDPB data-breach guide.
Check the effect on services, entity status, applicable regime and transitional arrangements. The amended KSC reporting model provides for staged information rather than one universal report for every organization.
Incident significance should not simply be copied from the GDPR assessment of risk to individuals. The applicable provisions are in the Polish KSC Act.
A financial entity assesses a major ICT-related incident against the applicable DORA criteria. Its procedure should not import GDPR’s 72-hour period as the only reporting obligation.
For entities reporting to Poland’s financial supervisor, KNF identifies the DORA Incident Handling System and a fallback arrangement. The instructions are provided on the KNF DORA incident page.
Assign a trigger, deadline starting point, recipient and responsible person to each reporting route. A shared incident-management tool does not remove legal distinctions. Related exercise material is available in CCyber’s Incident Response and Business Continuity category.
Illustrative scenario, not a description of a specific client. A company provides system administration to a bank. Assume a separate assessment has established that it is an important entity under KSC. For some operations, it processes personal data on the customer’s behalf.
The company therefore has its own KSC duties, processor obligations and contractual commitments to the bank. The contract alone does not turn it into a financial entity subject to the full financial-entity requirements of DORA.
Following compromise of a support account, the team can conduct one technical investigation: preserve logs, establish access scope and contain the consequences. In parallel, the provider assesses its own KSC reporting, informs the data controller and gives the bank information needed for its DORA assessment.
The investigation is shared. Roles and reporting decisions remain distinct. The provider should neither wait for the bank’s entire assessment before fulfilling its own duty nor report everything on the customer’s behalf without authority.
The following template is an organizational recommendation. It connects obligations with delivery while preserving their source.
Entity and role: which company, service and legal capacity does the record concern?
Source: the specific legal provision, contractual clause or approved internal rule.
Required outcome: what must be performed, and across which scope?
Shared activity: which process or safeguard implements the requirement, and which other obligations does it support?
Responsibility: who decides, who performs the activity and who verifies the result?
Deadline and evidence: which event starts the deadline, where is confirmation recorded and when must it be refreshed?
Differences and limitations: what does the evidence exclude, which exceptions remain and which activities require separate delivery?
For example, one action removing unnecessary access can support several requirements. Closing it does not establish complete GDPR, KSC or bank-contract compliance for the entire application.
Prepare a concise applicability assessment for each relevant entity, service and role. Identify obligations already being performed, not only those planned for the future.
GDPR has applied since 25 May 2018 and DORA since 17 January 2025. Their applicable obligations should not be postponed until the KSC project is complete.
For organizations meeting the criteria when the KSC amendment entered into force, the relevant timeline provides for implementation by 3 April 2027. Entities required to self-register under the transition arrangements face a 3 October 2026 deadline. Check the Ministry’s timeline and self-registration guidance.
Compare open actions and check whether two teams are planning the same configuration, questionnaire or test. Agree one delivery activity incorporating the needs of all relevant recipients.
Do not combine activities merely because their names resemble one another. A data protection impact assessment is not automatically the same as a business impact analysis of downtime.
Select an important service and walk through access, supplier management, recovery and an incident. Verify that each team receives the information needed to fulfil its responsibilities.
Then extend the model to further services. A successful pilot does not establish compliance across the entire organization.
We recommend a management sponsor and a coordinator working across IT, security, procurement and compliance. Service owners should participate in prioritization and acceptance decisions.
A data protection officer, where appointed, advises and monitors within that function. The DPO should not automatically own every decision about processing. Articles 38-39 of GDPR require attention to independence and conflicts of interest.
Do not equate “one programme” with “one person responsible for everything”. The model should improve cooperation without removing necessary separation of roles.
Detailed guidance is available in the EU Cyber Regulations and Compliance category. Accountability and management reporting are explored in the Cyber Risk, Governance and vCISO category. These links lead to Polish-language resources.
This article supports the design of cooperation between disciplines. It does not replace a detailed assessment of a particular obligation.
Through its EU regulatory compliance services, CCyber supports gap assessment, policy and procedure preparation, responsibility mapping and planning of safeguards and evidence.
Identify which activities can be combined and which need separate delivery. Your current requirements register, service inventory and open actions provide a starting point. The objective is one agreed action plan that preserves the relevant legal distinctions.
No. Applicability must be established separately. Processing personal data does not automatically bring a company under DORA or KSC. Similarly, serving a bank does not automatically confer financial-entity status.
A shared overarching policy can be used where its scope is appropriate. Separate procedures and registers may still be needed. Document count is not the measure of compliance. Coverage of the applicable obligations is what matters.
No. Requirements may concern different data, entities and purposes. Longer retention is not always correct, and stricter access does not replace a lawful processing basis. First establish what the requirement applies to.
One audit engagement can assess several sets of criteria, but their scope and conclusions must remain distinguishable. Applicable assessor and independence requirements must also be met. A general technical report does not automatically become a statutory audit.
It can reduce duplicated assessments and activities, but there is no guaranteed saving. Start by measuring duplicated work, the time required to produce evidence and the number of obligations without an owner.
NIS2, DORA and GDPR approach security from different perspectives: service operation, financial-sector resilience and the protection of individuals. Many activities can be performed together, but their legal significance needs separate assessment.
The starting point is not three new projects, but one map linking entity, obligation, process, owner and evidence. This enables the organization to reduce duplication without overlooking the requirements that genuinely apply.
How to Get into Cybersecurity: A Career Change Roadmap
A cybersecurity career change should start with choosing specific work, not buying more courses. This guide explores three directions: governance, risk and compliance, identity and access management, and SOC analysis. It includes a six-month learning plan, portfolio project ideas, certification guidance and advice on presenting your experience in a CV. It also explains how to use transferable skills and interpret junior salary data from Poland. The roadmap supports preparation for early-career applications, not a guarantee of employment within a fixed period.
Prepared by: CCyber Editorial Team
To move into cybersecurity from another career, choose a specific direction, build IT foundations and prepare work samples that reflect the tasks of your target role. Then compare your capabilities with job requirements and begin targeted applications. Completing a course or passing an exam does not replace the ability to explain what you did, why you did it and what the result means.
You do not need to study every area at once. Explore whether you prefer risk and requirements, access management or investigating security alerts. Previous experience in processes, user support, finance or IT administration can help, but it needs to be supplemented with knowledge relevant to the chosen role.
19 September 2026
The learning plan and portfolio exercises are original CCyber recommendations. They are not based on a study of the time required to find employment. Salary figures come from the Just Join IT 2026 report covering advertisements published in 2025. Certification requirements were checked against the issuing organizations’ sources.
Career changers, IT professionals considering a security specialization and candidates who have started studying but do not know what belongs in a portfolio. It is particularly relevant to people learning alongside their current job who need a plan with tangible outputs.
Instead of asking only “How do I become a cybersecurity specialist?”, consider which problems you want to solve. Are you interested in assessing risk, deciding who should access information or investigating whether an event indicates a user mistake or suspicious activity?
The ENISA European Cybersecurity Skills Framework describes different professional profiles. The NIST NICE Framework connects work roles with tasks, knowledge and skills. Framework roles are not, however, a ready-made catalogue of junior vacancies.
First exercise: collect around ten current early-career advertisements in an area that interests you. Identify recurring tasks, mandatory requirements and desirable skills. Also check the working language, location, any on-call arrangements and access to experienced colleagues.
This is research for your own plan, not a representative labour-market survey. Refresh it as you learn.
The following pathways are suggestions to explore, not a ranking of how easy they are to enter. Check actual vacancies to establish availability and responsibilities.
GRC means governance, risk and compliance. Relevant skills include analysing processes, assessing risk, interpreting requirements and evaluating evidence that safeguards have been implemented.
Experience in audit, quality, finance, procurement or business analysis can provide a starting point. That does not make GRC a role without technical knowledge. You need enough understanding of systems to distinguish a supplier’s statement from evidence that a safeguard operates.
Explore this direction by preparing a short risk assessment for a fictional service and a justified action plan. Do not begin by producing dozens of policies.
IAM includes granting, changing and removing access. Tasks to explore include processing requests, reviewing permissions after a role change and checking the accounts of people who have left.
This direction is worth investigating if you know user support, HR processes, application administration or data analysis. Roles vary considerably: operating an access-request process is not the same as designing a complex IAM platform.
Explore it by reviewing a fictional account register and making justified access recommendations. Further examples are available in CCyber’s Identity, Access and Cloud Security category.
A SOC is a security operations team. When preparing for an analytical role, focus on reading logs, constructing timelines, testing hypotheses and escalating cases that require further investigation.
Experience with troubleshooting and service tickets can be useful. Check whether a particular vacancy involves shifts and which decisions a beginner is expected to make independently.
Explore this direction by analysing training events and writing a short escalation ticket. An alert should not automatically become a confirmed attack in your report.
These are not the only options. With a background in software, cloud infrastructure or industry, also investigate application, cloud or OT security. You do not need to start studying all of them simultaneously.
In research published by ISC2 in 2025, hiring managers reported recruiting beyond traditional IT backgrounds and valuing analytical thinking, collaboration and problem-solving. The study covered 929 managers in six countries and did not include Poland. It provides recruitment context, not proof that every Polish employer follows the same criteria. See the ISC2 early-career hiring report.
In your CV, connect experience with a task. Examples include investigating discrepancies, maintaining records, handling requests, agreeing responsibilities or checking whether procedures have been followed.
Do not relabel your entire employment history as cybersecurity experience. Separate previous work, newly developed skills and educational projects.
Prepare to explain how a computer connects to a service, what DNS does, how a user account differs from an administrator account and where an event may be recorded. Learn Windows and Linux fundamentals, file permissions and the difference between a cloud service and a server you operate.
The objective is not to memorize every protocol. You should be able to apply foundations to a simple problem and identify what you still do not know.
Distinguish authentication from authorization, threats from vulnerabilities and backups from synchronization. Practise connecting a missing safeguard with a consequence for a user or business.
The NIST CSF 2.0 Small Business Quick-Start Guide provides an introduction to organizational security management. You do not need to design an entire management system immediately.
Include short documentation passages and written exercise summaries in your English practice. A practical goal might be understanding an instruction and writing a useful ticket, rather than achieving a perfect accent.
For each task, record the objective, sources, activities, result and limitations. These records will become the basis of your portfolio.
Working assumption: 6-8 hours per week alongside your current job. This is a proposed study structure, not a validated time-to-employment estimate. Someone without IT foundations may need a longer introductory phase. An experienced administrator may progress through some material faster.
An illustrative eight-hour week could include two hours of foundations, four of exercises, one of documentation and one of English or vacancy research. Adjust the allocation to your main gap.
Review vacancies, assess your foundations and complete two small exercises from different pathways. Notice which work you enjoy more and where you can explain the result logically.
Output: a selected direction, a skills-gap list and a sustainable weekly plan. Before spending substantially on training, establish whether you enjoy working through the tasks themselves.
Use your own isolated lab or a purpose-built training environment. Practise accounts, roles, logs and recovery of test data. Do not limit learning to watching lessons.
Output: short exercise records and the ability to repeat a basic task without following a step-by-step walkthrough.
Select one of the projects below. Define its scope, input data and completion criteria. Prepare a first report and ask a knowledgeable reviewer to identify weaknesses in your reasoning.
Output: a project documenting decisions and limitations, not just screenshots.
Improve the first project and complete a second task related to the same role. Add a more difficult variation: missing information, an ambiguous event or an exception requiring a decision.
Prepare a CV focused on specific tasks. Once you can perform the basics and explain your projects, begin targeted applications. You do not have to wait until the final month.
Practise presenting a project, answering foundational questions and saying “I do not know, but here is how I would check”. Review feedback and update your skills-gap list.
Output: closer alignment with selected roles and a follow-up learning plan. Completing six months does not automatically establish readiness or set a deadline for receiving an offer.
Choose one main project and a second supporting task within the same pathway. You do not need to complete all three suggestions.
Describe a fictional services company using business email and cloud applications. Develop five risk scenarios, identify existing safeguards and information gaps, and recommend three priority actions.
What to show: a short risk register, justification of priorities and a one-page management note. Clearly separate assumptions from verified facts.
Quality check: another reader should understand why each issue matters, who should act and which evidence would demonstrate improvement. Do not present the exercise as a real compliance audit.
Create a fictional register of 20 users, several roles and two applications. Include an employee departure, a departmental move and an account without an owner. Recommend which access to retain, change or investigate.
What to show: decision rules, discrepancies, a proposed approval process and a method for verifying access removal. A spreadsheet may support analysis, but does not itself demonstrate technical implementation.
Quality check: every recommendation needs a reason. Do not automatically remove an account merely because it looks unusual. Establish its purpose and dependencies first.
Use synthetic logs or training material permitted for this purpose. Construct a timeline, identify unusual events and develop at least two possible interpretations. Specify which additional information would help distinguish them.
What to show: a concise analytical ticket, the filters or queries used, observations separated from hypotheses and a reason for escalation.
Quality check: the reader should be able to follow and reproduce the analysis. Alert volume or use of a well-known tool does not replace a sound conclusion.
To explore professional tasks, consider the tools and micro-challenges described in CISA’s career-development resources. Use them to experience a type of work, not as complete preparation for a job.
For security, compliance and identity fundamentals in Microsoft environments, consider the SC-900 learning material. It focuses on Microsoft’s ecosystem and assumes basic familiarity with IT, networking and cloud concepts.
Working rule: practise only in environments where you have appropriate authorization. Do not scan random companies, reuse your employer’s confidential documents or publish real credentials. For cloud labs, also check the costs.
AI can help explain concepts and suggest revision questions. Verify the results against documentation and exercises. Do not submit analysis you cannot explain as your own work.
ISC2 Certified in Cybersecurity, or CC, does not require prior work experience. It can provide a reference point for foundational study. Requirements are described on the official CC certification page.
Microsoft SC-900 covers security, compliance and identity fundamentals across Microsoft services. It is an option to consider when that ecosystem appears in your learning plan or target vacancies. The scope is defined in the official certification description.
You do not need both credentials. Before purchasing, check the current syllabus, regional price, retake conditions and ongoing requirements. Distinguish a course-completion certificate from certification obtained under the issuer’s rules.
A certification complements a portfolio. It should not become a reason to postpone practice and applications.
The Just Join IT 2026 report, based on advertisements published in 2025, lists PLN 7,500 per month gross under an employment contract and PLN 12,844 per month as a B2B invoice amount excluding VAT for junior roles in its Security category. The figures appear in the Security category analysis.
According to the report’s methodology, seniority-level figures are medians of the midpoints of advertised salary ranges. They are not guaranteed earnings for candidates without experience. They are historical data from one platform, not a current pay scale covering all Polish employers.
A B2B invoice amount described as “net” is not personal take-home pay. Do not compare it directly with an employee’s bank-account payment. These are also different sets of advertisements, not two contractual valuations of the same job.
When planning a career change, review current vacancies for your role, level and location. Do not base a substantial training purchase on the highest salary found in a report.
Create an “Educational projects” section. For each project, identify the problem, your contribution, the result and a link to safely published material. A portfolio can be a repository or an organized collection of documents. GRC work does not need to masquerade as software development.
Example CV entry: “Educational IAM project: created a model register of 20 accounts, identified access discrepancies following role changes and designed an access-removal workflow. Synthetic data, no production deployment.”
During the interview, explain which information was missing, what additional evidence would change your recommendation and which actions would need approval. This demonstrates more than reading out a finished report.
Also consider an internship, an assistant role or agreed responsibilities within your current organization. IT support or access operations can form part of your plan, but do not automatically lead to a security promotion. Check the actual learning opportunities and supervision.
A useful checkpoint is being able to explain the foundations and independently complete and defend a simple task relevant to the position. You should understand your solution’s limitations and know when assistance is needed.
Do not wait until you know every tool in a vacancy. Separate mandatory from desirable requirements. At the same time, do not claim capabilities you cannot demonstrate.
If applications do not lead to interviews, investigate vacancy selection and CV alignment. If practical assessments are the difficulty, revisit the relevant foundations. Treat these as hypotheses to test, not an automatic diagnosis of why an application was rejected.
Before enrolling, ask about entry requirements, weekly workload and specific assignments. Establish who reviews projects, how feedback works and what recruitment support actually includes.
Check the total cost, any examination or lab charges and participation conditions. Where a provider publishes graduate employment figures, ask about the measurement period, participant count and definition of employment in the field.
Choose a programme aligned with your target work. A large module count will not help if there is insufficient time for independent practice and correcting mistakes.
Foundations are explored in the Training and Cyber Awareness category. The article on future skills provides broader development context, while resources on identity and access introduce practical problems. These links lead to Polish-language blog categories.
This guide focuses on an individual career-change plan. It is not the syllabus of a particular training cohort.
The CCyber cybersecurity bootcamp is aimed at beginners and IT professionals changing specialization. Its published programme includes portfolio assignments, CV preparation, mock interviews and a certification plan.
Review the programme against your starting point. Before enrolling, identify your previous experience, preferred direction and available study time. This makes it easier to assess whether the scope and intensity suit your needs. Completing training does not guarantee a job offer.
Pathways based on other experience and qualifications exist, but an individual vacancy may require specific education. Check your target employers’ requirements and develop skills matching the work.
Not every pathway requires programming at entry. That does not mean there are no technical requirements. Data analysis, understanding systems and later automation can matter outside development roles. Follow the actual job scope.
It depends on your starting point, study time, learning quality and recruitment process. The roadmap organizes preparation. It does not establish an employment deadline or a guaranteed level of independence.
Do not assess the opportunity solely by age. Consider required skills, available learning time and the conditions of early-career roles. Begin with a limited trial phase before making large purchases or leaving your current job.
No. A GRC portfolio can include a justified risk assessment, while an IAM portfolio can demonstrate an access review and workflow. The format should match the tasks and clearly identify your contribution and limitations.
A cybersecurity career change should be built around specific capabilities, not just a professional title. Choose a direction, strengthen your foundations, complete projects and check whether you can explain their results.
The important shift is from “I completed a course” to “I can perform this task and understand the limits of my knowledge”. That approach supports preparation for early interviews and more informed decisions about what to do next.
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.
