Free Phishing Test

KSC self-identification is an independent assessment of whether the organization is subject to the Act on the National Cybersecurity System (KSC), implementing the NIS2 directive, and assigning itself to one of three categories: key entity, important entity or no obligation. To conduct it, you need to check the sector of activity, the size of the enterprise and the conditions set out in Art. 5 of the Act. The result of positive qualification is the obligation to enter the KSC Register by October 3, 2026. The amendment to the KSC Act will cover, according to the estimates of the Ministry of Digitization, approximately 38-42 thousand entities subject to regulation in Poland.

What is self-identification in KSC?

You may be running a company operating in a sector covered by the regulations KSC 2.0. However, you have not received an official letter informing you that from today you are a key or important entity. Your organization must be the first to check whether the new obligations actually apply to it.

This is what self-identification is all about. This is an independent assessment of whether the activities conducted are subject to the KSC 2.0 Act, and if so, whether the organization should be classified as a key entity or an important entity. The starting point for such an analysis is Art. 5 of the Act and Annexes No. 1 and No. 2, which indicate the sectors, subsectors and types of activities covered by the regulation.

In practice, however, it is not enough to check the PKD code entered in the National Court Register. What is much more important is what the company actually does, what services it provides and on what market it operates. If the organization’s actual activities fall within the sector covered by the Act, the provisions may apply even if the main PKD code does not indicate so.

Properly performed self-identification should result in a clear answer:

If the analysis shows that the company belongs to one of the first two categories, the next step will be to make an entry in the KSC List. This is an official register of key and important entities, kept by the Minister of Digitization in the application wykaz-ksc.gov.pl and technically based on the S46 System.

Who is obliged to self-identify?

The obligation to self-identify applies to every entity operating in the sector indicated in the annexes to the Act on the National Cybersecurity System – regardless of whether it is a private company, a company with local government participation, or an office. Two pillars determine membership in the system: sector of activity and size of the organization.

The sector decides whether a given activity is included in the catalog protected by the Act at all – energy, finance, health care, transport, water and sewage management and several other industries listed in Annexes 1 and 2 (read more in the article about the amendment to the KSC). However, size determines which of the two categories of entities an entity that meets the sector criterion falls into.

The key entity criteria from Annex 1 differ from the important entity criteria from Annex 2 primarily in the importance of the potential effects of the incident on the state and the economy, not in the assessment mechanism itself.

When calculating the size, not only one’s own employment and finances are taken into account, but also related and partner enterprises – a Polish company may suddenly become a large entrepreneur through a foreign investor or shares in a capital group, even if it employs few people itself. The Act on the National Cybersecurity System does not distinguish between the private and public sectors: the obligations cover both, and the fact that the owner of the company is a commune or the State Treasury does not in itself determine the qualification.

We can help you determine whether your organization is subject to KSC – as part of an ISMS audit, which combines the perspective of a legal advisor with technical security diagnosis and practical team training.

Ask about an ISMS audit

How to self-identify KSC? Three steps according to the Ministry of Digitization

The Ministry of Digitization divides the self-identification process into three steps: checking the sector, determining the size of the enterprise and analyzing Art. 5 of the Act. The order matters – only the result of all three steps together gives the answer whether the entity is key, important, or not subject to the Act at all.

01 Check your business sector

The first step is to verify whether the business activity is within the sectors or subsectors indicated in Annex No. 1 (key entities) or Annex No. 2 (important entities) to the Act. The Ministry of Digitization emphasizes that what matters in this assessment is the actual nature of the business, and the PKD code has only auxiliary meaning – the actual scope of services provided or tasks performed is decisive, not the entry in the register.

For example, a company that operates in one industry on paper, but actually provides services from the sector covered by the Act – e.g. as a subcontractor in the energy or health care supply chain – should verify itself in relation to this real scope of activity, not in relation to the code in the National Court Register. Even an entity providing services only partially covered by the Act should analyze this part of its activities separately.

02 Specify the size of the company

The second step is to determine the size of the entity according to the thresholds of micro, small, medium and large enterprises, including affiliated and partner enterprises.

The thresholds are checked separately: it is enough to exceed one criterion – employment or financial – for the company to be placed in a higher size category, even if the second criterion remains unmet.

There is one clear exception to this rule. Telecommunications undertakings covered by the amendment to the Act, regardless of their size, have a different qualification threshold for the key/important category than other industries:

SizeType of entity (telecommunications undertaking)
Large entrepreneurkey entity
Medium-sized entrepreneurentity key
Small entrepreneurimportant entity
Micro-entrepreneurimportant entity

This is exactly the exception explained by the case from our webinar about KSC: a telecommunications organization employing less than 50 people, but with a revenue of over EUR 10 million, is a key entity – despite the small number of employees, because in telecommunications already an average entrepreneur has the status crucial, not important.

We invited a legal advisor and a partner of a digital law firm to a discussion about UKSC / NIS2, during which we broadly discussed the topic of self-identification and entry into the KSC List – receive free access to the recording and additional materials!

Free webinar about KSC – receive the recording and materials!

03 Analyze the article. 5 of the Act

The third step is the analysis of art. 5 of the KSC (Article 5 of the Act on the National Cybersecurity System), which specifies detailed rules for recognizing entities as key or important, including cases of being covered by the Act, regardless of their size. Only after analyzing this provision can you finally determine whether the entity is key, important or not subject to the provisions at all

Meeting the conditions of Art. 5 clearly means that the entity will be subject to the provisions of the Act regardless of the result of the second step – it is this path that allows, for example, a small municipal company to fall into the category of an important entity despite not meeting the size thresholds (full case in the section below). In some cases, an organization that does not formally meet the size criteria, but meets the sectoral conditions set out in Art. 5.

Additional tools to help with self-identification

Before you start manual analysis from scratch, compare your findings with ready-made tools:

  1. SME qualifier from PARP – the official tool for determining the size of an enterprise.
  2. UKSC/NIS2 Validator by Muszyński Law Firm – a free preview tool covering all three steps.
  3. Guides of the Ministry of Digitization – official explanations and answers to questions, updated on an ongoing basis.

None of these tools is a substitute for legal analysis. They provide an indicative result, based on data that you enter yourself – they do not take into account nuances such as affiliated enterprises, sector exceptions or the conditions under Art. 5.

If you have any doubts about the qualifications of key and important entities, it is best not to guess on your own – contact us to discuss the result of self-identification and the scope of the ISMS audit tailored to your organization.

Key or important entity? Examples of qualifications from practice

The sector and size criteria themselves sound simple on paper, but in practice, lawyers specializing in KSC regularly receive questions about borderline cases. The table below shows six typical situations and their qualification score.

Municipal company: waterworks and sewage, 20 employees

Limited limited liability company with 100% of the commune’s shares, operating in the water and sewage sector (Annex No. 1) and employing 20 people, does not reach the threshold of an average entrepreneur in terms of size. Nevertheless, it qualifies as an important entity – it does not meet the size criteria, but carries out a public utility task using information systems (Article 5(2)(8) of the UKSC).

Telecommunications entrepreneur below the employment threshold

A telecommunications company employing less than 50 people but with revenues exceeding EUR 10 million meets the criteria of a medium-sized entrepreneur despite low employment. In telecommunications, a medium-sized entrepreneur already has key status – this is a sector exception, so the company qualifies as a key entity.

Energy operator with over 250 employees

A large energy company (Annex No. 1), employing over 250 people, qualifies as a key entity – the sector and size clearly indicate this. However, it is worth remembering that some operators of particular importance for the energy system (e.g. transmission system operators) may be key entities regardless of their size – similarly to the telecommunications exception described above. Therefore, step 3, i.e. analysis of Art. 5, it is worth verifying even in seemingly obvious cases.

Catering company outside the sectors from the attachments

A small catering company employing 15 people operates outside the sectors indicated in the annexes to the Act – it is not subject to the KSC. The food sector covered by the amendment mainly concerns wholesale distribution and large-scale industrial production and processing of food, not catering and catering services operating locally. A company from the food industry should check on which side of this border it actually is, instead of relying solely on the general term “food sector”.

IT supplier for the energy operator

A small IT company (30 employees), providing services to an energy operator, does not itself operate in the sector indicated in the attachments – it is not automatically covered. Being a supplier of an entity covered by the KSC does not in itself determine coverage by the Act, but the contractor may impose contractual requirements.

The result of self-identification based on sector and size is not always final

The Act provides for an additional path: the minister may, by administrative decision, recognize an entity as key if it is the only one providing a service of key importance for critical social or economic activity via an information system – regardless of the fact that according to the size thresholds the entity would be considered important or even outside the scope of the Act. This applies, for example, to the only water supplier in the commune, with no alternative for residents: lack of competition on the local market may be the basis for the minister’s decision, even if the company does not meet the threshold of a medium-sized entrepreneur.

A separate category consists of digital service providers (e.g. providers of cloud, trading platforms or internet search engines) andexisting key service operators, operating under the old Act of 2018 – both groups were entered into the KSC List ex officio, without the need for self-registration.

The case of a municipal company from the table above comes directly from the questions asked at our webinar on the implementation of KSC. Legal advisor Jerzy Muszyński explained when such a company may be considered an important entity despite not meeting the employment threshold:

It may be determined by the fact that the company carries out public tasks, a public utility task within the meaning of the Municipal Economy Act, and carries out public tasks using information systems.
Jerzy Muszyński, legal advisor at SECAWA

Marcin Serafin drew attention to a threshold that is easy to forget about in such a company – the number of employees is not the only criterion:

This is something that could potentially be important […] because if it is to reach this threshold of ten million euros in turnover or balance sheet total, it will be subject to this regardless of whether it has twenty or two hundred employees.
Marcin Serafin, digital law specialist, partner of the Sterberg law firm

Twenty employees of a water and sewage company from our table are not enough to cross the threshold of a medium-sized entrepreneur – but if its turnover or balance sheet total reached EUR 10 million, qualification would be certain regardless of employment.

By when do you have to self-identify? Key terms

The deadline for self-identification and entry into the KSC List is October 3, 2026. The schedule is as follows:

Self-registration takes place via the Wykaz KSC application, after logging in with a trusted profile, e-ID, electronic banking or qualified signature.

The lack of penalties until 2028 does not mean the absence of an obligation – failure to self-identify and register is a violation of the regulations from day one, but not financially enforceable. Why this distinction can be confusing, we described in more detail in the article about why the lack of penalties until 2028 is a trap.

The most common errors when self-identifying and starting the implementation of the KSC Amendment

Legal advisor Jerzy Muszyński, based on implementation experience and control practice, pointed out six errors during the webinar that most often mean that the KSC implementation starts in the wrong direction from the very beginning:

The group of key and important entities that make these mistakes include both large, experienced organizations and those entering the system for the first time. KSC imposes the obligation not only to register, but above all to conduct real risk management – neglect of the duties of key entities is usually revealed only during an inspection or security incident.

