1. The bank is no longer the sole gatekeeper
2. A procedure is no longer a “shelf-ware alibi”
3. “Should you have known?”
4. A company’s problem can quickly become a board member’s problem
5. AML is becoming an element of enterprise management
6. The new boundary of liability
7. AML is entering new sectors today. But above all, it is entering boardrooms.

For years, anti-money laundering (AML) was primarily associated with banks, financial institutions, beneficial owner forms, and a million questions about where the client got their money from. It was a world of procedures, transaction alerts, and specialists locked away in compliance departments. That world is now definitively coming to an end.

AML is increasingly ceasing to be the exclusive domain of the financial sector. Meanwhile, its core requirements are making their way into law firms, tech companies, accounting offices, estate agencies, crypto market operators, luxury goods traders, and even professional sports. The EU AML package further expands the catalogue of obliged entities to include, among others, a significant portion of the crypto sector, luxury goods dealers, as well as professional football clubs and agents.

At the same time, the European Anti-Money Laundering Authority (AMLA) has been established to strengthen and harmonise supervision across the entire system. However, this is not just about adding more industries to the legislation. Much more important is the shift in how liability is perceived.

The bank is no longer the sole gatekeeper

The AML system is based on the premise that it is not only the state that is supposed to “hunt down” criminals. Private entities standing between the client and the transaction are also expected to assist.

A bank sees the flow of money. An accountant knows the settlement structure. An estate agent sees who is buying the apartment. An advisor helps structure a transaction. A law firm may be involved in setting up a company, acquiring a business, or managing a client’s assets. In the eyes of the European legislator, each of these entities is a gatekeeper to the legitimate economy.

In Poland, advocates, attorneys-at-law, foreign lawyers, and tax advisors are already obliged entities when they provide assistance concerning, inter alia, the buying and selling of real estate or enterprises, managing assets, opening accounts, making contributions, and creating or managing companies. This does not mean that every piece of legal advice is subject to AML. It does mean, however, that a law firm participating in certain transactions can no longer assume that the issue of the origin of funds is solely the bank’s problem.

The same applies to entrepreneurs. Not every entrepreneur is directly an obliged entity. However, almost anyone can encounter AML as a bank client, a participant in a transaction, an entity disclosing its ultimate beneficial owner, or a contractor whose ownership structure, funding source, or payment routing starts to raise questions.

AML is therefore spilling beyond the formal statutory catalogue. It enters ordinary business operations through the back door, via banks, contractors, audits, financing, and corporate group requirements. The only limitation here is the “processing capacity” of the supervisory authorities.

A procedure is no longer a “shelf-ware alibi”

Even a few years ago, many organisations treated compliance quite simply: we write a voluminous procedure that is essentially unreadable, conduct some generic training, collect signatures, and place the document in a suitably thick binder or a beautifully named folder on a shared drive.

The binder had one fundamental advantage: it looked professional, and the drive was backed up.

The problem is that regulators are increasingly less likely to ask merely whether a procedure existed. They ask whether it was tailored to the actual business model, whether it identified specific risks, whether it was updated, and whether anyone checked if it was working.

In the current approach, risk assessment cannot be reduced to labelling a client as “low”, “normal”, or “high”. The risk category must influence the scope and intensity of the actions actually taken. A change in product, distribution channel, geographical area, client structure, or political situation may require an immediate update of the assessment. The authority also expects the documentation to allow for the verification of the effectiveness of the measures applied, and for the risk assessment to be approved by responsible persons at the management level.

In other words, a procedure sitting on a server proves at most that someone knew how to write or outsource writing. It does not prove that the organisation knows how to manage risk.

“Should you have known?”

This is where the most dangerous shift occurs.

Liability is increasingly not based solely on the question of whether someone actually knew about the suspicious nature of a transaction. The question of whether you should have noticed it under a properly organised system is becoming ever more crucial.

Did the client’s profile match the nature of the transaction? Was the source of funds credible? Did the ownership structure make commercial sense? Was the sudden change in payment routing explained? Did the intermediary have a genuine business justification? Did anyone connect several seemingly neutral pieces of information?

This is no longer a classic document check. It is an obligation to draw conclusions.

The regulator does not expect clairvoyance. However, they do expect the organisation to know its own business well enough to spot anomalies. And when something is missed, a very uncomfortable question will arise: was it a failure of the employee, the procedure, the IT system, or perhaps the management board that approved an operational model without adequate safeguards? This is precisely where the boundary between compliance and personal liability blurs.

A company’s problem can quickly become a board member’s problem

The Polish AML Act does not leave this solely in the realm of best practices.

In an obliged entity where a management board operates, a person responsible for the implementation of AML duties must be designated from among its members. This is not an honorary function or a mere footnote in an organisational resolution. The Act allows for financial penalties to be imposed on persons responsible for fulfilling AML obligations. It also provides for the possibility of a temporary ban on holding managerial positions. In specific cases, breaches of reporting obligations may even lead to criminal liability.

Naturally, a board member is not expected to personally analyse every transaction. However, they are expected to ensure that there is an efficient system, adequate resources, a clear division of responsibilities, and a realistic escalation path.

