Introduction
Poland’s implementation of NIS2 has applied since 3 April 2026. It carries a definition that describes what every maintenance shop does: installation, operation and upkeep of information systems, delivered remotely. Below is what the statute says, quoted directly, with the places it does not settle marked as such.
This is a Polish act. If you are based elsewhere, your own country has its own law implementing the same directive, and this text does not cover it. Read this one if you serve clients in Poland, or if you want to see what a supply chain obligation looks like once a directive becomes a national statute with numbers in it.
In short
- Act of 23 January 2026, Journal of Laws 2026 item 252, published 2 March, in force since 3 April 2026 under article 49.
- The definition of a managed service provider covers support and administration “on site or remotely”.
- The ICT service management sector sits in annex 1, among the key sectors.
- That same sector lists two distinct entity types, and the difference between them decides the size threshold.
- For a managed security service provider the threshold starts at the small enterprise level, not the medium one.
- Deadlines run from the moment criteria are met, not from one calendar date, so this is not a countdown piece.
- This is not legal advice. It is a reading of the statute, with the boundary of that reading marked.
Three dates in circulation, one that governs
Collecting the deadlines for this article, I found three different entry-into-force dates for the same act. Search results and industry portals said 3 April 2026, the European legal register said 3 April, and one summary of a ministry notice said 10 April.
The text settles it. The final provision of the amending act reads:
Article 49. The act enters into force one month after the day of publication.
Publication was 2 March 2026, the month runs out on 2 April, so the act applies from 3 April 2026. One line settles what three versions were circulating about.
I mention it because every deadline below is counted from that date. Take the date from the notice and each one shifts by a week. It also gives you a quick test for any other article about this act: check whether the author cites an article number or only a date.
What the act says about providers
The amendment introduces two definitions worth reading verbatim, because the difference between them drives everything that follows.
The first:
managed service provider means a natural person, legal person or organisational unit without legal personality supplying services connected with the installation, operation or maintenance of ICT products, ICT services, ICT processes or information systems, through support or active administration carried out at the customer’s premises or remotely
The second:
managed security service provider means (…) an entity supplying services consisting in carrying out, or supporting the carrying out of, activities related to cybersecurity risk management, including incident handling and security testing
The first describes maintenance. Core and plugin updates, backups, server configuration, deployments, being on call when something breaks: the content of an ordinary maintenance contract. The word “remotely” is right there in the text, so the argument that you never touch the client’s physical infrastructure does not change how the activity is classified.
The second describes something else: risk management, incident handling, security testing. These are sold as a separate competence, not as technical upkeep.
Two entity types inside one sector
In annex 1, the ICT service management sector has two rows in the entity-type column: managed service provider and managed security service provider. That is not a repetition but two separate categories.
I checked where the sector sits, because that determines whether it belongs to the key or the important tier. Annex 1 begins on page 87 of the Journal of Laws text, annex 2 on page 96, and ICT service management appears on page 94. It therefore sits in annex 1, among the key sectors, next to energy, transport and banking.
Being in annex 1 does not by itself mean an entity is covered, because size decides that. It does mean the topic cannot be dismissed with “not our industry”.
The size thresholds, verbatim
The act does not define size itself. It refers to annex I of Commission Regulation 651/2014/EU, which says:
- The category of micro, small and medium-sized enterprises (“SMEs”) is made up of enterprises which employ fewer than 250 persons and which have an annual turnover not exceeding EUR 50 million, and/or an annual balance sheet total not exceeding EUR 43 million.
- Within the SME category, a small enterprise is defined as an enterprise which employs fewer than 50 persons and whose annual turnover and/or annual balance sheet total does not exceed EUR 10 million.
- Within the SME category, a microenterprise is defined as an enterprise which employs fewer than 10 persons and whose annual turnover and/or annual balance sheet total does not exceed EUR 2 million.
Two details from the same annex save you from a hasty conclusion.
Headcount is measured in annual work units, not names on a payroll. People working part-time or part of the year count as a fraction.
And article 4(2) says a single year over the threshold changes nothing:
the enterprise will only lose or acquire the status of medium-sized, small or microenterprise if this occurs over two consecutive accounting periods
One good year does not move a company into another bracket. Two in a row do.
Why the security threshold sits lower
Here is the part that is easy to miss on a quick read. Article 5 sets different thresholds for different rows of the annex.
The general rule for an annex 1 entity: a key entity is one that “exceeds the requirements for a medium-sized enterprise”. That means above 250 employees or above the financial ceilings.
But point 3 of the same paragraph reads differently:
a managed security service provider which at least meets the requirements for a small or medium-sized entrepreneur (…) or exceeds them
For this one category the legislator moved the threshold down from medium to small. A firm that would sit far outside the act’s reach doing ordinary maintenance can, at the very same size, land in the key entity tier if what it sells falls under the second definition.
I am not going to settle how the phrase “at least meets the requirements for a small” applies to a microenterprise, because that is a question for a lawyer rather than a developer. The direction is the point: the threshold here is lower than anywhere else, so this is the one place where company size stops being a comfortable argument.
Are you covered, questions instead of a verdict
I am not going to tell you that you are covered or that you are not, because the answer depends on your numbers rather than your industry. Here is the order of questions I would work through instead.
What you actually sell, according to contracts rather than the website. A maintenance contract with updates and backups is the first definition. A contract in which you commit to handling security incidents, running tests or maintaining a risk analysis moves towards the second. You read the obligations, not the package name.
What your marketing claims. This is a separate question from the previous one and more often the problem. A page promising round-the-clock incident response and security monitoring describes a different service from the update contract that was actually signed. That gap is a problem before any authority is involved.
Your size in annual work units and turnover, for the last two closed years. Not the current one, because what counts is repetition across two periods.
Whether any of your clients is a key or important entity. This does not decide your status, but it decides what your client will ask of you.
What changes when the client is covered
Even if you are not covered yourself, something changes in the relationship with a client who is. Among the security management requirements the act lists:
the security and continuity of the supply chain of ICT products, ICT services and ICT processes on which the provision of the service depends, taking into account the relationships between the direct supplier of equipment or software and the key or important entity
That translates into something concrete. A covered client must be able to show it has a grip on its ICT supply chain. If its shop or portal runs on WordPress administered by someone outside the company, that someone is a link in the chain that has to be described.
“Do you take backups” turns into a question about a documented procedure, about a restore time proven by a dated test, about who holds production access and what happens when that person leaves. The difference is that a statement stops being enough, because the client needs evidence for its own file.
There is something non-obvious in this for the supplier, and it is good news: this is not a new legal obligation on your side, it is a new contractual requirement. It arrives through a contract, so it is negotiated like any other term rather than received like a summons.
Your details in a government register
One detail that surprises on first reading. The application for entry in the register of key and important entities includes, among the entity’s data:
information about the conclusion of a contract with a managed security service provider (…) together with that provider’s details comprising the provider’s name, registered address, correspondence address, telephone number and email address
So if a covered client outsources work in that area, the provider’s details land in a register kept by the minister. On top of that, article 7c(3) requires an application to amend the entry “within 14 days of the change”, so switching providers starts a fourteen-day clock on the client’s side.
The practical consequence for a supplier: it is worth knowing whether you appear in someone else’s entry, because it changes what an ordinary contract termination means. The application carries a declaration made under criminal liability for false statements, so the entity’s management has a strong reason to keep the data current.
Deadlines that run from events, not from one date
The deadlines in this act are not a single calendar date but clocks started by events. That is why this text does not expire on any particular day.
Six months to apply for entry, counted from meeting the criteria:
Article 7c(1). A key entity or an important entity shall submit an application for entry in the register within 6 months of the day on which the conditions for being regarded as a key or important entity are met.
For entities that already met the criteria on the day the act took effect, six months from 3 April 2026 lands in early October 2026. A company that meets the criteria next year gets its own six months from its own date.
Twelve months for the obligations for entities that met the criteria on the day of entry into force (article 33(1)), so 3 April 2027.
Twenty-four months for the first audit for key entities (article 33(2)), so 3 April 2028.
Fourteen days to update register data after any change.
High-risk supplier, a separate mechanism
The act contains a second mechanism, often confused with the first, that works differently and targets someone else.
The minister responsible for digitisation may open proceedings “on recognising a supplier of hardware or software” as a high-risk supplier, in order to protect national security or public order. Article 67c sets out the effect: covered entities must not put the products, services and processes named in the decision into use, and must withdraw those already in use “no later than within 7 years” of the decision being published in the official gazette. For telecoms operators the period is 4 years. The decision is immediately enforceable and cannot be reconsidered on application.
Two consequences for a service provider. The mechanism targets hardware and software, not firms supplying maintenance, so an agency is not its addressee. And it can still hit indirectly and hard: if a component underpinning a covered client’s setup ends up in such a decision, migration stops being a budget question and becomes a statutory deadline.
In practice that means one thing regardless of legal status: it is worth knowing exactly what sits in the stack at clients in regulated sectors, including who publishes each plugin and where the hosting comes from. That knowledge costs an afternoon when written down calmly, and considerably more when reconstructed under pressure.
Penalties, figures from the text
I quote them because they circulate rounded, usually upward.
For a key entity:
The amount of the financial penalty may not exceed EUR 10 000 000 (…) or 2 % of the turnover achieved by the key entity in the financial year preceding the imposition of the penalty, whichever is higher. The penalty may not, however, be lower than PLN 20 000.
For an important entity the ceiling is EUR 250 000 or 1.4 percent of turnover, with a floor of PLN 15 000.
Two notes that change the picture. These are maximum ceilings, not rates, and the act ties the penalty to the gravity of the breach. And penalties only start applying two years after entry into force, so after 3 April 2028, which makes the current period one for putting things in order rather than for enforcement.
What to do this quarter
Work that makes sense regardless of how the legal assessment turns out, and that costs little.
Read your own contracts for verbs. What you commit to matters, not what the package is called. “We update” and “we take backups” is one thing. “We respond to security incidents”, “we maintain a risk analysis”, “we run tests” is another. If the contracts say one thing and the website another, that is an afternoon’s work.
List the clients who might be key or important entities. Hospitals, universities, local authorities, municipal companies, energy, transport, banks and their suppliers. You do not need to settle their status, only to know where the questionnaire will come from.
Prepare what they will ask for anyway. Who holds production access, how it is revoked, where the backups sit, when they were last restored as a test and how long it took, what the out-of-hours escalation path is. Four pages, not forty.
Decide who owns the assessment. That is a question for a lawyer and an owner, not for the engineering team. You can do the technical preparation yourself; you cannot do the legal classification.
One more requirement worth knowing early, because it concerns a habit rather than a purchase. The act requires covered entities to retain information system security documentation “for at least 2 years from the day it is withdrawn from use or the provision of the service ends”, and its destruction is confirmed by a disposal record with a date, a description of the method and the approving person’s details. It sounds like paperwork and partly is, but it carries a concrete consequence for suppliers: documentation outlives the contract. If, after the engagement ends, the client has nothing to show because everything lived in your ticket system, the problem comes back to you, now without a contract.
The practical conclusion is mundane. What maintenance produces, the change log, restore test results and the access list, should live on the client’s side rather than only in the supplier’s tooling. For the supplier that is protection in a dispute; for the client it is the condition of having its own records.
What this act does not change
For balance, because writing about regulation tends to inflate its scope.
It does not change personal data rules. The GDPR applies independently and it, not this act, governs breach notification to the data protection authority. These are two separate regimes with separate deadlines, and conflating them produces unnecessary notifications.
It does not create a certification requirement. There is no requirement in the text to hold ISO or any specific certificate; there is a requirement to have and maintain an information security management system. A certificate can be a convenient proof, but the act does not mandate one.
It does not impose obligations directly on a supplier that is not itself a key or important entity. The requirements reach that supplier through a contract with its client, which is a meaningful difference, because contracts are negotiated.
What this text does not settle
Stated plainly, because a piece with this many quotations is easy to mistake for a legal opinion, and it is not one.
It does not settle whether your company is covered. That depends on contract wording, size measured in annual work units and ownership links to other entities, none of which I know.
It does not settle how an authority will read the boundary between the first and second definitions in mixed cases, where a maintenance contract contains a security element. That boundary will be clarified by practice, and there is no practice yet, because penalties start in 2028.
It does not settle how a provider established outside Poland should treat these provisions. That is a jurisdiction question and belongs to a lawyer who works in both systems.
The statute itself is public and runs to 102 pages in the Journal of Laws edition. The quotations above come from it rather than from summaries, and each can be checked by searching for the phrase in the file.
Sources
- Act of 23 January 2026 amending the act on the national cybersecurity system and certain other acts, Journal of Laws 2026 item 252, text published 2 March 2026
- The act in the ISAP legal database
- Commission Regulation (EU) No 651/2014, annex I, SME definition, articles 2, 4 and 5
Last verified: 10 August 2026. Quotations checked against the text published in the Journal of Laws. Translations of statutory wording are mine and the Polish text governs. This article is informational and is not legal advice.