Why is it worth leaving an evidentiary trail?

Self-identification without documentation is self-identification that does not exist in the eyes of the controller. As Jerzy Muszyński emphasized:

Every company should perform such self-identification and approach this self-identification in an evidential way, i.e. leave some trace of this self-identification.
Jerzy Muszyński, legal advisor at SECAWA

In practice, an evidentiary trail means a specific set of documents, not the decision itself recorded in an email or agreed at a management meeting. It’s worth preparing:

Such a set of documents serves two functions at once. Firstly, it organizes the analysis itself – it is difficult to confuse a category when the data is compiled in one place and not scattered in the memory of several people. Secondly, it becomes defensible material: if the regulator asks why the company qualified in a certain way, the answer is a document, not a memory from a conversation from a year and a half ago.

Self-identification documentation is not an isolated trace – it becomes the first element of broader information security management system (ISMS) documentation, which will need to be expanded after being included in the list. A positive result of self-identification triggers the obligation to enter the KSC List, and the documentation referred to above is proof that this entry obligation was preceded by a reliable analysis, not guesswork.

Application to the KSC List – frequently asked questions

What is self-identification in KSC? Self-identification is an independent assessment of whether an organization is subject to the Act on the National Cybersecurity System and assigning itself to the category of a key or important entity or determining that the Act does not apply to it. The analysis is carried out independently, without a request from the office.

By when do you have to self-identify? The window for self-registration in the KSC List lasts from May 7 to October 3, 2026. Entities entered ex officio – m.in. public and telecommunications entrepreneurs – were registered earlier, by May 6, 2026.

Is there a penalty for failure to report by October 3, 2026? Not immediately. Fines are in force only from April 3, 2028, but the registration obligation itself runs regardless of this exclusion – the delay does not eliminate the violation of the regulations, but only postpones its financial enforcement.

Is a company that is a supplier of an entity covered by the KSC also subject to the Act? Not automatically. The mere fact of being a supplier of a key or important entity does not determine coverage by the act, but the contractor may impose security requirements in the contract – this is a typical mechanism for spreading the obligations of regulated entities to the rest of the supply chain.

Does outsourcing at KSC exempt you from statutory obligations? No. Outsourcing at KSC – for example, outsourcing hosting, cloud or data center services to an external supplier – does not transfer statutory liability. The key entity ensures the security of its systems regardless of whether it maintains the infrastructure itself or through a subcontractor, and must supervise this as part of supply chain management.

What tools help in self-identification? The SME qualifier from PARP and the UKSC/NIS2 validator from the Muszyński law firm provide an indicative result based on self-entered data. None of them replaces legal analysis – if in doubt, it is worth consulting the result with a lawyer specializing in KSC.

Summary

Self-identification is determined at the intersection of three elements: the sector of activity, the size of the enterprise and the conditions set out in Art. 5 of the Act – none of them alone gives a certain answer. An error made at this stage costs more than the classification error itself: it leads to an unnecessary implementation project, overlooked responsibilities, or documentation that will not withstand the question of why the company qualified this way and not another.

The deadline for registration in the KSC List is October 3, 2026, and organizations that are already unsure about their status today usually do not start any other implementation work.

We implement KSC in the alliance of law (Kancelaria Muszyński) and technology (SECAWA) – from the qualification of the entity, through cybersecurity audit, to the action plan and team training. If you want to determine where your organization stands, ask about an ISMS audit.

Arrange an ISMS audit: legal analysis of the entity’s qualifications, technical security review and a report with action priorities in one study.

Ask about an ISMS audit

JadePuffer is the first documented ransomware attack carried out from start to finish by an autonomous AI agent, without human involvement in decision-making at any stage of the intrusion. The Sysdig Threat Research Team tracked down an operation in which a large language model independently exploited a vulnerability in Langflow, took over credentials, moved to a production server running MySQL and Alibaba Nacos, encrypted 1,342 configuration items, and left a note demanding a ransom in Bitcoin.

The agent did not copy the finished script. He diagnosed the cause of the error and implemented a fix at a pace unattainable for a human reading the log by hand: in a documented case, 31 seconds passed from a failed login attempt to a working correction.

JadePuffer attack at a glance

The existing incident response procedures assumed that there is always a person behind a ransomware attack who can be slowed down, misled or with whom time can be negotiated. JadePuffer shows that this stage of tradecraft can now be handed over to the model.

What is ransomware?

Ransomware is malicious software that encrypts files or entire operating systems, and the unlocking of data requires the payment of a ransom, most often in cryptocurrency. This type of attack has been one of the most profitable tools in the hands of criminal groups for over a decade, because it attacks what has the greatest operational value for an organization: access to its own data.

The classic ransomware Trojan scenario looks similar regardless of the variant. Malicious code enters the system through phishing, a broken password or a software vulnerability. It then silently encrypts key data on disk and in backups, and displays a ransom note with a payment deadline.

The story shows the growing ingenuity of criminals, but also the repeatable pattern of ransomware: encrypt, demand, wait.

A ransomware group doesn’t have to write its own code from scratch today. The cybercrime market offers ready-made ransomware-as-a-service kits, and the operator’s role is often limited to selecting the target and sending the first payload. Ransomware threats have evolved from individual, proprietary programs into a service-based, repeatable business model – even before autonomous language models came into play.

JadePuffer – the first ransomware attack fully controlled by LLM

The Sysdig Threat Research Team documented Operation JadePuffer in the summer of 2026 – the first known case in which the entire ransomware attack chain, from reconnaissance to data destruction, was led by an autonomous agent based on a large language model, without human intervention at any stage of the intrusion. Sysdig calls this type of adversaryagentic threat actor (ATA) – an actor whose offensive ability comes from an AI agent rather than a manually maintained toolkit.

The attack took place on two different targets. The first compromised host served the agent only as a starting point to hack into the actual, much more valuable target.

How the JadePuffer attack worked step by step

Phase 1 – input host (Langflow)

  1. Entry via CVE-2025-3248 – Unauthorized RCE vulnerability in the code validation endpoint of Langflow, a popular open-source framework for building LLM applications and agents. The manufacturer patched the vulnerability on April 1, 2025, and CISA marked it as actively exploited in May of the same year.
  2. Reconnaissance and secret capture – the agent collected host data (id, uname, network interfaces, processes) and in parallel searched the environment for API keys of LLM providers, cloud credentials (including Chinese providers Alibaba, Tencent, Huawei, in addition to AWS, GCP and Azure), cryptocurrency wallets and database data.
  3. Dump of the local Postgres Langflow database – stolen credentials, API keys and user records were saved locally, previewed, and temporary files deleted.
  4. MinIO enumeration – The agent used the default credentials (minioadmin:minioadmin) to search the object bucket, including the terraform-state bucket. When one of the queries returned XML instead of the expected JSON, the next payload immediately adapted the parser to the new format.
  5. Maintain access – on the Langflow host, the agent installed an entry in the task scheduler (crontab), sending a signal to the attacker’s infrastructure every 30 minutes. As a result, even a server restart did not interrupt the connection with the attacker.

Phase 2 – actual target (MySQL production server and Alibaba Nacos)

  1. Pivot to a separate server – from the Langflow host, the agent moved to an Internet-exposed production server with a MySQL database and the Alibaba Nacos service, using a root account whose origin the researchers were unable to determine.
  2. Nacos Takeover – In parallel, the CVE-2021-29441 authentication vulnerability was exploited, the JWT was spoofed using the publicly known default Nacos signing key, and a backdoor administrator account was injected into the database via root access.
  3. Recognition of container escape – the agent tested writing and reading files via MySQL, checked access to docker.sock and init process files – a typical set of actions preceding an attempt to exit the container.
  4. Encryption – All 1342 Nacos configuration elements were encrypted with the AES_ENCRYPT() function in MySQL, the original tables were deleted and in their place a README_RANSOM table was created with the ransom note, Bitcoin address and email contact.
  5. Mass data destruction – The agent escalated from deleting single lines to DROP DATABASE commands on entire schemas, commenting in the code its own prioritization of targets according to the potential value of the data. It is worth noting: the annotation that the data was previously copied to an external server is a statement made by the agent itself, written in its own code, and not a fact confirmed independently by researchers. The actual scale of data exfiltration remains unknown.

Four pieces of evidence that the attack was directed by an LLM, not a human

Sysdig identifies four independent premises that together rule out the scenario of a fixed, pre-written script:

Time (UTC)Agent Action
19:34:24Inserts the xadmin account with the password hash generated by the call subprocess
19:34:36Login attempt fails
19:34:48Tests two possible causes of error in parallel
19:35:07Introduces a fix: direct import of bcrypt library, removal and restoration accounts
19:35:18Login is successful

From the failed attempt to the working fix, 31 seconds passed – a time unattainable for a human reading the error log, making a diagnosis and writing a correction.

Consequences for the organization – why this is a wake-up call for CISOs, CTOs, CSOs and CIOs

The most serious consequence of an LLM-driven ransomware attack is not the data encryption itself, but the fact that the assumptions on which data recovery and incident response procedures have been based so far no longer work.

JadePuffer is not an isolated signal that language models can be turned against an organization

We recently described how attackers convinced the Meta AI chatbot, to reset passwords and help take over 20,225 Instagram accounts – completely different vector, same mechanism: a model performing malicious actions based on what it “understood”.

The growing number of reported ransomware attacks and ransomware incidents using AI shows that this is no longer a theoretical scenario, but part of the cyberattacks in the GenAI era landscape that organizations must face today. If you want to see more such cases broken down into prime factors, in the free webinar series AI vs. Cybersecurity Secawa we covered both AI-driven attacks and attacks targeting AI systems themselves, with recordings and downloadable materials.

Free series of webinars: AI-supported attacks, Shadow AI, AI-prompt injection attacks and AI as CISO support. 4 meetings, additional materials and several SECAWA specialists who discussed the topic of AI in the context of cybersecurity in detail.

Receive recordings and materials from the AI vs Cybersecurity series

How to protect your organization against AI-driven ransomware?

Preventing ransomware attacks of this type does not require new tools, only consistent closing of vulnerabilities that JadePuffer exploited in No zero-day exploit was needed:

However, none of these recommendations will work without people who understand that social engineering in the era of AI agents looks different than it did just two years ago. It is also worth preparing security and IT teams for social-engineering methods supported by GenAI, because the line between a purely technical attack and one supported by manipulation is increasingly blurred.

Summary

JadePuffer changes three assumptions on which previous defense planning was based. First, the barrier to entry for conducting a ransomware attack has dropped to the cost of running an agent – ​​and with models powered by stolen computational access, that cost approaches zero. Second, old, seemingly benign vulnerabilities – like the 2021 Nacos vulnerability – are now automatically refreshed by agents searching the entire historical CVE catalog, so neglected, unpatched infrastructure becomes a more—not less—attractive target. Third, the code generated by LLM self-describes its intent – the same feature that makes the agent dangerous gives defenders a new chance to detect an attack before it is encoded.