Therefore, it is not enough to say, “We have an AML officer for that”.

The board may delegate the execution of tasks. It cannot delegate the entire problem and then pretend that AML reports were just an exotic, graphically pleasing addition to the board meeting materials.

Situations where the compliance unit has been signalling staff shortages, inefficient tools, backlogs in client reviews, or data quality issues for months, while the management merely notes the information and calmly moves on to the sales agenda, become particularly risky.

Such a meeting minute may one day turn out to be more interesting than many a procedure.

AML is becoming an element of enterprise management

The biggest mistake today is treating AML as an isolated regulatory island. Money laundering risk is intertwined with sanctions risk, corruption, tax, reputational, cyber risks, and the criminal liability of management.

A new product, expansion into a foreign market, a company acquisition, a venture into digital assets, serving clients from high-risk countries, or a change in the payment model are not purely business decisions. They should also trigger questions about AML implications.

Therefore, a properly functioning system cannot be built once and for all. It must respond to changes in the company’s operations. If the business has changed but the risk assessment remains the same, it usually does not mean the risk has been stable. It means nobody has looked at the document.

The new boundary of liability

AML is no longer just about fighting a suitcase of cash brought into a bank by a man in dark glasses looking like someone from a B-movie gangster film. Today’s risk hides in multi-level ownership structures, cross-border payments, digital assets, seemingly legitimate investments, brokerage agreements, and transactions, each of which looks perfectly innocent on its own.

Consequently, the expectations towards those responsible for the organisation are also changing. It is not enough not to know. You also have to demonstrate that the organisation did everything that could reasonably be expected of it to find out. And this is exactly where the comfortable world of compliance understood as a set of documents ends. What begins is accountability for decisions, omissions, lack of resources, and risks that nobody wanted to see.

AML is entering new sectors today. But above all, it is entering boardrooms.

AML is entering new sectors today. But above all, it is entering boardrooms, and it is there that the decision is made as to whether the company truly understands its risks or merely possesses a document covering them. If you are not sure which side your organisation stands on, we will help you find out before the regulator asks.

The post AML is “sailing” into broader waters. Do you know who is responsible for it today? first appeared on Kancelaria LBKP.

Our experts Paulina Jeziorska and Zuzanna Prandecka-Walek have analysed this topic in Dziennik Gazeta Prawna. In the article, they discuss step by step what the amendment means in practice for local authorities – from determining who is subject to the new regulations, through the catalogue of obligations, to the sanctions regime.

A few points worth noting:

A new classification of entities. The previous model, which distinguished between operators of key services and digital service providers, is being replaced by a classification into key entities and important entities. In the case of local authorities, the decisive factor is not the scale of their operations, but the type of authority and its position within the structure. Key entities include, amongst others, district authorities and local councils employing at least 50 people. Important entities, in turn, include local government budgetary units, budgetary institutions, cultural institutions and municipal companies – provided they carry out public tasks using information systems.

The obligations go far beyond mere formalities. Implementing an information security management system, handling and reporting incidents, ensuring business continuity, and streamlining relations with suppliers – this is not a one-off project, but a permanent change in the way the organisation operates. For important entities that are public bodies, the legislator has also provided a specific list of minimum requirements in an annex to the Act.

The penalties are substantial. Fines can reach up to €10 million for critical entities and €7 million for important entities. The head of the entity is held personally liable – up to 100% of their salary in the case of public entities. The regulations grant the authority some flexibility in determining the penalty, taking into account, among other things, the entity’s financial capacity, but the lower thresholds are set by law.

A key point of interpretation: is a key entity that does not use information systems to carry out public tasks completely exempt from these obligations? The wording of the regulations does not provide a clear answer, which in practice may create uncertainty for local authorities.

For many local authorities, the coming months will test their ability to rapidly build up the expertise and structures that they simply have not needed until now. Putting this off is no longer an option.

The full article by Paulina Jeziorska and Zuzanna Prandecka-Walek is available in Dziennik Gazeta Prawna:

The post Cybersecurity in local government – from a technical issue to a board agenda item first appeared on Kancelaria LBKP.

The illusion of full regulation

MiCA, in Article 2 and the recitals of the preamble, provides for significant exclusions. MiCA does not apply to, among other things:

• deposits, including structured deposits,
• cash (unless they meet the definition of e-money tokens),
• NFT tokens, provided they are ‘unique and non-fungible’;

However, it will be crucial to pay attention to recital 22 of MiCA. In this recital, the legislator stated that ‘where crypto-asset services are provided in a fully decentralised manner, without intermediaries, they should not be covered by this Regulation.’

Therefore, MiCA effectively covers only centralised or hybrid models. Services where there is no operator, provider or controller are not covered by the new rules.

Lack of DeFi regulation: the premise of ‘fully decentralised’

In practice, not all DeFi business models will meet the criterion of full decentralisation.

Recital 22 of MiCA indicates that the regulation does not cover services provided in a ‘fully decentralised manner, without intermediaries’. Although the term ‘intermediary’ is not defined, it can be assumed that it refers to a legal entity that is actively involved in the operation, provision or control of services related to crypto-assets, whether directly or indirectly.

