Sanction screening and GDPR — how to reconcile verification with personal data protection

Legal status as of: 2026-05-20.

You are required to screen counterparties and customers against EU sanctions lists — and yet you have heard that you cannot simply “dig around in other people’s data”. This is a common concern among business owners outside the financial sector. The good news: these two obligations — sanctions compliance and personal data protection — are not in conflict. The General Data Protection Regulation (GDPR) expressly anticipates situations in which you process data because the law requires you to do so.

TL;DR

• Sanction screening is the processing of personal data, but it has a clear legal basis under the GDPR — Article 6(1)(c) (legal obligation of the controller).
• The obligation to screen derives from EU regulations that apply directly in Poland, including Council Regulation (EU) No 269/2014¹ and No 833/2014² — you do not need the consent of the person being verified.
• You collect only the data that is necessary for identification — the principle of data minimisation.
• You have an information obligation, but with exceptions — where providing information would undermine the purpose of the processing.
• You retain verification results for as long as required by law or a legitimate interest — as a rule, no less than for the duration of the business relationship.
• An on-premise solution means that data never leaves your infrastructure — making it simpler to demonstrate GDPR compliance.

Is sanction screening the processing of personal data?

Yes — without exception. When you enter a counterparty’s or customer’s name or identification number into a system that checks sanctions lists, you are processing personal data within the meaning of the GDPR. This is true even when you do it once, on a one-off basis, before signing a contract.

The GDPR defines processing broadly: it covers any operation performed on personal data — collecting, storing, consulting, comparing. Checking whether a given individual appears on the EU Consolidated List³ or the list maintained by the Ministry of Interior and Administration (MSWiA)⁴ satisfies that definition. The fact that you are “merely comparing” is irrelevant — it is still processing.

Many companies postpone implementing screening for this very reason, fearing they will breach the GDPR. That is a mistake in the opposite direction. Failing to screen exposes you to liability under EU sanctions regulations — and the administrative penalty for breaching their provisions can reach PLN 20,000,000⁵ (imposed by the Head of the National Revenue Administration — Szef Krajowej Administracji Skarbowej, KAS⁶).

Legal basis for processing — the controller’s legal obligation

The GDPR does not prohibit the processing of data — it merely requires you to have a legal basis for doing so. In the case of sanction screening, that basis is Article 6(1)(c) of the GDPR: processing is necessary for compliance with a legal obligation to which the controller is subject.

Where does that legal obligation come from? Directly from Council regulations of the European Union. EU regulations apply directly in every Member State — without any need for a separate implementing act at national level⁷. Regulation 269/2014¹ and Regulation 833/2014² impose on every entity — including non-financial businesses — a prohibition on conducting transactions with sanctioned persons and entities. To comply with that prohibition, you must screen. To screen, you must process data.

The same logic applies to the Act of 13 April 2022 on special solutions to counter the support of aggression against Ukraine and to protect national security (Journal of Laws 2022 item 835)⁸ — a Polish regulation that supplements the EU sanctions regime.

An important practical point: you do not need to ask your counterparty for consent to process their data for screening purposes. Consent (Article 6(1)(a) GDPR) is voluntary and can be withdrawn — whereas screening must be possible regardless of whether the counterparty “wishes” to be checked. The basis under Article 6(1)(c) eliminates this problem: you have a legal obligation, so you have the right to process.

It is also worth noting that Regulation 833/2014 covers not only individuals on the list but also entities in which a listed person holds more than 50% of ownership rights or exercises control over them⁹. Verifying shareholders involves processing data about additional individuals — and the same legal basis (Article 6(1)(c)) covers that too.

The data minimisation principle in screening

Having a legal basis allows you to process data — but it does not give you the right to collect everything you possibly can. The GDPR requires you to limit the scope of data processed to what is necessary to achieve the purpose. In the case of sanctions screening, the purpose is specific: to check whether a given person or entity appears on sanctions lists.

What does this mean in practice? For verification you need identifiers sufficient to unambiguously identify the subject:

• Natural persons: first name, surname, date of birth, optionally country of residence or nationality.
• Legal persons: full company name, country of establishment, identification number (Polish NIP, KRS number, or foreign equivalent).

You do not collect the counterparty’s purchase history, health data, or anything else that is not required to verify their identity. Data minimisation is not only an obligation — it also simplifies the process. The less data you hold, the smaller the surface area for potential security issues.

In practice, a well-designed sanctions screening system enforces minimisation by design: it accepts defined identification fields, compares them against the list, and returns a result. It does not record data it does not need.

The information obligation towards counterparties and customers

The GDPR requires a controller to inform individuals whose data it processes — including about the purpose and legal basis of the processing. That is the general rule. Meeting it in the context of screening is simpler than it may seem.