Threat modeling for AI-based systems is no longer an academic exercise – it is the starting point for risk assessment in any organization that implements agent-based AI tools or is a potential target of ones such as JadePuffer. You can find more about how to systematically model the threats related to prompt injection in AI systems in our previous material.

If you prefer to see these mechanisms broken down into prime factors live, we invite you to a free series of webinars AI vs. Cybersecurity, where we covered both AI-driven attacks and attacks on AI systems themselves – with recordings and downloads available.

Sources:

https://www.bleepingcomputer.com/news/security/jadepuffer-ransomware-used-ai-agent-to-automate-entire-attack

https://www.darkreading.com/cyberattacks-data-breaches/jadepuffer-first-complete-llm-driven-ransomware-attack

KSC does not add new responsibilities to the CISO, but rather changes his role in the organization. Building digital resilience is something that mature companies have been doing for a long time – many of them have implemented security procedures, appointed responsible people, and systematically conducted tailored and realistic phishing simulations or organized cybersecurity training before the amendment appeared.

It is not a new technical obligation that raises the profile of the CISO role today, but the responsibility that has fallen on the management board. Amendment to the KSC Act, implementing the NIS2 directive, makes management personally responsible for cybersecurity.

We talked about what this change looks like in practice in a webinar with Marcin Serafin – a digital law specialist and partner of Sterberg law firm – and Jerzy Muszyński, a legal advisor who runs his own law firm. The conversation was moderated by Maciej Kołtoński, thanks to which there was also a business perspective. And if you want to watch the entire recording, fill out the form on this page.

What actually changes KSC in the CISO position?

KSC changes the position of the CISO – from a person performing technical tasks to a management partner who is personally responsible for cybersecurity.

So far, security has been treated as the subject of the IT department. The amendment shifts this burden higher, to the very top of the organization: it is the management who approves the risk analysis, provides the budget and is responsible for its own training, and delegating tasks to IT does not relieve it of its responsibility.

As legal advisor Jerzy Muszyński emphasized during the webinar:

For the first time, in such a broader context, we can talk about the fact that […] the company’s management board is to be an active entity participating in the ongoing management of cybersecurity within the company’s structures.
Jerzy Muszyński, legal advisor at SECAWA

The board needs a CISO as a risk translator

The management board, which is personally responsible for cybersecurity, necessarily must have someone who understands the risk, can manage it and translates it into decisions. It is from this relationship that the new position of CISO comes from.

Marcin Serafin described this mechanism directly:

When our management board members have their duties in terms of regular training, making decisions, and supervising the entire system of thinking about cybersecurity, they inevitably start to have to use someone who will explain this reality to them. Who will actually support them, and not just replace them.
Marcin Serafin, digital law specialist, partner of the Sterberg law firm

In other words: The CISO ceases to be a contractor, and becomes an advisor on whose analysis the management bases its own decisions – and its own responsibility.

CISO becomes an integral part of business

KSC 2.0 ends treating cybersecurity as a separate world, separated from business. Today, systems, data and tools are already a business – not an addition to it.

I hope that the problem of many CISOs who were left to themselves will end: do your own thing, tinker with your devices, analyze your reports, but don’t disturb our business. This is something that has to end – because this business is all about software and all these tools.
Marcin Serafin, digital law specialist, partner of the Sterberg law firm

For organizations, this means that security is no longer an incidental expense, but a condition for business continuity.

Not everyone is happy with this “promotion”

The growing importance of the CISO comes at a price – close, demanding cooperation with the management board. Not every specialist dreams of explaining risk to managers and sitting at the decision-making table. “This is a kind of increase in the importance of the CISO role within the organization (…). The CISO as a partner for the management is not left alone.” – said Marcin Serafin during webinar about KSC.

The advantage, however, is this: CISO stops working in a vacuum. He gains the support of the management board, but in return he has to spend more time explaining what exactly the threats are and how to solve them.

Why is there no single, universal definition of the CISO role?

A CISO in one organization is not the same as a CISO in another – these roles can be extremely different. The KSC clarifies the duties, but does not impose a single model for filling this position.

A CISO in an organization is not [equal to] another CISO in another organization. These roles are indeed extremely different.
Marcin Serafin, digital law specialist, partner of the Sterberg law firm

The differences in the CISO role concern resources, independence and the right to make decisions – some act independently, others are dependent on the management at every step.

Implication for the decision maker: Before filling this role, the board must decide the scope of authority, budget and independence of the CISO.

What does KSC mean in practice – for the management board and for CISO

Real change occurs when the CISO gets access to the management board, a budget and the right to make decisions – not just a title.

In practice, this means three things:

→ for the management board: training, social-engineering tests and penetration testing, approving risk analysis and security budget is an obligation, not a gesture of good will,
→ for CISO: more time to translate the risk in the language of business than on the risk itself tools
→ for the organization: clear path, who receives the decision and who is responsible for it.

Summary

The new position of CISO comes from the responsibility that KSC has placed on the management board.

This is a change that both parties can benefit from:

There is one condition: the CISO role must be given resources, budget and the right to make decisions.

The entire conversation – with specific examples, implementation schedule and question session is available on request. Sign up and you will receive access to the webinar recording and a set of materials (presentation and UKSC/NIS2 validator).

Free webinar. How to approach the implementation of KSC sensibly: so as not to take on everything at once, but also to complete the duties on time.

Receive materials and a recording of the webinar!

Poland’s Digitalization Strategy until 2035 is the first comprehensive document in the country’s history that organizes the country’s digital transformation around one goal – improving the quality of life of citizens thanks to digitization. It was developed by the Ministry of Digitization, and in October 2024 it was submitted for public consultations as a project replacing the Integrated State Computerization Program.

The document organizes activities around four horizontal areas:

They are complemented by detailed areas divided into three levels: state (including e-services, digital identity, cloud computing, open data), people (safe digital space) and economy and technologies (including artificial intelligence). In this structure, cybersecurity plays the role of a foundation that crosses other areas, and the credibility of all e-services depends on it.

The strategy sets out an increasing path of expenditure on digitalization: from approximately 0.8% of GDP in 2025 to 2% of GDP in 2030 and ultimately 5% of GDP in 2035, which corresponds to approximately PLN 100 billion annually after 2030.

Security teams will feel the effects of the Strategy very concretely. It announces:

In the following, we explain what the Strategy is, what it covers, what its schedule is and how to translate its provisions into the priorities of security teams.

What is the Polish Digitization Strategy until 2035?

Poland’s Digitization Strategy until 2035 is a cross-sectoral strategic document in the field of state computerization, which for the first time covers the digitization of the country as a whole – not as a separate ministry, but as a process permeating almost all areas of functioning of society, the state and the economy. The primary goal of the document is to improve the quality of life of citizens through digitalization by 2035

The strategy was prepared by Ministry of Digitization in cooperation with other government administration offices and with the participation of social and business stakeholders. It replaces the Integrated State Computerization Program and is intended to constitute a strategic basis for spending European funds intended for digitalization, setting the direction of negotiations for the upcoming financial perspective.

The document’s objectives are developed in related sectoral documents, including:

The conclusion for security managers is obvious: the general provisions of the Strategy will be detailed in sectoral regulations, which will directly affect the everyday work of IT and security teams. Tracking these documents is not a formality, but a source of specific obligations.

Why was the Strategy created?

The State Digitization Strategy was created to organize the development of digital services, which have so far been built in isolation from each other, without a common direction. As Deputy Minister of Digital Affairs Dariusz Standerski put it, the document “ends this era of fragmented development of digital services” and for the first time “defines our digital plan for the next decade.”

We set specific goals – in ten years, Poland will be the leader in the digital development of Europe. By 2030, 100% of key public services will be available digitally, 85% of Poles will have basic digital competences by 2035, and we will allocate 5% of GDP to digitization.
Dariusz Standerski, Deputy Minister of Digitization

The document responds to a specific ambition: Poland is to become the leader of digitalization in the European Union, and not remain a recipient of other people’s technologies. This is achieved by measurable goals with deadlines and indicators, including:

The strategy also clearly defines what digitalization should not do: make people dependent, disinform or exclude. Protecting citizens’ digital rights, protecting children and young people against harmful platform mechanisms and building technological sovereignty are treated on an equal footing with the development of e-services. The whole thing fits into the EU agenda “The Road to the Digital Decade” by 2030.

What does the Polish Digitization Strategy cover?

The strategy organizes the country’s digitalization in two dimensions: four horizontal areas, which constitute the foundation of the transformation, andthree levels containing detailed areas.

Four horizontal areas

This is the starting point of the entire Strategy – areas whose condition determines the success of the rest:

Three levels: State, People, Economy and Technologies

The remaining objectives of the Strategy are grouped into 17 areas on three levels:

On what principles is the Strategy based?

The strategy declares the principles according to which digitalization is to take place – and they set the limits of implementation:

Goals of the Polish Digitization Strategy

The strategy translates the vision into measurable goals, most of which have target values ​​set for 2035. The most important of them:

Schedule of the Polish Digitization Strategy

The strategy spreads the goals over time, from the most urgent institutional changes in 2025-2026 to the target year of 2035. Key milestones resulting from the indicator table:

The strategy is multi-annual, therefore it provides for a permanent management cycle, i.e. review of the document every 2 years and monitoring once a year, with a report to the Committee for Digitization and publication on the website of the Ministry of Digitization.

Summary

The State Digitization Strategy until 2035 combines Poland’s digital development into one measurable plan for the first time, in which cybersecurity is one of the four foundations determining the success of the rest.

For security teams, this is not an announcement of specific changes: a central cybersecurity institution based on PCOC, mandatory sector CSIRTs, a mechanism for identifying and limiting high-risk suppliers, a national migration plan to post-quantum cryptography and linking IT projects with the State Information Architecture.

These directions become binding through related regulations, primarily amendment of the Act on the KSC implementing the NIS2 directive and the Act on the National Certification System cybersecurity. The sooner the organization translates the provisions of the Strategy into its own map of responsibilities, the lower the risk that adaptation to new requirements will become an emergency action instead of a planned one.

The National Cybersecurity System (KSC) is a system of institutions, regulations and procedures designed to protect Poland against threats in cyberspace. Its principles are specified in the Act on the National Cybersecurity System, and from April 3, 2026, its extensive amendment – KSC 2.0 – is in force.

The new regulations implement the EU NIS2 directive and replace the existing regulations in force since August 2018. Work on the draft amendment to the Act was carried out by the Ministry of Digitization, and the result is the expansion of the system to include new sectors of the economy and a number of obligations for thousands of companies and institutions. Covered entities must, among other things, register in the KSC List, i.e. the official list of key and important entities, and implement an information security management system (ISMS). Negligence may result in severe financial penalties.

What is the National Cybersecurity System?

