NalevingLeestijd: 15 minuten

    Software van Russische oorsprong in EU-camerabewakingsprojecten (2026): naleving, sancties en beoordeling van aanbestedingen

    Een feitelijk, op aanbestedingen gericht overzicht voor CCTV-ontwerpers, -integratoren en EU-aanbestedende instanties die in 2026 steeds dezelfde terugkerende vraag stellen: hoe zijn de regels inzake herkomst, sancties en dataresidentie van toepassing wanneer CCTV-ontwerpsoftware betrokken is? Dit artikel vat het openbaar beschikbare kader samen. Het is geen juridisch advies – elke concrete aanbestedingsbeslissing dient te worden bevestigd door een gekwalificeerde aanbestedingsjurist.

    Belangrijk: dit is een feitelijke beoordeling, geen juridisch advies.

    Sancties, exportcontroles en aanbestedingsregels wijzigen regelmatig en worden in de verschillende EU-lidstaten verschillend geïnterpreteerd. Niets in dit artikel mag worden beschouwd als juridisch advies voor een specifieke transactie. Raadpleeg voor bindende uitspraken een gekwalificeerde aanbestedingsadvocaat in het betreffende rechtsgebied. Verwijzingen naar openbaar beschikbare normen, regelgeving en jurisprudentie zijn naar ons beste weten correct per mei 2026.

    Waarom deze vraag van belang is voor EU-aanbestedingen in 2026

    Sinds 2022 heeft de EU meerdere opeenvolgende sanctiepakketten tegen Rusland aangenomen, parallel aan veranderingen in de aanbestedingsregels van de lidstaten. Het cumulatieve effect hiervan op de software-aanbesteding is aanzienlijk: aanbestedende instanties die voorheen niet naar de herkomst van software vroegen, nemen nu standaard eisen op in de kwalificatiefase, en biedingen die geen bewijs van niet-gesanctioneerde herkomst kunnen leveren, worden vaak al vóór de commerciële beoordeling afgewezen.

    Software voor het ontwerpen van CCTV-systemen valt in een specifieke risicocategorie, omdat de documenten die het produceert – plattegronden, cameraplaatsing, netwerktopologie, BOM – zowel vanuit veiligheids- als operationeel oogpunt gevoelig zijn. Zelfs wanneer een sanctie-instrument een specifiek CCTV-planningsinstrument niet expliciet omvat, hanteren opdrachtgevers doorgaans een voorzorgsbeginsel, met name in de defensie-, overheids-, kritieke infrastructuur- en grote zorg- of transportprojecten.

    Dit artikel is de uitleg die we graag hadden gehad toen integratorklanten ons voor het eerst vroegen naar de herkomst van software in offertes. Het is beschrijvend, niet voorschrijvend – het doel is om het kader in begrijpelijke taal uiteen te zetten, zodat een CCTV-ontwerper de juiste vragen aan zijn inkoopadviseur kan stellen, en niet om dat gesprek te vervangen.

    Het huidige EU-sanctiekader: een samenvatting op hoog niveau.

    De restrictieve maatregelen van de EU tegen Rusland worden geïmplementeerd via verordeningen van de Raad, gepubliceerd in het Officiële Journal van de Europese Unie en bijgewerkt door middel van opeenvolgende wijzigingspakketten. Het kader is gebaseerd op drie brede pijlers die relevant zijn voor de aanbesteding van software.

    Drie pijlers die relevant zijn voor software

    • Exportcontrole. Beperkingen op de levering van specifieke goederen, diensten, technologie en software aan Rusland, met een sectorale focus op dual-use, defensie en bepaalde industriële categorieën.
    • Financiële sancties. Vermogensbevriezing en verboden op het beschikbaar stellen van geld of economische middelen aan beursgenoteerde personen en entiteiten. De toets van "eigendom en zeggenschap" is afhankelijk van de specifieke omstandigheden en geldt zelfs wanneer een leverancier zelf niet beursgenoteerd is, maar wel eigendom is van of gecontroleerd wordt door een beursgenoteerde entiteit.
    • Filters voor overheidsaanbestedingen. Bepalingen in Verordening (EU) 833/2014 van de Raad (zoals gewijzigd) die de gunning van overheidsopdrachten aan bepaalde Russische personen en entiteiten verbieden, zijn op verschillende manieren omgezet en aangevuld door de aanbestedingswetgeving van de lidstaten.

    Naast het EU-brede kader hebben lidstaten zoals Duitsland, Frankrijk, Polen, de Scandinavische landen en de Baltische staten hun eigen aanbestedingsregels met strengere criteria ingevoerd. Het gevolg hiervan is dat dezelfde leverancier in het ene EU-land acceptabel kan zijn en in een ander land kan worden afgewezen, zelfs als deze leverancier in geen enkel instrument expliciet wordt genoemd. Aanbestedingsteams hanteren daarom vaak de strengste regels van de betreffende lidstaat als interne maatstaf.

    Amerikaanse zijde: NDAA §889 en uitvoeringsbesluiten inzake ICTS

    Aan Amerikaanse zijde worden twee instrumenten, zelfs door EU-aanbestedingsfunctionarissen, routinematig aangehaald als informele referentiepunten. Artikel 889 NDAA (de John S. McCain National Defense Authorization Act voor het fiscale jaar 2019) verbiedt federale instanties en federale contractanten om telecommunicatie- en videobewakingsapparatuur van bepaalde Chinese fabrikanten te kopen of te gebruiken. De uitvoeringsbesluiten inzake informatie- en communicatietechnologie en -diensten (ICTS), met name uitvoeringsbesluit 13873 en opvolgende besluiten, geven het Amerikaanse ministerie van Handel ruime bevoegdheden om transacties met buitenlandse tegenstanders te beoordelen.

    Geen van beide instrumenten is wettelijk van toepassing op een typische EU-aanbesteding. Ze worden echter vaak gebruikt als standaardformulering in aanbestedingsdocumenten. Een EU-aanbestedingsautoriteit die een aanbesteding voor CCTV-systemen opstelt, zal doorgaans van de leverancier eisen dat deze verklaart dat zijn software, hosting en personeel niet zouden worden uitgesloten op grond van regels die gelijkwaardig zijn aan §889, zelfs wanneer §889 zelf irrelevant is voor het contract. Leveranciers die deze verklaring niet kunnen afleggen, hebben een concurrentienadeel, ongeacht de onderliggende wettigheid van hun aanbod.

    Directe impact van inkoop op CCTV-ontwerpsoftware

    De onderstaande categorieën zijn de vier waarin we het vaakst vragen over de oorsprong van software zien opduiken in EU-camerabewakingsprojecten voor 2026.

    Aanbestedingen in de publieke sector

    Aanbestedingen voor de overheid, defensie, gezondheidszorg en het onderwijs bevatten steeds vaker expliciete clausules over de herkomst van software. De aanleiding hiervoor is meestal een van de hierboven besproken selectiebepalingen voor aanbestedingen, die via nationale omzetting worden toegepast. Zelfs waar de juridische drempel discutabel is, is de praktijk dat biedingen die geen acceptabele herkomst kunnen aantonen, in de kwalificatiefase worden afgewezen. Ontwerpers die in 2026 inschrijven op aanbestedingen in de publieke sector, moeten rekening houden met de verplichting om voor elke softwaretool die in het ontwerpproces wordt gebruikt, een verklaring over de herkomst af te leggen, niet alleen voor de bewakingshardware zelf.

    Contracten voor kritieke infrastructuur

    De aanbesteding van energie, transport, bankwezen en waterbedrijven wordt geregeld door NIS2 (Richtlijn (EU) 2022/2555) en overlappende sectorale regels. Hoewel NIS2 zelf risicogebaseerd is in plaats van op herkomst gebaseerd, wordt de herkomst van de toeleveringsketen in de resulterende risicobeoordelingen doorgaans als een relevante factor aangemerkt. Exploitanten van essentiële diensten hebben dit dan ook in hun aanbestedingskaders opgenomen. De eisen voor bewijs van de herkomst van software bij kritieke infrastructuurprojecten liggen aanzienlijk hoger dan bij algemene commerciële aanbestedingen.

    Compliance-audits voor particuliere ondernemingen

    Grote ondernemingen met eigen ESG-, toeleveringsketen- of cyberrisicokaders controleren routinematig hun leveranciers en onderleveranciers. Zelfs als er geen specifieke aanbesteding aan te pas komt, kan een integrator die software gebruikt waarvan de herkomst niet kan worden aangetoond, tijdens een jaarlijkse evaluatie van de lijst met voorkeursleveranciers worden verwijderd. Deze dynamiek is in 2024 en 2025 merkbaar versneld en zet zich voort in 2026.

    Grensoverschrijdende samenwerkingen met integratoren

    Integrators met activiteiten in zowel EU- als niet-EU-landen worden geconfronteerd met extra complexiteit, omdat de aanbestedingsnormen verschillen. Een tool die acceptabel is voor een particulier commercieel project in het ene land, voldoet mogelijk niet aan de aanbestedingseisen voor een publiek project in een ander land. Veel integrators hebben dit opgelost door voor alle projecten te standaardiseren op tools van EU-oorsprong, waardoor de reactie op toekomstige aanbestedingen, ongeacht waar deze plaatsvinden, wordt vereenvoudigd.

    Hoe kopers de herkomst van software controleren

    Een inkoopmedewerker die een herkomstcontrole uitvoert, beschikt over een vrij standaard instrumentarium. Geen van deze controles bewijst op zichzelf de herkomst; ze vormen een beeld aan de hand van verschillende openbare gegevens.

    • WHOIS-registratie van het domein van de leverancier — registrarland, registrantorganisatie, nameserver ASN.
    • Door de leverancier moet de naam van de juridische entiteit, het land van registratie en het belastingnummer worden vermeld — dit is doorgaans vereist bij de kwalificatie.
    • Beoordeling van de hostingprovider — de cloudregio waar de SaaS-infrastructuur fysiek draait, zoals blijkt uit een attest of een hostingovereenkomst met een derde partij.
    • Openbare bedrijfsdocumenten — registers van uiteindelijke begunstigden, structuur van het moederbedrijf en eventuele verwijzingen naar sanctielijsten.
    • Verklaring van de toeleveringsketen — een schriftelijke verklaring van de leverancier waarin wordt beschreven waar de software wordt ontwikkeld, gehost en ondersteund, en waarin eventuele subverwerkers worden genoemd.

    Bij aanbestedingen met een hoger risico (defensie, kritieke infrastructuur) kan de beoordeling worden uitgebreid met onderzoek naar de herkomst van de broncode, beveiligingstests door derden en een onafhankelijk juridisch advies. De meerkosten van een dergelijke beoordeling op hoger niveau zijn niet gering en aanbestedende instanties laten deze doorgaans alleen uitvoeren als de waarde of gevoeligheid van het contract dit rechtvaardigt.

    GDPR aspect van gegevensoverdracht naar derde landen

    De artikelen 44 tot en met 49 GDPR regelen de overdracht van persoonsgegevens naar landen buiten de Europese Economische Ruimte. De standaardregel is dat een dergelijke overdracht verboden is, tenzij een van de volgende waarborgen van toepassing is: een adequaatheidsbesluit van de Europese Commissie, een goedgekeurd overdrachtsmechanisme zoals standaardcontractbepalingen met passende aanvullende maatregelen, of een uitzondering voor specifieke situaties.

    Het Europees Hof van Justitie heeft in de zaak Schrems II (C-311/18, 2020) duidelijk gemaakt dat standaardcontractbepalingen moeten worden aangevuld met een effectbeoordeling van de gegevensoverdracht, waarbij rekening wordt gehouden met de wetgeving van het land van bestemming en of deze een wezenlijk gelijkwaardige bescherming biedt. Rusland staat niet op de adequaatheidslijst van de Europese Commissie en de gangbare opvatting is dat het moeilijk is om een "wezenlijk gelijkwaardige" bescherming te bereiken voor gegevensoverdrachten naar Rusland, gezien het juridische kader aldaar. Het praktische gevolg hiervan is dat elke tool voor het ontwerpen van CCTV-systemen die persoonsgegevens verzendt naar servers in Rusland, of naar entiteiten onder Russisch toezicht, te maken krijgt met een aanzienlijke effectbeoordeling van de gegevensoverdracht, iets wat voor tools die in de EU worden gehost simpelweg niet het geval is.

    Voor CCTV-projecten is dit belangrijk omdat ontwerptools vaker persoonsgegevens verwerken dan mensen beseffen – projectmetadata, informatie over de locatie van de eindgebruiker, e-mailadressen van accounts, inhoud van supporttickets. Een opdrachtgever die GDPR serieus neemt, wil er zeker van zijn dat geen van deze gegevens de EU/EER verlaat op een manier die aanleiding geeft tot onderzoek op grond van hoofdstuk V.

    Waarom CCTVplanner bestaat — gehost en ontwikkeld door de EU

    CCTVplanner wordt beheerd door DEFENSAR, een in Polen geregistreerd bedrijf, met de frontend gehost in Polen en de backend op een cloudinfrastructuur in de EU. Dat is de betekenis van de slogan "100% Engineered and Hosted in EU" — de juridische entiteit, de ontwikkeling en de hosting bevinden zich allemaal binnen de Europese Unie, en er zijn geen subverwerkers uit derde landen in de standaardarchitectuur.

    Voor inkoopteams vertaalt dit zich in een kort, eenduidig antwoord op de hierboven beschreven vragen over de herkomst van gegevens. Er is nergens in het gegevenspad sprake van een subverwerker onder Russisch, Chinees of Amerikaans recht. Er is geen verplichting tot het uitvoeren van een impactbeoordeling van de gegevensoverdracht onder hoofdstuk V GDPR, omdat de gegevens de EU niet verlaten. Er is geen diskwalificatie op grond van artikel 889 van de AVG van toepassing op de toeleveringsketen. De EU-standaardarchitectuur, die door integrators over de hele wereld wordt vertrouwd, is het kenmerk dat in 2026 het vaakst ter sprake komt in inkoopgesprekken.

    EU-standpunt in één alinea

    • De operationele entiteit DEFENSAR is geregistreerd en fiscaal gevestigd in Polen.
    • Frontend gehost in Polen; backend op een cloud in de EU-regio (eu-west).
    • Geen subverwerkers van gegevens uit derde landen in de standaardarchitectuur.
    • Voldoet standaard aan GDPR — er is geen aparte effectbeoordeling van de gegevensoverdracht vereist voor kopers uit de EU.

    De realiteit van "Overstappen van JVSG "

    Een praktische vraag die we in 2026 vaak horen van installateurs is: "We zijn tevreden met onze huidige tool voor het ontwerpen van CCTV-systemen, maar het inkoopteam heeft de openbaarmaking van de software-oorsprong als een risico aangemerkt. Hoe ziet een overstap eruit?" Het antwoord is grotendeels mechanisch: exporteer de plattegrond naar DXF, importeer deze in CCTVplanner, vervang camera's uit een catalogus met meer dan 65.000 modellen, pas DORI drempelwaarden aan, verleg de bekabeling en exporteer het meerpagina's tellende PDF document. We hebben een stapsgewijze handleiding geschreven in de migratiegids die hieronder is gelinkt. Geen van de stappen is bijzonder moeilijk. Het moeilijkste is over het algemeen de beslissing om over te stappen, niet de overstap zelf.

    Voor door inkoop gedreven overstappen adviseren wij specifiek om de overgang schriftelijk vast te leggen: de aanleiding, de geëvalueerde alternatieven, de gekozen vervanging en de datum waarop de bestaande tool uit de workflow wordt verwijderd. Zowel inkoopadviseurs als ESG-auditors waarderen gedocumenteerde beslissingen, en een schriftelijk overgangsverslag is een veelvoorkomend document in due-diligence-dossiers.

    Afsluitende disclaimer

    Dit artikel is een feitelijke analyse gebaseerd op openbaar beschikbare normen, regelgeving en jurisprudentie zoals die golden in mei 2026. Het is geen juridisch advies en het is geen vervanging voor advies van een gekwalificeerde aanbestedingsjurist in uw rechtsgebied. Sancties, exportcontroles en aanbestedingsregels veranderen regelmatig en worden in de verschillende EU-lidstaten anders geïnterpreteerd. Elke concrete aanbestedingsbeslissing dient te worden bevestigd door een jurist die bekend is met de specifieke aanbestedende instantie, sector en het betreffende rechtsgebied.

    Geen enkele uitspraak in dit artikel is bedoeld als een belediging van welk land, bedrijf of categorie leveranciers dan ook. Het doel is om het inkoopkader te beschrijven zoals kopers dat in 2026 ervaren, zodat integrators offertes kunnen voorbereiden en workflows kunnen ontwerpen die de kwalificatiefase doorstaan.

    Veelgestelde vragen

    Is software of Russian origin banned from EU public procurement in 2026?

    There is no single blanket EU rule that says "all software of Russian origin is banned". Instead, several layered EU instruments — sanctions regulations, public-procurement rules, sectoral export controls and member-state interpretations — combine to make Russian-origin software difficult or impossible to procure in many specific contexts (defence, public administration, critical infrastructure, financial services). Whether your specific procurement is permitted depends on the contracting authority, the sector and the country. Always consult your in-house counsel or external procurement advisor for a binding determination.

    Does the EU sanctions framework apply to design software, not just hardware?

    Sanctions instruments commonly cover "goods, services, technology and software" — software is treated as a category of its own, separate from physical hardware. Whether a particular CCTV design tool falls inside or outside a specific sanctions instrument is a fact-specific legal question. Public-sector tenders increasingly include explicit "software origin" disclosure requirements, and a vendor unable to evidence non-Russian origin is usually filtered out at the qualification stage regardless of the underlying sanctions analysis.

    How does GDPR interact with Russian-hosted software?

    GDPR Articles 44 to 49 govern personal-data transfers to third countries. Russia is not on the European Commission's list of countries with an adequacy decision, and standard contractual clauses to Russian processors face additional scrutiny under the Schrems II reasoning of the European Court of Justice. In practice this means that any CCTV design tool that transmits personal data — project metadata, account information, customer-site details — to servers in Russia or to entities under Russian jurisdiction faces a meaningful GDPR transfer-impact assessment burden that EU-hosted tools do not.

    What is NDAA §889 and does it apply outside the United States?

    NDAA §889 is a US federal procurement rule that prohibits federal agencies and federal contractors from buying or using telecommunications and video-surveillance equipment from certain named Chinese companies. It is a US instrument with US scope, but it is increasingly cited as a procurement template by EU and UK contracting authorities updating their own rules. Procurement officers in 2026 routinely ask vendors whether their products would qualify under §889 even when §889 itself does not legally apply to the contract.

    What practical due-diligence does a procurement team perform on software origin?

    Standard checks include WHOIS lookups on the vendor domain, verification of the legal entity name and registration country, review of hosting providers (where the SaaS infrastructure physically runs), inspection of public corporate filings, and a request for a written supply-chain attestation from the vendor. For higher-risk procurements (defence, critical infrastructure) the assessment can extend to source-code provenance, third-party penetration testing, and an independent legal opinion. None of this is a substitute for advice from procurement counsel, which is why the recurring recommendation in this article is to consult one.

    © 2026 CCTVplanner. Alle rechten voorbehouden.