As a result, the assessment of ‘full decentralisation’ may require determining in each case whether any entity influences the functioning of the protocol or interface. Unfortunately, the EU legislator has not provided more detailed criteria or proposed a definition that would make it easier for supervisory authorities and market participants to clearly classify entities, which is likely to cause interpretation complications in the near future.

In practice, therefore, it will be the national supervisory authority – in Poland, the Financial Supervision Authority – that will decide whether a particular DeFi is subject to MiCa and whether it requires a CASP authorisation. For the time being, there are no detailed guidelines to assist in making such a decision, but it is likely that EU authorities will provide guidance on what elements should be taken into account in order to assess whether certain services are provided in a fully decentralised manner without intermediaries or not.

Partial decentralisation remains subject to MiCA

The ‘comfort’ of no regulation is not provided by partial decentralisation. Recital 22 itself stipulates that if ‘part of such activities or services are carried out in a decentralised manner’, MiCA obligations remain in force. Such a modern hybrid could be a DEX with an upgrade key, i.e. a smart contract that can be changed or suspended by the project management. In practice, such a protocol is not fully decentralised, as there is an entity that retains the ability to interfere with its functioning.

In such configurations, it may be possible to identify the controlling entity (even partially), and therefore the competent national authority may consider that such an entity can only operate after obtaining a CASP licence.

Issuance of crypto-assets ‘without an issuer’

The second exception provided for in recital 22 does not concern services but the issuance of crypto-assets. If a crypto asset ‘has no identifiable issuer’, the provisions of Titles II to IV of MiCA (concerning, inter alia, the information document, obligations towards token holders, issuance, offering and admission to trading of crypto assets) do not apply.

This exception may apply to issues made directly by an on-chain protocol launched without a central entity, e.g. through a fair launch or automatic minting mechanism, without the involvement of any managing person.

It is worth noting that MiCA does not specify what specific characteristics should determine whether a particular entity can be considered an issuer. Nevertheless, the degree of control over the issuance process and the possibility of linking specific persons or structures to the management of the issuance or the economic benefits derived from it may be of key importance.

Practical consequences for the market

• The national authority (in Poland – the Polish Financial Supervision Authority) will have to determine whether there is an ‘intermediary’ in a given project model and whether the issuer can be identified. Under the draft Polish law on the cryptoasset market (June 2025), the KNF will gain instruments to restrict access to or block the interface to such a website.
• Entrepreneurs should assess the level of centralisation of their products today. Projects that use multisig to upgrade a contract, charge transaction fees or control issuance revenues, or set rules for service/token management may qualify as CASPs.
• Investors should be aware that the absence of an issuer or CASP also means that there is no European regulatory protection under MiCA.

Conclusions

MiCA is only the first step towards a harmonised crypto-asset market. By drawing a line in recital 22, the European legislator has recognised that DeFi requires a separate – perhaps entirely new – regulatory approach. Until such a framework is developed:

• full decentralisation remains the only way for a service to fall completely outside MiCA;
• any element of centralisation may entail licensing obligations;
• the national authority will have to assess whether it is dealing with DeFi or not.

The post MiCA does not cover DeFi. What does this mean for the crypto asset market in the EU? first appeared on Kancelaria LBKP.

You can read more about this here: https://lbkp.pl/rozpoczecie-stosowania-mica-co-oznacza-dla-rynku-krypto-w-polsce/

MiCA transition period at EU level – 18-month safety buffer

The basic premise of the MiCA Regulation is to introduce a certain ‘time buffer’ during which existing crypto-asset service providers will be able to operate under the old rules laid down in national legislation. According to Article 143(3) of the MiCA Regulation, this period is 18 months from the date of application of the new rules, until 1 July 2026.

During this time, companies providing crypto-asset services may continue to operate in accordance with existing local regulations until they obtain the formal authorisation required by MiCA in accordance with Article 63 or until such authorisation is refused, whichever comes first. This is a particularly important stage for all entities, both those already present on the market and new players planning to enter the cryptocurrency market in the European Union.

Flexibility in setting transition periods at national level

MiCA provides flexibility for Member States in determining the length of the transition period. Recital 114 of the Regulation emphasises that if national regulations in force before 30 December 2024 were significantly less stringent than the MiCA requirements, Member States may decide to shorten or even omit the transitional period. This allows them to raise the standards of crypto-asset entities more quickly to the level set by the EU.

Article 143(3) MiCA – specific conditions for the use of the transitional period in the EU

Pursuant to Article 143(3) of MiCA, crypto-asset service providers who provided their services in accordance with applicable national law before 30 December 2024 may continue to operate under the existing rules until 1 July 2026, until they obtain authorisation under Article 63 of MiCA or until authorisation is refused. Only these companies will be eligible for transitional arrangements – companies that commence operations after that date will be subject to the full MiCA regime from the outset.

Provisions concerning entities not covered by the register of virtual currency activities in Poland