The National Cybersecurity System (KSC) includes all entities responsible for the security of networks and IT systems in Poland: from state institutions, through specialized incident response teams, to companies and offices providing services important to the economy. Its goal is to ensure the continuity of operation of key services and quick response to cyber threats.

The legal basis of the system is the Act on the National Cybersecurity System, adopted in 2018 andthoroughly amended in 2026. The work on the draft amendment to the Act resulted from two reasons:

  1. Necessity to implement the EU NIS2 directive, which increased the requirements for member states.
  2. Growing scale of threats in cyberspace for which existing regulations are no longer sufficient.

The new regulations change the system in three main areas: they expand the catalog of companies and institutions covered by the act, specify their obligations for risk management and introduce real sanctions for non-compliance.

Is it possible to implement KSC in a week?

Sign up for a free webinar!

Who does the new regulations apply to? Key entities and important entities

The amendment to the KSC organizes the scope of entities covered by the Act into two categories: key entities and important entities. The affiliation is determined by a combination of two criteria: the sector of activity (indicated in the annexes to the Act) and thesize of the organization, calculated taking into account affiliated and partner companies.

Key entity and important entity

Key entities are organizations whose disruption would have the most serious consequences for the state and the economy, for example in energy, banking, health care, transport or digital infrastructure. This also includes the current key service operators who already operated under the old act. Important entities includeother industries added by the amendmentwhere the incident is serious but less severe on a national scale. This division translates into the intensity of supervision: key entities are subject to stricter control than important entities.

What industries and entities are covered by the act?

The amendment to the KSC has significantly expanded the catalog of industries covered by the national cybersecurity system.

In addition to energy, finance and health care, the act now covers, among others, waste management, production and distribution of food and chemicals, postal services, the space sector and the management of ICT services.

The Act does not distinguish between the private and public sectors, the obligations cover both.

On the state side there are public administration entities and local government entities covered by the Act, including municipal offices acting as a public sector entity. On the market side, the act covers production and service companies as well as digital service providers.

All these organizations have one principle in common: self-identification. The entity itself assesses whether it meets the sector and size criteria and then reports without waiting for the office’s decision. If the business profile indicates the status of a key or important entity, the obligation to register arises automatically.

What obligations does KSC impose?

Key entities are obliged to implement a coherent system for protecting their networks and IT systems, and important entities implement the same statutory requirements to a slightly lesser extent.

The essence of the responsibilities of key entities isthe implementation of an information security management system (ISMS), i.e. a set of policies, procedures and safeguards that the organization applies, documents and regularly updates.

This system consists of several pillars:

These are selected pillars of a broader catalog of measures required by the KSC Act. The full scope additionally includes, among others: cryptography and communication security, security monitoring and testing, vulnerability handling, and physical and personnel security.

Incident reporting and the role of CSIRTs

In addition to preventive protection, statutory obligations includeincident reporting. Each entity must maintain incident handling procedures and report serious incidents to the appropriate CSIRT team within specified deadlines.

CSIRTs are computer security incident response teams. There are three national-level teams in Poland, of which the greatest role towards companies and local governments is played by CSIRT NASK. The amendment expanded their competences and added the possibility of creating sector-specific CSIRTs supporting entities in specific industries. Reporting an incident to CSIRT triggers support in analyzing the incident and mitigating its effects, and the CSIRT team can also warn other entities about the associated threat.

How to enter the KSC List?

Each key and important entity, after self-identification, must register in the official register. KSC List is a list of key and important entities maintained by the Ministry of Digitization, based on which the state knows who is responsible for the provision of key services and who is subject to the supervision obligation.

The Act provides for two modes of entry of an entity:

  1. Some organizations are entered into the register ex officio, i.e. on the initiative of the minister. This applies primarily to public entities, telecommunications undertakings, trust service providers and former operators of key services previously included in the list of key services.
  2. Other entities, mainly private ones, submit applications independently.

Self-registration takes place as online registration in the Wykaz KSC application. Login takes place via the National Node, i.e. a trusted profile, e-ID, electronic banking or qualified electronic signature. The application is submitted and signed by the entity’s manager or a person authorized by him. After the entry, the entity connects to the S46 system, a central channel for the exchange of information and threat warnings, acting as a digital cyber hub of the national system.

The most important date is October 3, 2026. By this date, newly covered entities must self-identify and submit an application for entry.
Jerzy Muszyński, Legal Advisor to SECAWA

The full list of entities obliged to register results from the annexes to the Act and size criteria.

How to self-identify?

Self-identification involves checking on your own whether your organization is subject to the Act and assigning yourself to the appropriate category. The Ministry of Digitization describes it in three steps, based onArt. 5 and Annexes No. 1 and No. 2 to the Act

After this analysis, the entity determines one of three results: it is a key entity, it is an important entity or it is not subject to the Act. The first two answers result in the obligation to enter the KSC List.

Manager’s liability and penalties for violations – KSC

KSC 2.0 moves responsibility for cybersecurity to the very top of the organization. It is the entity’s manager, i.e. the management board, director or commune head, who is personally responsible for the implementation of statutory obligations. He must approve the risk analysis and selection of security measures, provide a budget for them and undergo cybersecurity training himself. Delegating tasks to the IT department does not relieve it of this responsibility.

The implementation of obligations is verified by an audit. The first ISMS audit must be carried out by the key entity within 24 months of being covered by the Act, i.e. no later than April 3, 2028, and subsequent audits at least every three years. The audit checks whether the information security management system works in practice, and not just on paper.

Prepare your organization for KSC

Arrange an ISMS Audit

Failure to fulfill obligations is subject to sanctions for violations in two dimensions.

  1. An organization may be subject to administrative fines for, among other things, failure to implement an ISMS or failure to register on the list.
  2. Separate fines apply to the manager and may reach the equivalent of 100% of his remuneration. However, the timing is important: penalties for most administrative obligations can be imposed only after April 3, 2028, which gives entities time to adapt.

Summary

The National Cybersecurity System, after the amendment of April 3, 2026, covers a much wider range of organizations than before and divides them into key entities and important entities. Each company and institution from the covered sectors must check its own status (self-identification), enter the KSC List by October 3, 2026, implement an information security management system (ISMS) and report incidents to the CSIRT teams. Responsibility for these obligations rests personally with the entity’s manager, and from April 3, 2028, failure to comply with them may result in real financial penalties.

The earlier an organization starts preparations, the easier it will be to meet the requirements of the Act without rushing and risking sanctions. A good starting point is a SECAWA ISMS audit. Together with our legal advisor Jerzy Muszyński we join ISMS legal audit and qualification of the entity under the Act with a technical cybersecurity audit, thanks to which you will receive a full picture of legal and technical gaps and a clear report with recommendations and action priorities, which will also serve as evidence of due diligence during inspections by the supervisory authority.

Today, security teams operate under pressure that would have been hard to imagine just a few years ago. All the more so because this pressure is growing from several sides at the same time: staff shortages, regulatory changes, GenAI, the growing number of security incidents and increasingly complex digital threats have meant that cybersecurity has long ceased to be exclusively a technical area.

Today is a test of the resilience of the entire organization. This is also confirmed by legal regulations that require companies not only to implement appropriate protection measures against cyber threats, but also to demonstrate due diligence in information security, risk management and security awareness training.

But how to cover all these areas if internal security teams lack people, time and operational space for subsequent tasks?

Why are security teams under so much pressure today?

Security teams are under pressure today because the number of responsibilities is growing faster than available resources, budgets and competencies. CISO must also be responsible for detecting threats, managing security incidents, regulatory compliance, building and developing the information security system, and preparing the organization for increasingly sophisticated cyberattacks.

Gartner indicates that the current cybersecurity landscape is influenced by, among others: chronic talent shortages, regulatory changes, GenAI and constantly changing digital threats. Each of these factors separately increases the level of difficulty. Together they create an environment in which the activities of the security team increasingly require not only technical knowledge, but also operational resilience, efficient prioritization and reporting of effects to the management.

Cybersecurity data clearly shows the scale of the burden on security teams:

Source: ISACA, State of Cybersecurity 2025 – Europe, 2025.

Security teams have less space for preventive activities, analyzing trends, updating procedures and systematically strengthening information security.

For CISO the consequence is concrete: the growing number of incidents and cyber threats does not allow us to postpone actions “for later”, but an overloaded team does not always have the resources to conduct every project internally. This also applies to educational programs, phishing tests and Security Awareness which require regularity, updating of scenarios and measuring employee reactions.

The pressure is therefore double. On the one hand, organizations must improve security, meet regulatory requirements and document due diligence. On the other hand, teams responsible for cybersecurity in Poland and Europe operate in conditions of staff shortages, growing expectations and an increasingly complex attack landscape.

This is why CISOs increasingly need to ask: “what should we implement?” as well as: “who will maintain, measure and report on it throughout the year?”

Staff shortages in cybersecurity – what do the statistics say?

Staff shortages in cybersecurity are no longer a recruitment problem that can be solved with another recruitment. This is a factor that directly affects the organization’s digital security, the pace of response to cyber threats and the ability to maintain continuous preventive activities.

According to ISACA data:

At the same time, IBM indicates that 48% of organizations face a high level of security competence deficiency.

In practice, this means that the security team’s activities increasingly have to be carried out in conditions of limited bandwidth. Often the same team is responsible for:

It is no wonder that with such a workload, security teams treat some elements of the cybersecurity strategy as an obligation to be ticked off, rather than a real priority.
Piotr Kaźmierzak, CEO of SECAWA

The problem is also exacerbated by the recruitment time. ISACA indicates that in many organizations, employment for entry-level positions lasts from 3 to 6 months, and a similar time also applies to more advanced roles. This means that even if the CISO has an approved cybersecurity investment program, new competencies will not appear in the organization immediately. And remember that cybercrime, new attack techniques and the growing number of incidents do not wait until the recruitment process is completed.

Therefore, the information security system should be designed so that not every activity requires constant manual operation by an internal team. Especially where periodicity, measurability and reporting are important – as in Security Awareness programs, phishing tests or employee education in information security.

Staff shortages do not release the organization from responsibility for the level of safety. However, they mean that some processes need to be conducted differently: with less workload on the team, but maintaining data, reports and evidence of due diligence.
Piotr Kaźmierczak, CEO of SECAWA

Phishing and social engineering – current cybersecurity statistics

Phishing remains one of the most important risks because it hits people: rush, routine, trust in the sender and the pressure to react quickly. Even the latest security tools do not fully eliminate the risk that an employee will click on a link, open an attachment or provide data on a fake website.

Cybersecurity data that shows the scale of the problem is

These numbers are important because they show that phishing is not a side topic in information security. It is a permanent element of the threat landscape that affects cybersecurity in Poland.

Read the summary of phishing statistics from the CERT Polska 2025 report

Go to the article

Cybercriminals are increasingly using scenarios that look like a regular part of the working day: a message from a courier, an alert from the system, a request from the finance department, a message from a public institution or a link to a document. That’s why phishing requires not only email filters and security tools, but also regular monitoring of how employees react to realistic manipulation attempts.