In most business situations, information about screening can and should be included in the information clause in a contract or terms of service. If a counterparty signs a contract with you, add a paragraph stating that identification data are processed for the purpose of verification against sanctions lists on the basis of applicable EU regulations. That is sufficient.

There are, however, situations in which full disclosure could conflict with the purpose of screening. The GDPR allows for restrictions on the information obligation where providing information would impede the achievement of that purpose — for example, where a counterparty is suspected of connections to a sanctioned entity and prior notification could lead to deliberate evasion. Any decision to rely on this exception should be documented and justified.

A practical rule: describe screening in your general information clause (privacy policy, contract template). You do not need to send a separate letter to every counterparty before each check.

How long to retain verification results

Sanction screening is not a one-off activity — the verification result forms part of your compliance documentation. The question arises: how long should results be kept?

No sanctions legislation expressly specifies a retention period for the hits register. The general GDPR principle applies: you retain data no longer than is necessary for the purposes for which it is processed. At the same time, the law requires you to have documentation available in the event of an inspection or administrative proceedings.

In practice, this means at least two reference periods:

1. For the duration of the business relationship — while actively working with a counterparty, you verify them on a regular basis and retain the results as evidence of due diligence.
2. After the relationship ends — you retain verification documentation for a period commensurate with the risk of liability: by analogy with limitation periods for claims or administrative proceedings, which in the Polish legal order is typically 5 years.

The specific retention period should be set out in your internal sanctions policy and be proportionate to the scale of your activities and the level of risk. Important: if you maintain a hits register (MATCH or POSSIBLE), those records carry particular evidential weight — do not delete them without a considered justification. What fields the register should contain and how long to retain it is covered in the article Sanctions hits register — how to maintain it.

Read more about the counterparty verification process step by step in our guide.

Why on-premise is advantageous for GDPR compliance

When you use a cloud-based screening system, the personal data of your counterparties is transferred to the provider’s servers — that is, to an external processor. Under the GDPR, you are required to conclude a Data Processing Agreement (DPA) with that processor, and if the provider’s servers are located outside the European Economic Area (EEA) (for example, in the United States), requirements relating to the transfer of data to third countries also apply.

An on-premise solution reverses this arrangement. The screening system is installed in your infrastructure — on your servers or those of your data centre. The personal data of your counterparties does not leave your organisation. You do not transfer it to anyone. The only place it is processed is within your own organisation — where you are the controller.

From a GDPR perspective, this is a significant simplification:

• No need to conclude a DPA with the screening provider.
• No risk of data transfer outside the EEA.
• Easier demonstration of control over data in the event of an inspection by a supervisory authority.

Sanqto operates on an on-premise model — the system is installed in the client’s network, and counterparty and customer data remains exclusively under the client’s control. The verification result is returned in three states: MATCH, POSSIBLE, or CLEAR, enabling rapid classification without exporting personal data externally.

If you operate in the insurance or real estate sector — industries particularly sensitive to client data protection — on-premise architecture is a solution worth considering. Read more about sanctions screening for insurance companies and real estate agencies.

False positives and personal data — caution in classification

A false positive is a situation in which the system returns a MATCH or POSSIBLE result for a person who is not a sanctioned entity — for example because they share a name with someone on the list. This is technically unavoidable in any screening system that operates on the basis of text matching.

The problem is that incorrect classification leads to the processing of the personal data of a person unconnected to sanctions in a context that may harm them — refusal to conclude a contract, blocking of a payment, a flag in the register. This creates a risk of infringing that person’s rights under the GDPR.

Several principles help to limit this risk:

Do not make automated decisions based solely on the algorithm. The GDPR expressly restricts decisions based solely on automated processing where the decision produces significant effects. A POSSIBLE or MATCH result should be reviewed by a human — a compliance officer or the person responsible for this process. How to resolve such cases methodically is covered in the article on false positives in sanctions screening.

Document the determination. When your analysis establishes that a hit is a false positive, record that conclusion in the register. This is your evidence of due diligence — both before the Head of KAS in the event of a sanctions inspection, and before the Office for Personal Data Protection (UODO — Urząd Ochrony Danych Osobowych) in the event of a complaint from the individual whose data you processed.

Retain data from a false positive only for as long as necessary. If you determine that a POSSIBLE result is an error, and the business relationship with the counterparty is proceeding normally, consider deleting or anonymising the record once the review process is complete — unless legislation requires the documentation to be retained for a specific period.

Learn more about how the sanction screening process works and how to classify verification results.

FAQ

Do I need the counterparty’s consent to check them against a sanctions list?

No. The legal basis for processing data in sanctions screening is a legal obligation (Article 6(1)(c) GDPR), not consent. Consent is voluntary and revocable — it is not a suitable basis for verification that you are required to carry out regardless of the counterparty’s wishes. EU regulations — such as 269/2014¹ and 833/2014² — are binding on you directly, without any choice on your part in the matter.

What should I include in the information clause about screening?

