GDPR compliance and on-premise architecture

If you run a real-estate agency, an insurance broker, a travel agency, or any other firm subject to sanctions screening — you remain the sole controller of your customers' data. Sanqto only ships you a tool you run locally.

1. Zero data-processing agreements. Because Sanqto does not process your customers' data, there's no legal basis for a processing agreement under GDPR Art. 28. Your legal team has one moving part fewer.
2. Zero third-country transfers. GDPR Art. 44 only applies when data is transferred outside the EEA. In the on-premise model, data does not leave your network — in any direction. So there's nothing to assess under TIA (Transfer Impact Assessment), Schrems II, or SCCs.
3. Zero "shadow processor" risk. Cloud SaaS sanctions-screening vendors usually have sub-processors (CDN, hyperscalers, AI providers). Each of them widens the attack surface and demands review. With on-premise, that cascade does not exist.

Screening a customer against the EU sanctions list is a processing of personal data. The legal basis is GDPR Art. 6(1)(c) — compliance with a legal obligation to which the controller is subject. The specific sources of the obligation:

1. Art. 2 of Council Reg. (EU) 269/2014 — prohibition on making funds available to or providing services to listed persons,
2. Council Reg. (EU) 833/2014 — sectoral sanctions against Russia,
3. Art. 15 of the Polish Act of 13 April 2022 on special measures for preventing support for the aggression on Ukraine — the national obligation and the catalogue of penalties (up to PLN 20,000,000).

Practical consequences worth flagging:

1. screening does not require the customer's consent — Art. 6(1)(c) is an independent legal basis,
2. you discharge the information obligation (GDPR Art. 13) by stating the purpose "compliance with Reg. 269/2014" in your privacy policy,
3. retention of reports is 5 years — driven by AML and tax obligations, regardless of the data-minimisation principle in GDPR Art. 5.

Communication between the application and Sanqto's infrastructure is one-way — Sanqto server to your application.

1. FIU, tax authority, DPA. Reports generated by the application include a timestamp, the Reference List version, the operator identifier, and the input file hash. The format meets inspection expectations.
2. 5-year archive. The application stores reports locally — in a directory you specify. Sanqto recommends keeping them on an encrypted volume with offsite backup.
3. Audit on Sanqto's side. Enterprise customers can request the penetration-test report for Sanqto's distribution infrastructure, ISO 27001 certificates (after they're obtained), and the list of sub-processors handling Sanqto's contact data.

Sanqto removes most of the compliance friction, but a few things still sit on your side:

1. add "Screening customers against EU sanctions lists" with GDPR Art. 6(1)(c) as the basis to your Records of Processing Activities,
2. add the activity to your privacy policy (purpose, basis, 5-year retention),
3. document in your internal AML / sanctions procedure who handles a hit and how the FIU notification is filed within 24 hours,
4. secure the device running the application locally (access control, disk encryption, backups of the report directory),
5. limit application permissions to a minimum group of staff and keep an access log.

Need help rolling these out? The Enterprise tier includes a dedicated CSM and team training — book a deployment call.

For GDPR and security architecture matters: privacy@sanqto.com.

The full data-processing rules are in the Privacy policy.