In such a model, specific data becomes crucial:

Without this information, it is difficult to assess whether the organization actually reduces the risk of information security incidents or only formally implements educational activities.

An effective Security Awareness program is no longer just a regulatory requirement, but an urgent necessity

An effective Security Awareness program is no longer just a regulatory requirement, but an urgent necessity for every organization that wants to actually reduce the risk of a security incident and build a multi-layer defense against phishing, smishing, vishing and other manipulation techniques.

Technology alone is not enough. Email filters, EDR, MFA and response procedures are necessary, but they cannot replace an employee who can recognize a suspicious message, stop before clicking and report an attack attempt with one simple action.

The problem is that ensuring such a program requires constant work by the security team. It’s not just about purchasing a platform or conducting one pre-audit training. The full program means:

With staff shortages and an increasing number of incidents, it’s easy to understand why Security Awareness is sometimes treated as a chore to check off. Meanwhile, a poorly run program does not provide CISOs with hard data on employee behavior, does not strengthen the reporting of suspicious messages and does not help demonstrate due diligence in information security.

Not every organization has the people, time and resources to maintain a Security Awareness program on its own. However, the audit will not wait. Also the regulator. Attacker? The more.
Piotr Kaźmierczak, CEO of SECAWA

Practical SECAWA Anti-Phishing Training – a measurable program without adding work to the security team

Practical SECAWA Anti-phishing Training is a long-term Security Awareness program based on realistic simulations of cyberattacks, condensing education at the moment of a mishap and measuring employees’ reactions. It is not another platform for self-service, but a service in which SECAWA team takes over responsibility for the implementation of training – from scenarios, through campaigns, to analysis of results and reports.

Polish capital that understands the local threat landscape

SECAWA has been developing its own methodology for over 7 years, cooperating with the state administration and the enterprise sector. As a result, the training stays grounded in the realities of the market – it takes into account cybersecurity in Poland, local phishing scenarios, regulatory requirements and the way Polish organizations operate.

This is important because effective Security Awareness cannot be based solely on universal templates. Employees have to deal with cyberattacks that resemble real fraud attempts: communication from public institutions, suppliers, courier companies, payment systems and internal company processes.

Training that does not require your organization’s resources

SECAWA takes full responsibility for conducting the training:

The client’s side has a maximum of 3 hours per month to accept ready-made materials and schedules. This is especially important where the security team’s activities are already burdened with alerting, compliance, audits and security incident management.

PTA allows you to maintain a continuous educational program without shifting further tasks to the internal team. The CISO retains control over the course of action and effects, but does not have to build the entire training from scratch.
Piotr Kaźmierczak, CEO of SECAWA

Measurable effects and ready reports

Practical Anti-Phishing Training is based on data, not declarations. The platform measures real employee reactions to simulated attacks and shows whether the organization is actually strengthening its resistance to phishing.

The dashboard includes:

This is cybersecurity data that can be used not only to plan subsequent campaigns, but also for conversations with the management board, auditors and supervisory authorities. Ready-made reports help demonstrate that the organization not only conducts educational activities, but actually monitors their effectiveness.

In the PTA model, the goal is not just to “train employees”, administer a single knowledge test, and provide certificates of completion. The goal is a real change in behavior: fewer clicks, more reports and faster response to suspicious messages.

Employee data under control and GDPR compliance

The Security Awareness program must strengthen information security, not create new risks related to data processing. Therefore, in PTA it is important to control where employee data goes, how it is processed and who has access to it.

Our proprietary SECAWA training platform operates on infrastructure located in the European Union, which supports compliance with GDPR and personal data protection requirements. SECAWA has full control over product development and data processing, without transferring this responsibility to intermediaries outside the EU.

For organizations subject to regulations, security audits and information security management requirements, this is an important element of the entire program. Security Awareness cannot be achieved at the expense of data control.

SaaS or on-premise – two implementation models and full functionality in both

Practical Anti-Phishing Training can work in the SaaS or on-premise model. The organization chooses a variant that is consistent with its own infrastructure, security policy and regulatory requirements.

The SaaS model allows you to quickly launch training without interfering with the client’s environment. The on-premise model works well where the priority is full control over the environment, data and integration with internal procedures.

In both variants, the organization benefits from the full functionality of the solution and ongoing updates. This is important because cybercrime is constantly changing its operating techniques, and training scenarios must keep up with the development of digital threats.

Free Phishing Test – check your team’s resistance without costs or obligations

Free Phishing Test allows you to check how employees react to a realistic attack attempt before the organization decides on a full Security Awareness program. It’s a low barrier to entry: no cost, no obligation, and no burden on your security team.

As part of the test, SECAWA conducts a simulation of a cyber attack on a selected group of employees. This allows the organization to see specific behaviors:

What does a CISO gain after a phishing test?

After the phishing test, the CISO receives data that helps assess the real level of employee security against phishing. This is a practical starting point for deciding whether the organization needs a full training program, how intense the training should be and what scenarios it is worth building resistance to first.

Free Phishing Test also gives access to the SECAWA’s proprietary training platform. It allows you to check whether the method of conducting simulations, reporting and education after an incident fits the culture of the organization, the requirements of the security team and the expectations of the management board.

If cybersecurity in Poland today is faced with a growing number of incidents, and phishing remains one of the most frequently handled cybersecurity incidents, it is worth starting by checking your own resilience.

Schedule a Free Phishing Test and see how your team reacts to a realistic attack attempt – without adding work to the security department.

Schedule a Free Phishing Test and see how your team reacts to a realistic attack attempt – without adding work to the security department.

Schedule a completely free phishing test

The CERT Polska 2025 report clearly shows that computer fraud dominates in Poland today, and its most common form remains phishing. For CISOs and security teams, this is a clear signal that educational programs should focus on practical preparation of employees to recognize and report such attacks – for example, using personalized phishing simulations. Especially since phishing messages are increasingly unlikely to resemble a primitive attempt at fraud. On the contrary – they do not have typical errors, are more credible and well suited to the context and role of the recipient.

The schemes most frequently described by CERT Polska include campaigns impersonating tax refunds, undelivered parcels, correspondence from websites in the gov.pl domain, social benefits and e-TOLL fees. The report also shows that many of these campaigns were multi-step, combining email or text messages with time pressure, a fake phishing site, or an attempt to trick the victim into making a phone call and installing malware.

There is no doubt that artificial intelligence is driving increasingly sophisticated cyberattacks. We showed how cybercriminals use AI to scale, authenticate and automate attacks during our free AI vs Cybersecurity webinar series. The series has ended, but access to the recordings and materials is still available here.

A series of AI vs Cybersecurity webinars for CISOs
How does AI affect cyber threats and how to use artificial intelligence as an element of a security strategy?

Get access to recordings and materials

Social engineering attacks in Poland – key statistics from the CERT Polska 2025 report

What is CERT Polska and what does it do?

CERT Polska is the country’s first cybersecurity incident response team. It has been operating within NASK structures since 1996, and in 2026 it will celebrate its 30th anniversary. This team has been monitoring threats on the Polish Internet for years, handling reports and publishing reports that clearly show what the incident landscape in Poland really looks like.

In practice, CERT Polska deals primarily with:

CERT Polska also carries out some of the tasks of CSIRT NASK in accordance with the Act on the national cybersecurity system (KSC). It handles incidents reported by public institutions, digital service providers, companies and individuals.

Phishing and computer fraud – statistics of cyber threats in Poland in 2025

Size of the problem: computer fraud was the main category of security incidents

In 2025, computer fraud dominated the landscape of incidents in Poland. The CERT Polska team registered260,783 security incidents, and 253,238 of them were classified as computer fraud. This means 97% of all events handled. CERT itself also recorded growth in this category by 158% year-on-year, which clearly shows that we are not talking about a temporary jump, but about a lasting trend.

Number of phishing attacks in 2025

Phishing was the most frequently recorded type of computer fraud. According to CERT Polska‘s report, 78,391 phishing incidents were recorded in 2025. This is 30% of all registered events, which shows that phishing remains one of the most important mechanisms used by cybercriminals to extort confidential data and, in many scenarios, also to gain access to victims’ money.

What brands and scenarios were most often used in phishing campaigns?

The more recognizable the website and the more natural the context of the message, the greater the chance that the user will react without thorough verification. The most frequently observed phishing campaigns concerned unauthorized use of the image of OLX – 28,462 events and Allegro – 22,513 events. Attempts to obtain credentials for electronic mailboxes also constituted a separate category – 2,519 events.

Smishing still an important fraud channel

SMS remains an important channel used in social engineering fraud in 2025. The CERT Polska team received 295,169 reports of suspicious SMS messages, and the report indicates that most visits to phishing websites occur within 15 minutes of receiving the message. This shows how strongly this type of campaigns use the speed of reaction and impulsive actions of recipients.

The number of blocks shows that phishing was operating on a massive scale

In 2025, almost 245,000 were added to the CERT Polska Warning List. domains. The report also indicates that the list was downloaded almost 1.3 billion times, as a result, approximately 141.1 million visits to dangerous websites were blocked. Additionally, in the SMS area, 790 patterns led to blocking of 1,883,610 malicious messages.

Data from the CERT Polska report show that organizations should treat resistance to social engineering as a permanent element of their security strategy, not a one-off educational campaign. Technological security alone is not enough. Organizations needregular phishing teststhat show employees’ actual vulnerability to cyberattacks, and asimple process for reporting suspicious messagesthat speeds up the response and helps block the threat. This is especially important in the environment of increasingly greater legal and regulatory requirements, such as the AI ​​Act, KSC 2.0, GDPR, DORA or NIS2.

At SECAWA, we have provided these needs in one service – Practical Anti-Phishing Training, which combines education in a controlled environment, measurable results for the management board or auditors and convenient incident reporting. It is an original platform for simulating cyberattacks (including phishing, smishing, quishing, and soon also Microsoft Teams simulations and vishing integrated with AI) fully operated by our team. As a result, Polish organizations can strengthen their cybersecurity resilience without burdening resources, but also meet regulatory requirements such as AI Act, KSC 2.0, GDPR, DORA or NIS2 for security awareness.

Learn about your team’s resistance to phishing and see how our cyberattack simulation platform works – without costs or obligations!

Schedule a Free Phishing Test

The most frequently observed social engineering campaigns in Poland in 2025

According to the CERT Polska report, fraudsters most often used in 2025 scenarios based on trust in well-known institutions and everyday services. Campaigns aimed at taking over passwords to email boxes and social media accounts, as well as fake websites pretending to be state services and courier companies, especially Poczta Polska and InPost, were particularly common.

Tax refund: e-Tax Office and KAS

The fraudsters sent messages about an alleged refund awaiting approval, using the image of the Ministry of Finance and the style of official correspondence. The goal was not just to click, but to guide the victim through the entire extortion process – from entering a crafted website to providing electronic banking and payment card details.