Poland is participating in the process of implementing the MiCA Regulation and in June 2025 submitted a draft law on the crypto-asset market to the Sejm.

Pursuant to Article 162 of the draft law, an entity which, on 29 December 2024, provided crypto-asset services within the meaning of Article 3(1)(16) of MiCA (for more information on the scope of services, see https://lbkp.pl/rozpoczecie-stosowania-mica-co-oznacza-dla-rynku-krypto-w-polsce/), but which do not constitute economic activities consisting in the provision of services in the field of:

a) exchange between virtual currencies and means of payment,

b) exchange between virtual currencies,

c) intermediation in the exchange referred to in point (a) or (b),

d) keeping accounts referred to in Article 2(17)(E) of the AML Act

– may provide these services in relation to crypto assets under the existing rules, but for no longer than:

• 4 months from the entry into force of the draft Act,
• or for 9 months from the date of entry into force of the draft act, if, within 3 months of the date of entry into force of this act, it submits a complete application for the issuance of this authorisation and receives the notification referred to in Article 63(4) of the MiCA Regulation.

Regulations for companies entered in the VASP register (i.e. the register of virtual currency activities) in Poland

For companies that were entered in the national VASP register on the date of entry into force of the draft act, similar rules apply – they may continue to operate under the existing rules for 4 months from the date of entry into force of the draft law, or for 9 months from the date of entry into force of the draft law if they submit a complete application within the prescribed time limit and receive notification of acceptance of the application.

An exception is if such an entity is removed from the register before the expiry of the specified time limits.

Practical consequences for the market – what do companies need to do?

The regulatory changes resulting from MiCA and the Polish Cryptoasset Market Act impose an obligation on companies to closely monitor the current legal situation and develop an implementation strategy. The key actions that companies operating on the market should take include, in particular:

• verifying their current legal status (whether the company is registered as a VASP, whether it has been operating in accordance with the existing regulations),
• preparing a complete set of documentation necessary to apply for a CASP licence,
• monitoring transition deadlines and responding quickly to any changes in legislation,
• implementing new internal procedures in accordance with MiCA and national requirements and guidelines from supervisory authorities.
• Failure to meet deadlines or lack of adequate preparation may result in the loss of the ability to operate on the crypto asset market in Poland and throughout the EU.

Documentation and formal obligations – challenges for companies

Preparing for the full implementation of MiCA will require companies to conduct an in-depth analysis and carry out numerous formal and legal activities. The CASP registration process is multi-stage and includes:

• developing AML/KYC policies and measures to prevent money laundering and terrorist financing,
• preparing compliance documentation and risk management rules,
• implementing comprehensive IT security and personal data protection procedures,
• providing detailed descriptions of services, products, technological architecture and mechanisms for securing customer funds,
• presenting risk analyses and business continuity plans.
• You can read more about this here: https://lbkp.pl/uzyskanie-zezwolenia-casp-kluczowe-informacje-dla-firm-kryptowalutowych/

Why start preparing for MiCA now?

Currently, despite the fact that the act implementing MiCA in Poland has not yet entered into force, it is worth starting to prepare documentation and analyse your own activities in terms of the new regulations in advance. Companies with a complete set of ready-made documents will be able to go through the CASP registration process faster and obtain the required permits. This allows for smooth continuation of operations and gaining a competitive advantage in the market.

Importantly, current legislative analyses do not indicate any risk of significant changes to the key provisions of the draft law, which is why preparatory measures are already fully justified at this stage.

No possibility to submit an application before the law enters into force

It is not yet possible to submit an application for CASP registration to the relevant authority, as the law enabling this process has not yet entered into force. However, our clients are providing services in accordance with the existing regulations, while preparing with us the documentation necessary to apply for a CASP licence.

The work on the bill so far does not indicate that the draft will undergo major changes. We recommend that you start preparing all the required documents now. Due to the broad scope of the guidelines already set by the EU authorities, completing all the documentation and introducing the necessary procedures may be time-consuming and require careful planning. Starting these preparations in advance will allow you to go through the registration process smoothly and adapt your business to the new requirements.

Gain an edge with professional MiCA support

The implementation of the MiCA Regulation and the new Crypto Asset Market Act in Poland requires a multi-stage, well-planned process covering legal, technical and management issues. Proper preparation and understanding of the transition periods are key to the smooth functioning of the crypto asset services market, both for existing and new entities.

Our law firm offers comprehensive support in the implementation of MiCA requirements – from completing documentation and training staff to ongoing compliance support and legal advice. We encourage companies that want to efficiently and effectively adapt to the new regulations to contact us – from consultation, through the preparation of policies and procedures, to the finalisation of the CASP registration process.

Don’t wait until the last minute – a delayed response to legislative changes may mean losing your competitive position and growth opportunities. Contact us!

The post MiCA in Poland – a compendium of knowledge about transition periods and deadlines in the draft law on the crypto-asset market first appeared on Kancelaria LBKP.

