Kraków · enterprise technology · regulatory background
Compliance and risk notes for technology decisions
Published
5 Nov 2026
Notes in set
7
Scope codes
1234567
All seven notes are current at the date above. Each note states the rule, the teams it touches, and the contract questions it raises.
These notes cover the regulatory and risk-management topics that shape technology procurement and outsourcing in Poland. They are written as background for decision-makers: what a rule requires, which teams it touches, and what it means for the contracts and controls that sit around a technology choice.
How to read a note
- A Rule and where it applies
- B Teams and contracts affected
- C What to check before you sign
A rule only matters once it reaches a contract
Polish technology procurement now carries regulatory weight that used to sit with the legal team alone. ICT risk management, third-party provider oversight and supply-chain security all land on the same desk: the one that drafts the statement of work. These notes gather the topics in one place so technical and buying teams can read the same page.
Each note below follows the same shape. First the rule and the date it applies from, then the teams and suppliers it touches, then the questions worth asking before a contract is signed. Where a rule is still being implemented or interpreted in Poland, the note says so.
-
Financial sector
DORA and ICT risk duties for banks and fintechs
-
Supplier side
Assessing third-party providers and their obligations
-
Wider market
NIS2 and the Polish cybersecurity law
-
New systems
AI governance agreed before a model goes live
DORA and financial-sector technology
Applies since 17 January 2025 · Polish implementing rules from 7 August 2025
DORA has applied to financial entities since 17 January 2025, with Polish implementing legislation supporting it from 7 August 2025. The regulation raises requirements for ICT risk management and for how third-party providers are assessed.
For technology teams, the effect is concrete. Vendor due diligence is more detailed than it used to be, contractual expectations around incident reporting are tighter, and the ICT risk function has a louder voice in procurement. Banks and fintechs in Poland have been reshaping their vendor processes accordingly — questionnaires that once ran to a page now run to a set, and the answers are read by people outside IT.
The practical consequence for a supplier or a buying team is that the evidence needs to exist before the question is asked. A provider that can show how it registers incidents, who is accountable for them and how fast it notifies a client will move through assessment faster than one that answers those points in prose.
What the note asks a buyer to establish
-
Whether the provider supports a regulated activity, and how critical that support is to it.
-
How incidents are detected, escalated and notified, and who at the provider owns that path.
-
What the contract says about audit access, subcontracting and exit, and what it leaves unstated.
Third-party provider management
Most enterprise technology stacks now depend on providers the organisation does not control. That dependency is what the current rules are aimed at.
Third-party provider management means knowing which providers are critical, what they are contractually obliged to do, and how incidents are escalated. The notes in this area cover the practical side: what a provider assessment needs to establish, where contractual language typically falls short, and how outsourcing arrangements interact with ICT risk requirements.
-
Criticality
Which providers carry functions the organisation could not continue without.
-
Contract
Where the wording commits the provider and where it only describes intent.
-
Escalation
Who is called, in what order, and within what window when something fails.
-
Oversight
How the arrangement is reviewed after signature, not only before it.
Technology procurement under new rules
Procurement is where compliance requirements either get written into a contract or get lost. Under the current environment, technology procurement in Poland has to account for ICT risk management expectations, supply-chain questions, and incident-reporting obligations. These notes are written for the people who run that process.
Ask the provider
Request the incident-notification path in writing, with the window and the contact named. Ask which subcontractors sit under the service and whether they are disclosed before or after signature. A provider that answers these from an existing document is easier to work with than one that composes an answer for your request.
Document it
Keep the assessment, the version of the contract it was made against, and the date. When a rule changes or an auditor asks why a provider was accepted, the record answers faster than memory does. Notes here are dated for the same reason: a position taken in 2024 may need rereading in 2026.
Locate the risk
Where a provider is critical to a regulated activity, the risk does not stop at the provider's own systems. It reaches the service the organisation owes its own clients. That is the part worth naming in the contract, because it is the part a regulator will ask about first.
In progress · the Polish implementing rules for NIS2 are still being interpreted
Notes that touch an unsettled rule say so in the text.
Who the notes place in scope
-
Organisations in sectors the Polish cybersecurity law names, alongside the financial entities DORA already covers.
-
Suppliers that serve those organisations, including cloud, managed service and software providers.
-
Management bodies, which now carry accountability for the security posture they sign off.
NIS2 and the Polish cybersecurity law
NIS2 and Poland's implementing cybersecurity law have changed what vendor contracts need to cover for a broad set of organisations, not just financial entities. Supply-chain security, incident notification, and management accountability are now part of the compliance picture.
The notes cover which organisations fall in scope, what the notification obligations look like, and how the requirements land on technology suppliers that serve those organisations. The last point matters most to readers of this page: if you supply a regulated organisation, the obligations reach you through the contract even when the law does not name you directly.
Notification windows are the part most often misread. A supplier that discovers an incident on its own infrastructure may owe the client information well before the client owes anything to a regulator. Notes here separate those two clocks so a response plan can be built around both.
AI governance before deployment
Teams deploying AI models now have to think about governance before deployment rather than after. That covers model selection, data handling, human review, and the question of what happens when a model output turns out to be wrong.
The notes in this area are written for technical and operational leads who need a defensible position before a model goes into a workflow. They are background material, not legal advice, and they say so. A defensible position usually answers four things in writing: which model was chosen and why, what data it sees, who reviews its output before it acts, and what the fallback is when it is wrong.
Model selection
Why this model for this task, and what was ruled out. A record of the comparison is worth more than the choice itself.
Data handling
What the model receives, where it is processed, and how long any of it is retained.
Human review
Which outputs a person checks before they take effect, and who that person is.
Wrong output
What happens when the model is wrong, who notices, and how the workflow recovers.
Incident response and supply chain
Incident response planning has to account for the supply chain now. A security incident at a critical provider is an incident the organisation has to manage, even when its own systems are unaffected. These notes cover how supply-chain incidents are handled, what notification duties apply, and how response plans need to be structured when key services sit with third parties.
How a response plan reads once the supply chain is in it
-
Name the critical providers and the service each one carries.
-
Write the contact path for each, including the hours it is staffed.
-
Separate the provider's notification duty from your own.
-
Rehearse it, because a plan that has never run is a document, not a plan.
Reading these notes
These notes are background, not legal advice. They are written to help technical and procurement teams ask better questions and to understand the regulatory context around a technology decision.
Where a note touches a rule that is still being implemented or interpreted in Poland, it says so. Rules change, and the notes are dated for that reason. If a note you are relying on predates a change, treat it as a starting point and check the current position before you commit a contract to it.
Legend
- Settled The rule applies and its Polish implementation is in force.
- In progress Implementation or interpretation in Poland is still moving.
- Background Context that shapes a decision but sets no obligation by itself.
Every note carries its own date, so a reader can tell how recent the position is.
Questions readers send us
Are these notes legal advice?
No. They are background material written for technical and procurement audiences. For decisions with legal consequences, the institute's notes are a starting point, not a substitute for professional advice.
Which regulations do the notes cover?
Primarily DORA, NIS2 and the Polish cybersecurity law, and AI governance as it applies to enterprise deployment. Coverage is focused on how these rules affect technology procurement, outsourcing, and ICT risk management.
How current are the notes?
Each note is dated. Where a rule is still being implemented or interpreted in Poland, the note says so and keeps the date visible, so you can judge whether the position it describes has moved since it was written.
Who are the notes written for?
Technical leads, procurement teams and the people who sign technology contracts. The wording avoids legal shorthand where a plain sentence does the job, because the reader is usually the one who has to act on it.
Take the question to the people who can answer it
If a note here raises a question about a contract in front of you, the institute can point you to the research behind it or put you in touch with the team that writes the briefings. The notes themselves stay where they are: dated, sourced, and open to rereading when a rule moves.
Institute registry
- Legal name
- INSART INSTITUTE OF ADVANCED RESEARCH AND TECHNOLOGIES SP. Z O.O.
- KRS
- 0000949885
- NIP
- 6762610622
- REGON
- 521068374
- Office
- ul. Józefa Sarego 5, lok. 4, 31-047 Kraków, Poland
- Hours
- Monday to Friday, 9:00 AM – 6:00 PM
- Phone
- +19082975632
- [email protected]