Undelivered parcels: InPost, Poczta Polska, e-Delivery

A classic example of a campaign that works because it fits well into the user’s everyday context. CERT Polska describes both email messages with attachments installing malware and SMS messages directing to fake websites used to extort personal data and payment card details. Importantly, the report also draws attention to variants that bypass the phone’s security – e.g. by persuading the user to reply to a message, which makes it easier to activate the link.

Official matters: services in the gov.pl domain

Fraudsters sent messages about new official correspondence, account activity or logging in from an unknown device. In this scenario, the message was often just the first step. The next step was to persuade the recipient to contact him by phone and then – during the conversation – convince him to install a tool enabling remote access to the computer (vishing).

Verification of entitlement to social benefits

A pattern in which an advertisement or message directed the user to a false website stylized as gov.pl, and then to a form impersonating a payment operator. This example shows that a cyber attack does not have to start with an email – it can equally effectively use advertising, a simple form and a financial context that is natural to the user.

e-TOLL fee

In 2025, CERT also observed campaigns using the motif of unpaid toll. This scenario was based on time pressure and the risk of financial consequences. The attack was two-stage: first, personal data was extorted, including ID number, and then payment card details.

Statistical Office and malicious attachment

The CERT Polska report also describes campaigns impersonating the Statistical Office in Warsaw. In this case,social engineering was a carrier for malware. The message looked legitimate, contained formal content and a detailed footer, and the attachment led to the launch of RAT-type software. This could result in both stealing saved passwords and taking control of the victim’s device.

False investments in social media

One of the most financially painful scenarios was investment fraud. Fraudsters registered fake investment websites en masse and often used the images of public figures or well-known brands. The mechanism was not based solely on the promise of profit. Falsified charts, time pressure and the victim’s belief that they were dealing with a limited opportunity with minimal risk also played a role.

NFZ and reimbursement of drug purchase costs

The criminals impersonated the National Health Fund and informed about the possibility of recovering the costs of purchasing medicines. The user was directed to a website used to steal personal data and passwords. There is an important psychological element here: short deadlines for receiving funds, which were intended to limit the time for reflection and verification of the message.

Refund of overpayment for electricity

The report also describes campaigns impersonating electricity suppliers. Their effectiveness resulted from the combination of a current topic – energy costs – with a very refined form. The messages were written in correct Polish, maintained a formal style and faithfully reproduced the appearance of legal websites of energy operators. The conclusion is simple: modern phishing, which is often supported by AI, is no longer revealed by simple linguistic errors.

What do these social engineering campaigns have in common?

Although they differ in subject matter, their mechanism usually remains similar: first build credibility, then add time pressure and embed the message in a situation that will seem familiar to the recipient. The authority of institutions or services present in users’ everyday lives was particularly often used because it increases the chance of clicking, providing data or performing other risky actions.

Therefore, organizations should regularlypractice safe responses to scenarios based on real threats from the Polish Internet. As part of Practical Anti-Phishing Training, we prepare campaigns tailored to the specificity of a given company, processes, tools used, positions and industry, so that our phishing simulations best replicate attacks that may be aimed at employees.

Practical Anti-Phishing Training: realistic simulations of cyberattacks, measurable training effects and ready-made reports for the management board and auditors

Find out more about the platform

Security incidents in Poland in 2025

The most important incidents described in the CERT Polska 2025 report show that an effective attack is less and less based on one channel and one user error. Increasingly, we are seeing the entire chain of activities: phishing, account takeover, use of legal login mechanisms, extortion of data about specific people or further use of leaked data.

For CISOs, this means that the organization must simultaneously practice recognizing suspicious messages, build resistance to multi-stage and multi-channel attacks, and provide the team with clear response procedures that will allow the incident to be stopped before it develops further.

Selected incidents described in the CERT Polska 2025 report

Summary

The CERT Polska 2025 report very clearly shows the scale of phishing attacks in Poland – their number and level of refinement. The report covers more than phishing; it also includes a broader picture of threats: from mobile malware and ransomware to the activities of APT groups.

Importantly, CERT Polska does not limit itself to describing the problem, but actively helps to limit it – through the Warning List, blocking malicious SMS messages, the moje.cert.pl portal, the bezpiecznedane.gov.pl, number 8080 for reporting suspicious messages and current messages about campaigns and vulnerabilities.

LLM-based systems introduce a new operating model, but many security threats result from well-known risk patterns. What changes is not the target of the attack itself, but the way in which data, instructions, tools and permissions are combined in one flow. This is why prompt injection and other attacks on AI systems should not be analyzed solely as a problem of the model, but as a problem of the entire system architecture.

In practice, this means that the risk does not end with a malicious prompt, but can start with input data, go through context and RAG, use tools or integrations, and finally lead to abuse of privileges, data leakage or unauthorized actions.

For CISOs, it is not about a single vulnerability, but about layer-by-layer threat modeling.

The scale of the problem is serious: it can be said that 100% of AI systems are vulnerable to attacks because there is no fully effective method of defending against prompt injection today.
Piotr Kaźmierczak, CEO of SECAWA

Therefore, AI systems should be designed with the assumption that individual protections can be bypassed, and resilience must be built in multiple layers – at the level of input, context, RAG, tools, permissions, output and operational control.

How does communication with LLM (Large Language Model) work?

To model threats well in AI systems, you must first understand how such a system actually works.

From the user’s perspective, it looks simple: we ask a question and get an answer. In practice, however, the model does not work on a single sentence, but on the entire context provided to it by the application.

In its simplest terms, this flow includes system instruction, user input, model, and system response or action. This is where the main attack surface related to prompt injection also appears.

Language model messages and context

For a language model, context is everything it “knows” about the current interaction. It includes not only the content of the user’s question, but also system instructions, previous messages, and in more complex architectures also external data and results of tool operation. It is a set of messages that are sent to the model only after being assembled. This is important because the model does not respond only to the last message – it works based on the entire context it receives from the application.

Question-answer

The simplest variant is the question-answer architecture. The system passes a system instruction and one user message to the model and then receives the response.

This flow looks the cleanest, but already at this level the basic security logic is visible: the model responds to what is in the context, not to the intention of the system designer. Therefore, even a simple chatbot is not just a conversation interface, but a system whose behavior depends on how the input context was built.

Conversation

The situation becomes more complicated when we move to multi-turn conversations. Then, not only the user’s new question is added to the context, but also the model’s previous answers and conversation history

From a functionality point of view, this is natural – the system should “remember” what the conversation was about.

From a security point of view, however, this means thateach subsequent invocation of the model relies on an increasingly broader set of contentthat can influence the response logic. The longer and richer the conversation, the more important is what exactly is recorded in the context.

RAG

The next level is RAG, i.e. enriching the context with external sources of knowledge. The context window may receive documents, database records, website content or other materials that are intended to help the model provide a more complete response.

This allows you to connect the model with organizational knowledge or external data. However, from a security perspective, this means that the model begins to receive content outside the direct conversation with the user – and therefore also content that may be erroneous, unverified or malicious

Use tools

The most extensive variant is an AI system in which the model not only responds, but also uses tools. In such a scenario, the model can first call a specific function, API or automation, and only then – after receiving the result – generate the final response. The result of the tool also returns to the context and influences the further course of the task.

This is a key moment from the CISO’s perspective, because the AI ​​system then ceases to be only a response layer and begins to have a real impact on data, processes and operations. The more tools, integrations and intermediate steps, the greater the risk surface.

This is why communication with the LLM model should not be reduced to a simple “question-answer” pattern. In practice, it is a flow in which context can be built from many sources, expanded with conversation history, fed with external data and supplemented with the results of tool operation. And if so, the security of the AI ​​system must be assessed not only at the model level, but also at the entire architecture that creates this context.

What is prompt injection?

Prompt injection is an attack involving the introduction of a specially prepared instruction that induces the AI ​​model to act in a manner inconsistent with its intended purpose. A malicious prompt does not have to “corrupt” the model itself – it just needs to influence how the model interprets the context and what actions it considers appropriate. This is why Prompt Injection attacks are today treated as the main attack surface in LLM-based systems.

This means that in the case of such an attack, the model receives not only the right question or task, but also an additional, malicious instruction that is supposed to change the way it works. If the system does not separate data from instructions well enough, the model may treat malicious content as a control instruction and respond or act contrary to the system designer’s intentions.

Effects of prompt injection

A prompt injection attack for an organization could mean:

We wrote more about prompt injection, types and consequences in this article: http://secawa.com/en/blog/prompt-injection-what-it-is-and-how-to-limit-the-risk/

How to model threats in AI systems?

For CISO the key question is not only whether the system is resistant to prompt injection, but how to assess the risk separately for each layer of the AI ​​system – from input and context, through RAG and tools, to permissions, output and operational control.

In practice, modeling threats in AI systems is worth dividing into 7 areas: inputs, context, RAG, tools and integrations, permissions, output and telemetry and control.

01 Input

This is the first and most obvious area of ​​threat modeling. The following may be sent to the AI ​​system:

It is these entrances that the materials indicate as themain entry points for prompt injection. The problem is that the system does not always distinguish between regular content and malicious instructions. The more input sources and data formats there are, the greater the risk that a malicious prompt will be treated as part of the legitimate context.

02 Context

The second layer is the model context itself, i.e.:

This is where attempts to hijack the system’s operating logic or reveal hidden instructions occur. From a security perspective, this is critical because context manipulation can lead to a change in the system’s operating logic or the disclosure of model control instructions.

03 RAG

The next layer is RAG, a mechanism for enriching the model context with documents and data from the knowledge base. From an architectural perspective, this includes, among others: vector database, retriever and ranker.

In this layer, the main risks are data extraction, context manipulation and data poisoning. If the system retrieves content from documents, web pages, emails or other external sources, indirect prompt injection can occur without direct user interaction with the attacker.

04 Tools and integrations

When a model has access to APIs, functions, automation or MCP servers, it stops being just a response generation layer and begins to influence processes, data and activities performed outside the LLM itself.

This is where the risk of unauthorized actions and misuse of tools comes into play. Manipulating the prompt, context or task flow is enough for the AI ​​system to perform an operation it should not perform.

05 Permissions

This is one of the most important layers from a CISO perspective. The question is not only what the model has access to, but also whose permissions it operates under and what scope of access the connected tools have.

The key principle is simple: access control must operate beyond LLM, at the application level. If the system does not ensure this, the AI assistant may perform operations with a greater scope of permissions than it should, or launch actions to which the user would not normally have access.

06 Language model output

Threat modeling doesn’t end with input. Equally important is what the system returns next: responses, links, HTML, integrations and data passed to subsequent components.

This is important because the model’s response may be:

Therefore, the model output must be treated as an element of the attack surface, not just the final result.

07 Telemetry and control

The last layer is operational supervision of the AI ​​system – logs, limits, alerts, action approval and anomaly detection. This part does not block the attack itself, but gives the organization the ability to audit, detect abuse and respond quickly.