The MiCA (Markets in Crypto-Assets) Regulation is the first European Union legal act that comprehensively regulates the rights and obligations of issuers and service providers related to crypto-assets. The aim of MiCA is to ensure a high level of investor protection, particularly for retail investors, to increase the transparency of the crypto-asset market and to harmonise the rules governing this market across the European Union. Thanks to MiCA, the crypto-asset market is gaining clear rules, which promotes investment security and the development of the industry.

The post Types of crypto assets regulated by MiCA first appeared on Kancelaria LBKP.

How to obtain a CASP licence?

In order to operate in the field of crypto assets in accordance with MiCA regulations, entrepreneurs must meet certain requirements and submit an application to the relevant supervisory authority in their country.

Requirements for physical presence in the EU

In accordance with Article 59(2) of MiCA, crypto asset service providers must:

• Have their head office in a member state where they actually carry out at least part of their cryptoasset service business.
• Have their place of effective management in the EU.
• Have at least one director who is resident in the EU.

Therefore, purely virtual operations without a physical presence in the EU do not meet the regulatory requirements.Where do I apply for a CASP authorisation?

Entities applying for a CASP authorisation shall submit an application to the competent supervisory authority of their home Member State.

The home member state for a crypto-asset service provider will be the member state in which the crypto-asset service provider has its registered office.

Does the CASP authorisation allow for the provision of services throughout the EU?

Yes, once they have obtained a CASP licence, companies can provide crypto-asset services throughout the European Union under the freedom of establishment or the freedom to provide services. Importantly, cross-border activity does not require a physical presence in the host Member State.

Requirements for board members of entities applying for a CASP

Board members must:

• They must be of good repute, have a clean criminal record and have appropriate knowledge and experience.
• They must not have been convicted of offences relating to money laundering or terrorist financing or of other offences that could affect their good repute.
• At least one board member must be resident in the Union.
• They must also demonstrate that they are able to dedicate sufficient time to effectively fulfil their duties.
• They must not be subject to any penalty under commercial law, insolvency law, financial services regulations, anti-money laundering and anti-terrorist financing regulations, anti-fraud regulations or professional liability regulations.

The fulfilment of these conditions must be documented with appropriate evidence and attached to the authorisation application. The supervisory authority will verify whether these conditions are actually met.

Documents required for the CASP authorisation application

The exact list of documents and information that must be included in the CASP application depends on the type of services that the applicant intends to provide according to Art. 3, Paragraph 1, No. 16 of the MiCA. Therefore, the first step in preparing an application should always be to identify the services you plan to provide and verify the requirements that the MiCA has set for the authorisation of these specific services.

However, based on the requirements set out in the MiCA regulation and the accompanying technical standards, it is possible to define a basic catalogue of documents and information that will need to be completed by an entity preparing to apply for a CASP licence. These will include:

• Identification data of the applicant.
• Articles of association or partnership agreement.
• Programme of activities and type of services planned, as well as the place and manner in which they will be provided.
• Proof of compliance with the prudential requirements set out in Article 67 of the MiCA (documents confirming the required funds or guarantees, insurance policies if applicable).
• Description of management principles – organisational structure of the applicant and internal supervision system and decision-making procedures.
• Proof of good repute and competence of the members of the management body – (Criminal records and CVs as well as information on experience).
• Description of internal control and risk management procedures (Policies and procedures for identifying, assessing and managing risks, procedures for combating money laundering and terrorist financing, and a business continuity plan).
• Technical documentation of ICT systems and security solutions with a non-technical description (Consistent non-technical description and business continuity policy, which includes ICT business continuity plans as well as ICT response and recovery plans).
• Procedures for segregating crypto assets and customer funds.
• Complaint handling procedures.
• Cryptoasset custody policy (Required for custody service plans).
• Description of trading platform operating rules (if applicable) – Platform rules and procedures and market abuse prevention system.
• Confirmation of the knowledge and experience of persons providing advice or portfolio management (if we intend to provide crypto-asset advice or crypto-asset portfolio management services) – Documents confirming the competence and experience of advisors necessary to fulfil their duties.
• Indication of the type of crypto assets to which the crypto asset service relates.
• Systems and procedures to ensure the availability, authenticity, integrity and confidentiality of data.
• Outsourcing policy, including policies on contingency plans and exit strategies, taking into account the scale, nature and scope of the crypto asset services provided.

Summary

Considering the detail and extent of the information and documents that must be attached to the CASP licence application, there is no doubt that this is a process that requires thorough preparation. Therefore, if you are planning to apply for a MICA licence, please contact us to make sure that your application meets all regulatory requirements! We will gladly help you prepare the relevant documentation and ensure compliance with MiCA regulations, as well as other regulations relevant to, among others, financial entities or those in the crypto-asset industry – in particular, GDPR or DORA.

The post Obtaining a CASP licence – key information for crypto companies first appeared on Kancelaria LBKP.

This register is more than a list of contracts with ICT suppliers. Its purpose is to create a database of key information for ICT risk management. The ROI is intended to map the relationships between the financial entity and its suppliers, providing supervisory bodies with full insight and control over these relationships.

The deadline for preparing and submitting the first ROI to the KNF is approaching. According to the KNF, the first ROI reports will be submitted in April 2025 (the exact date will be announced at the beginning of April).