State the purpose of processing (verification against sanctions lists), the legal basis (compliance with a legal obligation arising from EU regulations), the categories of data processed (identification data: first name, surname, company name, identification numbers) and the retention period. You do not need to list every sanctions list by name — a general formula referring to “sanctions lists in force under EU law and national law” is sufficient.

What should I do if a counterparty requests deletion of their data after the relationship ends?

You may refuse — or defer compliance with the request — if legislation requires you to retain documentation for a specific period. Invoke the legal obligation and state the estimated retention period. If a deletion request is received during an active business relationship when screening is still required, you may refuse, explaining that processing the data is necessary to fulfil a legal obligation.

Do I need to notify UODO (the Polish data protection authority) of processing for screening purposes?

In most cases, no — the general obligation to register processing with a supervisory authority was abolished when the GDPR came into force. You are, however, required to maintain your own Record of Processing Activities (if you employ more than 250 people, or where the processing is likely to result in a risk to individuals’ rights) and to include sanctions screening as a separate processing activity within it.

Does on-premise exempt me from GDPR obligations towards employees who operate the system?

No. Data held in an on-premise system is still processed by you — you are the controller. You therefore have all the obligations of a controller: the information obligation, appropriate technical and organisational security measures, and responding to requests from individuals exercising their rights. On-premise only eliminates the need to entrust data to an external software provider.

What if my counterparty is a foreign company? Does GDPR still apply?

Yes, if the entity being processed is established or resident in the EEA, or if your company is established in Poland. The GDPR has a broad territorial scope. At the same time, the sanctions obligation — arising from EU regulations and the Act of 13 April 2022⁸ — covers every transaction carried out by an entity operating in Poland, regardless of the nationality of the other party.

What to do — a step-by-step checklist

1. Inventory your processing activities. Add a new entry to your Record of Processing Activities: “Verification of counterparties and customers against EU and national sanctions lists”. State the purpose, legal basis (Article 6(1)(c) GDPR), scope of data and planned retention period.

2. Update your information clause. Add a paragraph to your contract template, terms of service, or privacy policy covering the processing of identification data for sanctions screening purposes. This is sufficient in the vast majority of cases.

3. Limit the scope of data collected. Check what data your system actually needs to perform verification. Remove fields that you collect but do not use in the screening process.

4. Introduce a false positive handling procedure. Designate a person responsible for manual review of MATCH and POSSIBLE results. Draft a template explanatory note and incorporate it into the hits register.

5. Establish a retention policy for results. Decide and document how long you will retain verification results — separately for CLEAR results (shorter period) and for MATCH and POSSIBLE results (longer period, as evidential documentation).

6. Assess the architecture of your system. If you use a cloud-based tool, ensure that you have a current DPA with the provider and check the location of the servers. If data is processed outside the EEA — assess the risk and the transfer mechanisms in place.

7. Align your sanctions policy with your privacy policy. Both policies should be consistent: the sanctions procedures describe how you verify; the privacy policy describes why and on what basis you process data during that verification.

How Sanqto can help

Sanqto is sanctions screening software installed directly in your infrastructure — the on-premise model means that counterparty and customer data never leaves your company’s network. You thereby eliminate the need to entrust data to an external processor. The system returns a result in three states — MATCH, POSSIBLE, or CLEAR — giving you a clear basis for decision-making and documentation in the hits register. The implementation package includes ready-made document templates: a sanctions policy, a hits register, and a false positive handling procedure — ready to be adapted to your business profile. Read what the sanction screening obligation is and who it applies to before deciding on a tool.

Legal basis

• Council Regulation (EU) No 269/2014 of 17 March 2014 concerning restrictive measures in respect of actions undermining or threatening the territorial integrity, sovereignty and independence of Ukraine — CELEX 32014R0269
• Council Regulation (EU) No 833/2014 of 31 July 2014 concerning restrictive measures in view of Russia’s actions destabilising the situation in Ukraine — CELEX 32014R0833
• Act of 13 April 2022 on special solutions to counter the support of aggression against Ukraine and to protect national security (Journal of Laws 2022 item 835) — ISAP
• Council Regulation (EU) No 765/2006 of 18 May 2006 concerning restrictive measures in respect of Belarus — CELEX 32006R0765
• EU Consolidated List (FSD) — published by the European Commission (DG FISMA) — finance.ec.europa.eu
• Polish sanctions list maintained by MSWiA (Ministry of Interior and Administration) — gov.pl/web/mswia/lista-osob-i-podmiotow-objetych-sankcjami
• Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016 (GDPR) — CELEX 32016R0679

Footnotes

Information, not legal advice. This article is for informational and educational purposes only. It does not constitute legal advice. Legal status as of: 20 May 2026. Your company’s specific obligations depend on your business profile and require individual assessment — if in doubt, consult a lawyer or compliance adviser.