This is especially important where the system performs activities that are costly, sensitive or difficult to reverse. Without telemetry and control,an organization loses visibility into what the AI ​​system did, how it behaved when executing commands, and whether there were any abuses, anomalies, or costly operational impacts.

7 questions a CISO should start assessing the risk of AI systems

The resilience of the AI ​​system must be designed in many layers. Therefore, a good starting point is to go through the 7 layers of the AI ​​system and assess the risk separately for each of them – from input data and context, through RAG and tools, to permissions, output and operational control.

What can enter the system?

The first question is not about the model, but about input channels. The AI ​​system may receive not only user prompts, but also files, websites, emails and documents. This is where most successful attacks begin, because the model can treat untrusted data as an instruction. Therefore, the CISO should check which entries are filtered, whether entry screening works, whether prompt injection patterns are detected and whether the organization responds to repeated user abuse.

What goes into the model context?

The second question is: what exactly does the model see as context. Good practice is not about a “stronger system prompt”, but about separating data from instructions, clearly labeling what is a system command and what is user or document content, and minimizing the context provided to what is really needed to perform the task. The CISO should also assess whether the context contains secrets, sensitive configurations or unnecessary information that increases the risk of leakage.

What sources of knowledge enrich the answer?

With RAG, the key question is not only what the system uses, but also how it trusts these sources. Documents, web pages, PDFs, emails and comments may contain malicious instructions, so external sources must be treated as untrusted and RAG content filtered and flagged before being included in the context. From the CISO’s perspective, it is also important whether the system maintains control over permissions to source data, whether it segments repositories and whether it detects mass data extraction attempts.

What tools can the model invoke?

When an AI system uses APIs, functions or automation, a wrong answer can quickly become a costly operational failure. Therefore, the CISO should assess what tools the model can run, whether their use is validated before performing the action, whether the output returned by the tools is controlled and whether the model cannot independently skip required process steps. In practice, the security of this layer is based on validating calls, controlling the sequence of actions and limiting the scope of integration to the minimum necessary for a given task.

Whose permissions does the system run on?

This question often determines the scale of the incident. The CISO should determine whether the agent operates in the context of a user, application, or privileged backend, and whether authorization occursoutside the LLMat the application level. Good practices here are clear: all operations should be performed with user, not system, privileges, the scope of tools should be minimal, and the user, agent and backend identities should be separated. Without this, prompt injection may turn into privilege escalation and unauthorized operations.

What comes out of the model and where does it go next?

The model output is not just a response to the user. It is also a potential source of data leakage, another step of automation or an entrance for another system. Therefore, the CISO should verify that the organization controls model responses, detects attempts to disclose data in the output, limits the length of responses and the number of steps, and does not include secrets in prompts and context. In practice, quickly limiting the effects of exfiltration and cost abuse is as important as blocking an attack.

How does the organization log, control and test it?

The last question is whether the organization hasreal supervision over the AI ​​system after implementation. Checking once is not enough. Effective supervision should include system telemetry, alerts, logs, agent behavior monitoring, cost and token control, and regular testing of resistance to prompt injection and RAG attacks. It is also important to measure not only the effectiveness of blocking, but also the quality of the response – so that after implementing security measures, the system continues to operate correctly, accurately and predictably.

Summary

The security of AI systems cannot be assessed by a single test or a single defense prompt. In AI systems, risk arises throughout the entire flow – from input data, through context and RAG, to tools, permissions, output and the telemetry and control layer. Therefore, it is worth conducting risk assessment layer by layer, and not only at the level of the model itself.

From the CISO’s perspective, the most important conclusion is simple: there is no single, fully effective method of defense against prompt injection today. But this does not mean that organizations are helpless.

The resilience of AI systems must be designed in many layers – combining entry control, secure context building, limited trust in sources, validation beyond LLM, permissions control, monitoring and regular testing of resistance to real attack scenarios. Just as important as blocking an attack is limiting its effects and quickly detecting violations.

If you want to verify how your environment will handle attack scenarios in practice, it is worth basing it on controlled tests. At SECAWA, we conduct professional penetration tests, which help discover system vulnerabilities and then turn the results into specific recommendations for corrective actions. This will help prepare the organization for real cyberattacks and better protect data, reputation and business continuity.

Test your system security with controlled cyberattacks

Discover our penetration testing offer

AI is entering business processes faster than some organizations have built hard boundaries for it. Language models don’t just answer questions. They increasingly read documents, browse the web, summarize threads in instant messengers and launch actions through integrations (e.g. MCP – Model Context Protocol). This creates a new, semantic attack surface: prompt injection.

Prompt injection is a situation in which malicious instructions enter the LLM context – sometimes directly from the user (direct prompt injection), and in other cases hidden in external data that the system processes (indirect prompt injection). The effect can be simple, but expensive: the model does something it shouldn’t – it reveals information, manipulates the response or initiates actions that the architecture and permissions granted to it allow (e.g. via API/integration) – even though the user did not want it.

OWASP classifies prompt injection as the highest-ranked risk for LLM and GenAI applications. He also emphasizes something that is inconvenient, but crucial for CISO: due to the nature of generative AI There is no method today that provides a 100% guarantee of eliminating prompt injection – but the risk and effects can be significantly reduced.

In this article, we answer questions that really influence security decisions:

What is prompt injection? Definition

Prompt injection is a vulnerability in which content passed to the model (user prompt or external data attached to the context)changes the behavior or result of LLM in an unintended manner. It may lead to violation of system operation rules, generation of undesirable content, disclosure of information, gaining unauthorized access or initiating actions in connected systems – depending on the architecture and permissions.

Prompt injection occurs when input (regardless of form) influences the model so that it performs actions or generates responses that are contrary to the intended function of the system and trusted instructions (e.g. roles and constraints defined in the system/developer prompt). Importantly, a malicious command does not have to be human-readable – it just needs to go to the model context and be processed by it. Therefore, prompt injection applies not only to chats, but also to GenAI agents and applications that retrieve context from documents, websites, emails or repositories (e.g. in RAG architectures) – however, the use of RAG or fine-tuning alone does not eliminate this vulnerability.

In practice, prompt injection takes advantage of the fact that the model processes instructions and data in the same input stream (usually as text, and in multimodal systems also through other modalities), so untrusted content attached to the context (page fragment, search result, ticket, mail, document) may contain a command that the model will treat as an instruction. The more agency the system has (integrations, actions, permissions), the greater the potential impact.

Difference between prompt injection and jailbreaking

The two concepts are related and are used interchangeably, but they are not the same thing:

In short: every jailbreak is a form of prompt injection, but not every prompt injection is a jailbreak. In the context of enterprises and agents, what is particularly dangerous is that by injecting malicious prompts, the system may be induced to perform unauthorized actions or exfiltrate data – and the scale of the effects depends on the granted permissions and integration.

Types of prompt injection

Direct prompt injection

Direct prompt injection occurs when a malicious command hits the model directly in the content of the user’s prompt. This input could be:

The mechanics are simple: input provides content that the model incorrectly treats as an instruction, which can lead to bypassing constraints or performing actions that are contrary to the system’s intended function and trusted instructions and constraints.

Indirect prompt injection

Indirect prompt injection is more difficult to detect because malicious instructions do not come directly from the user. The attacker places them inexternal sourcesthat the GenAI system can process: websites, documents, emails, databases, metadata or even graphic files. Such injections can also be unintentional – if the external content contains instructions that the model will treat as commands.

This is where the most insidious element comes in: the user often cannot see the attacker’s prompt, and the tool can appear normal while executing hidden instructions “in the background”. Malicious instructions can be hidden, for example, in metadata, in invisible Unicode characters, or in formatting that is invisible to humans but readable by the model.

Indirect prompt injection particularly escalates the risk when:

In practice, this means that “data for analysis” also becomes a potential carrier of commands – also when these commands are not given directly in the text, but embedded in graphic material or another input channel.

Summary of the differences between direct prompt injection and indirect prompt injection

Direct prompt injectionIndirect prompt injection
Instruction sourceUser input going directly to the model.Instructions embedded in external content that the model retrieves and processes.
Visibility for the userPresent in prompts, sometimes visible, sometimes obfuscated, but still in the model’s input stream.Often invisible (metadata, hidden text, obfuscation, multimedia elements).
Typical surface attackInterfaces where the user provides a prompt (chat, form, command).WWW, documents, emails, instant messaging, repositories, DB records, images.
Differences between direct prompt injection and indirect injection

When is the impact greatest?
In both cases – when the system has access to data and the ability to launch actions through tools/integrations and extensive permissions.

What effects can a prompt injection attack have on an organization?

Data exfiltration

Prompt injection may lead to the disclosure or exfiltration of sensitive data – both that which the model “sees” in the context of the conversation (e.g. content of processed documents, fragments of the knowledge base) and that which the application has access to through connected tools and integrations.

In practice, the risk covers data that the GenAI system can read or download during the task: email content, documents, information about customers and employees, financial data or other confidential records – depending on what sources are connected and what permissions are granted. If the application has operational channels (e.g. sending messages, publishing content, API calls), exfiltration can occur quickly, without additional exploitation of vulnerabilities in target systems, using legal permissions and integrations available to the application/agents.

Content manipulation and bad business decisions

Prompt injection can lead to response manipulation: the model generates distorted content – it omits important information, reinforces incorrect or biased conclusions, or suggests actions that are inconsistent with the intended purpose of the system and trusted constraints.

In an organization, this is particularly dangerous where the model’s response supports decisions – in risk analysis, recommendations for teams, purchasing, legal or HR processes. Even if there is no data leak, there may be real business losses resulting from decisions made on the basis of a manipulated response.

Disclosure of information about the system and system instructions (system prompt)

Prompt injection attacks often aim to extract informationthat helps the attacker refine the next steps: system instructions, how the assistant works, as well as what tools and integrations are available. This speeds up the iteration of the attack and increases the chances of successfully bypassing security measures in a specific architecture.

It is worth emphasizing this directly: these threats are classified as one of the highest risks in the OWASP Top 10 for LLM applications (2025). In practice, the result is that the model – and often the entire LLM application – does not have a hard, reliable boundary between trusted instructions (from the developer/system) and untrusted input content (from the user or from external data). Because everything goes to one context and is processed through the “same channel”, a properly crafted input can prompt the system to reveal the system prompt, operating logic or information about available functions – exactly those elements that facilitate further escalation of the attack.

Abuse of tools available to the agent

Prompt injection may prompt the agent to select and invoke tools that are in his arsenal but should not be used in a given context (e.g. reaching for the “get customer data” function during a simple email summary).

This does not necessarily mean a classic escalation of privileges at the IAM layer – more often it is a violation of the boundaries of the context and purpose of the task: the agent uses the privileges it already has in an unauthorized way relative to the intended system function and security policies.

Unauthorized actions and changes to systems