Scope of responsibilities and key challenges

In order to prepare the ROI, financial entities will have to collect a range of information, including:

• Information on specific ICT contracts, including basic information such as the parties, the type of services, the dates of conclusion and validity, as well as more detailed information on the contract value, notice periods, place of service provision or data storage.
• LEI numbers of ICT suppliers and subcontractors.
• For contracts that support critical or important functions, comprehensive information about the supply chain is necessary.

For many financial institutions, the key challenge is obtaining data for the ROI register. This information is often not centrally collected, which requires the involvement of various organisational units and external ICT providers, which can delay the process.

Formal requirements, validation and changing guidelines

Collecting data is only the first step. The next challenge is to correctly fill in the ROI register in accordance with the requirements of the Polish Financial Supervision Authority (KNF).

The reporting obligation will be fulfilled via the KNF reporting system, using dedicated ROI forms. The register must meet certain standards – incorrect data format, missing required fields or incorrect file name can result in rejection, which means urgent correction and resubmission.

The changing regulatory environment is an additional challenge. Taxonomies, forms and instructions are constantly updated, so financial institutions must follow KNF and EBA guidelines to comply with the latest requirements and avoid problems when submitting the register.

Consolidation of data in capital groups

For capital groups, the consolidation of the ROI register is an additional challenge. A financial entity required to maintain a consolidated ROI must include not only its own contracts with ICT suppliers, but also similar information from its subsidiaries (if they are subject to DORA).

For financial entities, this means the need to:

Verify whether and to what extent their ROI is subject to consolidation,

If they are required to consolidate, obtain data from subsidiaries in time to verify it and enter it in the register.

Standardising the way data is reported by individual entities is key to avoiding inconsistencies in the consolidated ROI register.

How to prepare?

Due to the complexity of the process of preparing a correct ROI, in my opinion, the key to the success of the entire undertaking is the implementation of an internal process for preparing the register, which should include:

1. careful familiarisation with the definitions in DORA and implementing acts, as well as the interpretation of KNF guidelines;
2. for capital groups: identify the entities covered by the register – determine which entities within the financial group are subject to the reporting obligation;
3. collect and complete data in the appropriate forms – identify missing information and contact suppliers to obtain it.
4. comply with formats and taxonomy
5. Regularly monitoring regulatory changes – keeping track of updates from the KNF and EBA to ensure that the organisation is working on the correct forms and in accordance with current guidelines.

o summarise…

The ICT Contract Information Register is a key obligation for financial entities covered by DORA, and its preparation requires time, special care and precision. Failure to comply with the PFSA’s requirements may result in the report being rejected and, in extreme cases, severe sanctions.

Financial institutions should work intensively on their records and also monitor updates provided by the PFSA and EBA, as changing guidelines may force additional adjustments in reporting.

Useful materials

• EBA:Guidelines and materials regarding DORA
• KNF: DORA reporting portal (reporting forms, detailed instructions and KNF guidelines, requires login)

The post DORA: Register of ICT Contract Information – the Polish Financial Supervision Authority will soon give the ‘I’m checking’ signal first appeared on Kancelaria LBKP.

What is a data breach?

A data breach is a security incident that leads to accidental or unlawful:

• data destruction
• data loss
• data modification
• unauthorised disclosure of data
• unauthorised access to data

A breach can be both a deliberate action (e.g. a cyber attack) and an accidental event (e.g. losing a data carrier). The key point is that the breach concerns personal data being processed and can have a negative impact on the rights and freedoms of the data subjects.

Why are breaches dangerous?

Data breaches can have serious consequences for data subjects, such as:

• physical injury
• property damage (e.g. identity theft, financial fraud)
• non-pecuniary damage (e.g. damage to reputation, mental stress)

Even seemingly insignificant incidents can have far-reaching consequences. It is therefore important that data controllers respond appropriately to any violations.

Who is responsible for data protection?

The main responsibility lies with the data controller, i.e. the entity that determines the purposes and means of processing personal data. It is the controller who must implement appropriate technical and organisational measures to ensure data security.

The following also play an important role:

• Processors – process data on behalf of the controller
• Data Protection Officers (DPO) – advise and monitor compliance with the GDPR

What are the responsibilities of the controller?

In the context of personal data breaches, the controller has the following responsibilities:

1. Preventing breaches by implementing appropriate safeguards
2. Detecting and identifying breaches
3. Responding to breaches:
4. Remediation of the breach and minimisation of its effects
5. Assessment of the risk associated with the breach
6. Reporting of the breach to the supervisory authority (if there is a risk)
7. Notification of the data subjects (in case of high risk)
8. Documentation of the breach

How can data breaches be prevented?

The key is to implement appropriate technical and organisational measures, such as:

• Data encryption and pseudonymisation
• Regular testing and evaluation of the effectiveness of security measures
• Employee training
• Incident response procedures
• Control of data access
• Data backups

The selection of measures should be based on an analysis of the risks associated with the processing.

How to detect violations?

Administrators should implement monitoring and incident detection systems, such as:

• Intrusion detection systems (IDS/IPS)
• Anti-virus software
• Analysis of system logs
• Procedures for reporting incidents by employees

It is also important to train staff to recognise potential violations.

What to do after a breach has been detected?

After a breach has been detected, the controller should:

1. Take immediate action to contain the breach and minimise its impact
2. Assess the risk to the rights and freedoms of data subjects
3. Report the breach to the supervisory authority within 72 hours if there is a risk (unless it can be demonstrated that the risk is unlikely to materialise)
4. Notify the data subjects if there is a high risk
5. Document the breach and the measures taken

Reporting breaches to the supervisory authority

The notification to the President of the Personal Data Protection Office should include:

• A description of the nature of the breach
• The categories and approximate number of data subjects
• The possible consequences of the breach
• The measures taken to remedy the breach
• The contact details of the Data Protection Officer or other contact point

The notification can be made electronically via a dedicated form or ePUAP.

Notification of data subjects

In the event of a high risk, the controller must notify the data subjects without undue delay. The notification should:

• Be written in simple and clear language
• Describe the nature of the breach
• Include the contact details of the DPO or other contact point
• Describe the possible consequences of the breach
• Describe the measures taken to remedy the breach
• Include recommendations for individuals to minimise potential negative effects

Notifications can be made directly (e.g. by email) or through a public announcement.

Documenting breaches

The controller must document all violations, regardless of whether they were reported. The documentation should include:

• The circumstances of the violation
• Its effects
• The remedial measures taken
• The reasoning behind the decision regarding the report/notification
• The documentation serves as proof of compliance with the GDPR and may be subject to inspection by the supervisory authority.

Cross-border personal data breaches

A cross-border data breach is an incident that involves the processing of personal data in more than one member state of the European Union. This can be because the controller or processor has organisational units in several EU countries, or when the breach affects data subjects in different member states.

In the case of cross-border data breaches, the incident reporting and management process becomes more complex. Controllers must cooperate with supervisory authorities in different countries and also take into account differences in local regulations and procedures. It is crucial to quickly determine which supervisory authority is the lead authority in a given case and to ensure effective communication between all parties involved. The cross-border nature of the breach can also affect the risk assessment and the way in which data subjects are notified, especially when it is necessary to take into account cultural and linguistic differences in different countries.

Summary

Responding appropriately to personal data breaches is crucial to protecting the rights of data subjects. This requires controllers to:

• Implement appropriate safeguards
• Prepare incident response procedures
• Act quickly in the event of a breach
• Communicate transparently with the supervisory authority and data subjects

Remember that the main purpose of these measures is to protect the rights and freedoms of individuals, not to avoid penalties. A responsible approach to data protection builds trust and minimises the negative effects of possible violations.

Want to know more?

Read the new guide from the UODO (the Polish Data Protection Authority):

https://uodo.gov.pl/pl/138/3561

What’s new in the guide?

The new version takes into account the latest interpretations of regulations, case law and practical tips that will help administrators make the right decisions in the event of a personal data breach. It includes, among others:

• updated procedures for responding to breaches (reporting to the President of the Personal Data Protection Office);
• practical examples and case studies;
• guidelines on cooperation with the President of the Personal Data Protection Office and other supervisory authorities;
• key recommendations on risk assessment and breach prevention.

The post Data protection violations – what do you need to know? first appeared on Kancelaria LBKP.

DORA – new standards for cyber security

In the digital age, when most financial transactions take place online, the security of our data and funds is becoming a priority. We’ve all seen recently – with the example of Microsoft’s operating systems crashing – what happens when one of the more commonly used online services for business, Office 365, is affected.

Airline connections were cancelled, the London Stock Exchange did not work, and bank customers also reported problems (in Poland, Santander Bank and PKO BP, among others, were affected). Microsoft estimated that up to 8.5 million Windows devices were affected by the incident. The effects of what turned out to be ‘just’ a crash brought part of the world to a halt for a moment. The scale of the disruption to the operations of entities in many industries makes one wonder what might happen when we are dealing not with a crash, but with a successful cyber-attack.

The European Union, recognising the growing risks in the area of digital security for the financial sector and its customers, in December 2023 enacted the Digital Operational Resilience Act (DORA for short), which sets new standards for the cyber-security of financial entities, aiming to ensure their resilience to all ICT-related disruptions and threats.

The new regulations aim to:

Minimise the risks associated not only with cyber attacks, but more broadly with security incidents. By establishing uniform standards and procedures, DORA is expected to contribute to protecting the integrity, security and continuity of financial services in the European Union.

The countdown is on

Financial entities have until 17 January 2025 to comply with DORA. After this date, there will be no concessionary tariffs – the FSA, during trainings and meetings with the financial sector, warns that it will not wait for latecomers and plans to verify and enforce the implementation of the new obligations from day one.

Importantly, DORA is not a directive (as is the case with another cyber-security-relevant act such as NIS2), but a regulation. This means that it is binding in its entirety on the entities to which it is addressed and is directly applicable in all countries of the European Union, without the need to implement it into local legal orders by means of laws.