When the agent has integration and the ability to perform actions, abuse of tools may result in real changes in systems: sending a message, modifying or deleting data, updating records, launching a workflow.

Another problem is that such actions may look like “normal” operations performed by an authorized entity – only they were triggered by a manipulated context, rather than by the intended purpose of the task and trusted system instructions.

Reconnaissance and preparation of further attack

Prompt injection can be used as a reconnaissance stage: determining what data sources the system processes, what tools it has, what limitations it has, how it responds to specific commands and whether it requires confirmation of the action.

Such reconnaissance helps prepare more targeted attacks – especially when the attacker has the ability to place malicious instructions in content that the organization regularly processes (e.g. documents, emails, websites or records in systems).

How to protect your organization against prompt injection attacks?

There is no approach today that provides a 100% guarantee of eliminating prompt injection – this is due to the generative nature of AI and the fact that in practice LLM systems process both trusted instructions (system/developer) and untrusted content (from the user or external data) in one context. Reliably distinguishing “instructions” from “data” and detecting malicious intent is not something that can be assured deterministically under all conditions today.

This does not mean, however, that we are defenseless.

The organization can significantly reduce the probability of a successful attack and – often more importantly – limit its effects by building layered protection: from employee security awareness, through governance and AI use policies, to technical security, permissions control, adversarial tests and monitoring the behavior of models, agents and their interactions with tools..

Increasing threat awareness among employees

Prompt injection is a semantic type of manipulation – so in practice it hits where employees use GenAI to work with content: summarizing emails, analyzing documents, summarizing instant messaging threads or asking to perform tasks in tools.

If the user does not understand that the LLM system processes both instructions and data in one context, it is easy to engage in risky behavior: pasting untrusted content into tools, asking agents for too broad actions (“do what it takes”), launching integration without thinking about the consequences and what data and actions the agent has access to.

Therefore, cybersecurity education should include not only general cyber hygiene, but also specific rules for safe work with GenAI – including awareness of the risks related to external content, integrations and the scope of commands given to agents.

At SECAWA we can provide various forms of education for all roles in the organization and management levels:

Contact us to discuss the best security awareness solution for your organization.

AI policies and governance

Prompt injection protection starts with rules that reduce the attack surface and limit the consequences when something goes wrong. In practice, there are four areas:

Visibility and control of GenAI (shadow AI) use

If an organization does not know what AI tools are used and for what (the Shadow AI phenomenon) – it is not able to manage the risk. Rules are needed that distinguish between permitted and non-permitted tools and define what data they can process and in what scenarios.

Principles of working with content sources

Indirect prompt injection is based on the fact that the model processes content from sources over which the organization does not have full control – or which may have been modified.

Therefore, it is worth determining what sources are considered trusted (allowlisting), when to use a precautionary approach and how to consistently treat content from the web, emails, documents, instant messengers or records in systems as untrusted input to the context.

Rules for formulating commands and scope of freedom of action

The more general the command and the greater the freedom of action, the easier it is to produce an undesirable effect. Governance AI should promote precise tasks, limited scope and clear criteria for what the model should do – and what it should not do (especially when working on external content and having access to tools).

Least privilege as default rule

If an agent has access to tools and data, they shouldonly receive the permissions necessary to perform a specific task – and nothing more. Conscious design of what an agent can see and what it can change or run in connected systems is key.

In practice, this means limiting access to sensitive resources, minimizing the scope of available functions, and clearly separating “read-only” operations from those that cause changes to systems. The fewer rights and fewer actions an agent has, the smaller the potential impact – even if a prompt injection occurs.

Technical inspections and monitoring

The technical layer has two goals: to make an effective attack more difficult and to quickly detect anomalies before they turn into an incident. The following actions are a practical synthesis of the key recommendations OWASP:

GoalWhat to implementWhat to measure/log
Limiting model behaviorReduce susceptibility to “shifting” the role and forcing actions out of scope.1. Precise system/developer prompt: role, scope, prohibitions, terms of use of tools.
2. The “task bounding” principle – the model is to implement only clearly defined types of tasks, without default initiative.
3. Clear rules for ignoring attempts to modify trusted instructions.		1. Model version + configuration version (e.g. hash/ID system prompt, tool policies).
2. Detection of override/jailbreak attempts (flags from the classifier/heuristics).
3. Out-of-scope response rate, denials and escalations to human.
Define and validate expected output formatLimit the possibility of unwanted content being “injected” into responses and enforce predictable results.1. Hard response schemas (JSON/schema, field lists, report format).
2. Deterministic validation on the application side (parser + rules).
3. “Fail closed” rules – if the validation fails, do not perform the action, do not propagate the result further.		1. Percentage of non-compliance with the scheme, reasons for rejections, retry count.
2. Cases of “schema drift” after prompt/tool changes.
3. Correlation: Format incompatibility ↔ unusual tool use.
I/O Filtering and ControlDetect and block risky content (including hidden instructions) and limit disclosures.1. Input and output filters (rules + classifiers) for categories of sensitive and typical prompt injection signals.
2. Disclosure control: redaction of secrets/PII, blocking “prompt leakage”.
3. For RAG: assessment of response quality (context relevance, grounding in sources, Q/A consistency) and rejections when the model drifts away.		1. Filter result: allow/block + categories + confidence.
2. RAG telemetry: which documents entered the context, scoring, rejections, source conflicts.
3. Redaction cases (what was redacted and why – without logging the secrets themselves).
Permission control and the principle of minimum permissionsEven if prompt injection is successful, limit the possible impact.1. Minimum scope of access to data and functions – per task and per agent.
2. Separating operations that do not change state from those that change state (and the latter – as narrowly as possible).
3. Tokens/credentials on the application side, not “in the model”; the model should not “have” secrets.		1. What permissions are active for a given session/task (policy ID).
2. Each use of the tool: who initiated it, what was the purpose of the task, what were the parameters (with redaction of sensitive values).
3. Attempts to use functions outside the permitted scope (policy violations)
Human confirmation for high-risk actionsBlock unauthorized actions that change the state of systems or reveal data.1. “Human-in-the-loop” for mutating and sensitive operations (sends, record modifications, deletions, publications, transfers, permission changes).
2. Verification of the context of the action: what was the basis for the decision, what sources provided the instructions.		1. Confirmation events: request → approve/deny, response time, action summary content.
2. Percentage of actions stopped by user or rules.
3. The most common types of actions requiring confirmation (for tuning policies).
Separation and marking external content as untrustedLimit the influence of external data on trusted instructions and decisions about the use of tools.1. Explicit “trust boundaries” in context: explicit separation of external content from system instructions.
2. Source policy: allowlisting, limiting domains/file types, precautionary principle for WWW and unverified content.
3. Content normalization/cleaning (e.g. removing hidden elements, metadata where it makes sense).		1. Context origin: sources, data types, acquisition path (Web/document/email etc.).
2. “Untrusted content” flags and detection of hidden/obfuscated elements.
3. The share of external content in context (volume, number of sources) vs. incidents/anomalies.
Adversarial testing and attack simulationsDetect vulnerable paths before the attacker does – and maintain resilience after changes.1. Regular direct and indirect prompt injection tests on real flows (RAG, emails, documents, WWW, tools).
2. Action scenarios: whether the agent can be tricked into unauthorized actions, disclosures, use of tools out of context.
3. Regressions after each change: prompts, tools, integrations, policies, data sources.		1. Test coverage (scenarios, source types, tool types), pass/fail results, bypass vectors.
2. Vulnerability trends over time (is it better/worse after implementations).
3. “Top failure modes” – the most common ways in which the model/agent fails the task.
Source: LLM01:2025 Prompt Injection OWASP

Prompt injection is a real attack vector against GenAI applications and agents based on language models. The risk increases wherever the system processes external context and has access to tools, integrations and sensitive data. Since there is no approach today that provides a 100% guarantee of eliminating prompt injection, a layered approach is crucial: raising awareness and rules for safe work with GenAI, AI policies and governance that limit the attack surface, and technical controls, tests and monitoring that reduce the effects and shorten the detection time.

The analysis of incidents reported to the President of the Personal Data Protection Office (PUODO) in 2025 paints a disturbing picture: over 22,400 reported personal data protection breaches are a signal that the current risk management models are becoming ineffective. Moreover, the CERT Polska team handled over 250,000 security incidents in 2025 (over 600,000 reports, of which approximately 250,000 were identified as incidents). This is more than twice as high as in 2024.

In the era of full implementation of the AI Act (Regulation on Artificial Intelligence) and the evolution of threats, cybersecurity is no longer the domain of IT departments and is becoming a key element of the legal responsibility of management boards.

Risk modeling in the light of Art. 15 AI Act

Although many organizations use AI systems that do not qualify as high-risk systems, it isArt. 15 AI Actsets today the standards of “due diligence” in risk analysis. According to this provision, systems should be resistant to:

In legal practice, we increasingly recommend the use of the Art. 15 AI Act framework as an element of a data protection impact assessment (DPIA). The 2025 incidents showed that the unauthorized use of intelligent assistants to transcribe meetings without participants’ consent is not only a violation of privacy, but a potential legal tort. 

Identity as a legal parameter (Art. 32 GDPR)

The statistics are ruthless: 1/3 of breaches last year resulted from credential compromise. From the point of view of the data controller (ADO), the failure to implement multi-factor authentication (MFA) in 2025 may be interpreted as afailure to comply with the obligation to implement appropriate technical measuresin accordance with Art. 32 of the GDPR. 

The example of a doctor impersonated in order to obtain prescriptions for opioids shows that the legal consequences of a violation go beyond administrative fines – civil liability for personal injury is involved. 

AI Act checklist for CISOs for 2026:
High-risk AI systems

Download the free checklist

Security by Design – from code to compliance

“Security is not a function, but a consequence of decisions made when writing code.” This statement is strongly supported by thePrivacy by Designprinciple (Art. 25 GDPR). More than 75% of IT incidents that constituted data breaches resulted from application errors (e.g. SQL Injection). For a lawyer, this means that a compliance audit must include not only documentation (policies, registers), but also verification of software development processes and regular code reviews. 

HR verification challenges: NIS-2 and UKSC

The amendment to the Act on the National Cybersecurity System (UKSC) and theNIS-2guidelines introduce new rigors for personnel verification. It is worth paying attention to Implementing Regulation 2024/20690, which in point 10.2 suggests verifying the background of employees in certain cases. 

However, there is an important coincidence with labor law. The Provincial Administrative Court’s judgment (II SA/Wa 190/22) sets the limits of the admissibility of monitoring employees’ activity on social media. Administrators must balance the obligation to ensure security and protect employee privacy. 

Summary

2025 proved that “it doesn’t take a big hole to sink a ship – just one that no one knows about.” Effective data protection in 2026 requires abandoning “paper compliance” in favor of real vulnerability management and incorporating cybersecurity into the organization’s KPI structure. 

Jerzy Muszyński