Who is affected by DORA?

DORA primarily – but not exclusively – covers a broad spectrum of financial institutions and digital finance entities. Among others, banks, insurance companies, investment funds, credit institutions, cryptocurrency providers, e-money institutions and other financial services providers are obliged to comply with the new regulations.

In addition, DORA introduces certain obligations for technology providers, including cloud service providers and other ICT service providers.

What does DORA mean for the financial sector?

DORA imposes obligations on financial sector players, requiring financial institutions not only to respond to incidents, but also to take a number of preventive measures, based on the principle that prevention is better than cure.

In practice, this means taking action primarily in the following key areas:

1. ICT risk management Instytucje finance should develop and implement a comprehensive ICT risk management strategy. This strategy should include identifying, assessing, monitoring and controlling ICT risks to ensure the security and integrity of IT systems.
2. ICT incident management Classification and reporting of ICT incidents are key to effective security management, according to DORA. Financial institutions will be required to follow clear guidelines for incident classification, which is expected to lead to appropriate tracking, analysis and response.Responsibilities in this area will include, but are not limited to:Creating and implementing uniform incident classification guidelines to categorise incidents by level of severity and type of threat.Regular reporting of incidents to relevant authorities and stakeholders, in accordance with applicable standards and regulations.Conducting root cause analysis of incidents to identify vulnerabilities and implement corrective actions.
3. Risk management from external ICT service providers Financial institutions should define policies for managing cooperation with external ICT service providers. Responsibilities in this area will include, among other things, developing criteria for the evaluation and selection of ICT service providers to ensure that they meet security and compliance requirements, ensuring that contracts entered into with ICT providers comply with the requirements set by DORA, and regularly monitoring and evaluating the performance of providers.
4. Operational digital resilience testing Obowiązki in this area will include, among other things, the establishment of a comprehensive operational digital resilience testing programme. Financial entities other than micro-enterprises will be required to test all ICT systems and applications at least once a year. For some obliged entities, DORA also provides for an additional obligation to carry out advanced penetration testing (TLPT) for threat searches at least every 3 years.

Where there are obligations, there are also sanctions

Understanding and adapting to the requirements of DORA are essential from the point of view of financial actors, not only for the need to ensure an adequate level of operational digital resilience, but also to avoid serious legal and financial consequences.

DORA implies that the competent authorities (in Poland this will primarily be the FSA) will be granted broad powers to supervise and enforce DORA. They will be entitled to request access to any documents and data they deem relevant in the context of their investigations. Financial institutions must be prepared for possible audits and inspections. Failure to cooperate or provide the requested information may lead to additional sanctions.

In the event of violations of DORA, various administrative sanctions may be applied by the supervisory authorities. These include, inter alia, cease and desist orders for non-compliant activities, the requirement to terminate practices contrary to the regulations and the application of financial sanctions aimed at enforcing compliance.

Summary

Of course, a full assessment of the impact of the new regulations will only be possible after some time, but we already dare to hypothesise that DORA is a milestone towards ensuring digital operational resilience in the EU financial sector. With the introduction of new ICT risk management standards and the requirement for a proactive approach to digital security, DORA should not only help protect financial institutions, but also increase customer confidence in financial services. The move is now on the side of the financial sector – achieving the goal of DORA and the associated benefits will only be possible if the implementation of the new regulations is taken seriously.

The post DORA on the horizon: key changes for the financial sector 🏦 first appeared on Kancelaria LBKP.

The end of 2024 is not only marked by whistleblowers, but also by ‘Cyber Security’. We owe this to the NIS 2 directive and the DORA regulation. Today, a few words about NIS 2.

By 17 October 2024, Poland must implement the EU NIS 2 Directive, which is intended to ensure the resilience of entities important from a public interest perspective to cyber threats. This requires the implementation of appropriate procedures and training, including: risk analysis and IT system security, incident handling, business continuity, crisis management, supply chain security and others.
NIS 2 will cover a number of entities that have not yet been regulated under NIS 1. According to the draft amendments to the National Cyber Security System Act (UKSC), entities that should be particularly interested in NIS 2 include:
Energy
Transport
Banking
Infrastructure financial markets
Protection health
Supply drinking water and its distribution
Digital infrastructure
Wastewater
Management IT services
Public sector
Space
Postal and courier services
Waste management
production manufacturing and distribution of chemicals
Production food processing and distribution
Production
Providers of digital services
Scientific research

The list is long . What’s more, the UKSC draft requires self-identification of entities that meet the criteria and registration in the relevant register.
The UKSC amendment, according to the draft, will come into force within one month of publication. This will not be sufficient time to fully implement the new obligations. Therefore, we are already proposing to audit and implement NIS 2 for our clients, based on the PN-EN ISO/IEC 27001, PN-EN ISO/IEC 22301 standards and market best practices. Once the legislation has been finalised, fine-tuning the procedures will be sufficient.

And you, are you ‘catching on’ to NIS2 and are you NIS-ready?

The post NIS 2 – New requirements first appeared on Kancelaria LBKP.