Technische en organisatorische maatregelen

Dit document is in meerdere talen gepubliceerd. Bij verschillen tussen de taalversies is de Poolse versie bindend.

Versie 1.1 · Laatst bijgewerkt: 22 oktober 2026

Maatregelen op grond van Art. 32 AVG waarmee LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Polen, de dienst formexposed beschermt. Deze pagina maakt als Bijlage 2 deel uit van de Verwerkersovereenkomst.

1. Toepassingsgebied en uitgangspunt

De maatregelen gelden voor alle gegevens die de dienst verwerkt: voor de gegevens die wij namens onze Klanten verwerken (beschreven in de Verwerkersovereenkomst), en voor de gegevens waarvoor wij zelf de verwerkingsverantwoordelijke zijn, zoals klantaccounts en logs. Er zijn geen afzonderlijke beschermingsniveaus voor beide; wat het account beschermt, beschermt ook de verwerkersgegevens.

Opbouw volgens Art. 32(1) AVG. Pseudonimisering en versleuteling (punt (a)) worden behandeld in paragraaf 4; de blijvende vertrouwelijkheid, integriteit, beschikbaarheid en veerkracht van de systemen (punt (b)) in de paragrafen 3, 5, 6 en 7; het vermogen om na een incident de beschikbaarheid tijdig te herstellen (punt (c)) in paragraaf 7.1; de procedure voor het regelmatig testen, beoordelen en evalueren van de doeltreffendheid (punt (d)) in paragraaf 9. Wij hebben de maatregelen gekozen op basis van de risico’s die zijn beschreven in onze Gegevensbeschermingseffectbeoordeling, rekening houdend met de stand van de techniek en de uitvoeringskosten.

Uitgangspunt: gemeten in plaats van bedoeld. Hier staat alleen wat daadwerkelijk in de code of in de bedrijfsvoering is geïmplementeerd. Wat gepland maar nog niet geïmplementeerd is, staat in paragraaf 10 uitdrukkelijk als “gepland” vermeld. Een maatregel die hier ontbreekt, is niet stilzwijgend aanwezig.

Namen van machines, interne adressen, poorten, gebruikersnamen en softwareversies worden bewust niet vermeld. Ze helpen niemand de maatregelen te beoordelen, maar wel iemand die ze wil omzeilen. Wie ze voor een audit op grond van de Verwerkersovereenkomst nodig heeft, ontvangt ze in het kader van die audit onder geheimhouding, voor zover ze voor de audit noodzakelijk zijn.

2. Opbouw van de dienst

De dienst draait op twee eigen servers van de aanbieder in Polen, die zich in hetzelfde interne netwerk bevinden:

Webserver met database. Deze levert de applicatie, bevat de database, verstuurt meldingen en maakt back-ups van de gegevens. Alleen deze server is ingericht om verzoeken vanaf het internet te accepteren.
Scanserver. Deze voert de controles van websites van derden en eigen websites in een browser uit en draait het taalmodel dat afzonderlijke formulieren classificeert en in “Fix it for me” code toevoegt. Deze server is niet ingericht om verzoeken vanaf het internet te accepteren, maar haalt zijn taken zelf op bij de webserver en levert de resultaten daar af.

Bij de exploitatie is geen hosting-, datacenter- of cloudprovider betrokken, en er gaat niets naar een externe AI-dienst. Welke derden gegevens ontvangen, staat op de pagina Subverwerkers.

3. Vertrouwelijkheid

3.1 Fysieke toegangscontrole

De servers staan in niet voor het publiek toegankelijke ruimten van de aanbieder in Polen. Alleen de eigenaar heeft toegang (volgens opgave van de exploitant). Het exacte adres van de locatie wordt hier bewust niet vermeld.

3.2 Toegangscontrole: inloggen bij de dienst

Wachtwoorden worden alleen als hash opgeslagen met de standaardmethode van PHP (bcrypt). Als de standaardmethode verandert, wordt de hash bij de volgende login vernieuwd. Bij een inlogpoging met een onbekend adres berekent de server toch een hash, zodat de responstijd niet verraadt of een account bestaat. Evenzo verraadt het antwoord op een verzoek om het wachtwoord opnieuw in te stellen noch door de formulering noch door de duur of het account bestaat; resetmails worden maximaal drie keer per uur naar hetzelfde adres gestuurd. Nieuwe wachtwoorden moeten ten minste tien tekens lang zijn en mogen niet langer zijn dan 72 bytes (UTF-8), omdat bcrypt niet meer bytes in aanmerking neemt. Het wijzigen van het wachtwoord meldt alle andere apparaten af; het opnieuw instellen via de link meldt alle apparaten af, en de link is slechts één keer geldig.
Blokkering na mislukte pogingen. Mislukte logins worden per IP-adres geteld; na te veel in korte tijd (momenteel acht in 15 minuten) wordt inloggen vanaf dat adres tijdelijk geblokkeerd. Een geslaagde login zet deze teller terug. De pogingen worden na zeven dagen verwijderd. Daarnaast wordt vóór elke wachtwoordcontrole één poging geteld per account (bij een onbekend adres per ingevoerd adres) en per IP-adres, geslaagde pogingen inbegrepen: momenteel maximaal acht per account vanaf hetzelfde IP-adres en 80 per IP-adres in 15 minuten; per account geldt over alle adressen samen een aanzienlijk hogere limiet, tegen gedistribueerd raden. Mislukte pogingen vanaf een ander adres sluiten de eigenaar daardoor niet meer buiten zijn account. Deze tellers bevatten alleen een HMAC-sleutel, geen e-mail- of IP-adres in leesbare vorm, en verlopen met hun tijdvenster. Als de telleropslag niet beschikbaar is, wordt de login geweigerd, niet doorgelaten. Hetzelfde soort limiet geldt voor het bevestigen van het wachtwoord vóór een wijziging van wachtwoord of adres, het in- of uitschakelen van de tweede factor, het overdragen van een werkruimte, de gegevensexport en het verwijderen van het account (vijf pogingen per account in 15 minuten), voor registraties (tien per IP-adres per uur) en voor wachtwoorden van klantportalen (tien pogingen per portaal en IP-adres, 50 per portaal in 15 minuten).
Tweede factor. Elk account kan inloggen met een eenmalige code volgens RFC 6238 (TOTP) inschakelen. Het geheim daarvoor wordt versleuteld in de database opgeslagen; de sleutel staat niet in de database, zodat een uittreksel van de database alleen niet volstaat. Een geaccepteerde code is geen tweede keer geldig. Tien herstelcodes worden alleen als hash opgeslagen. Eenmalige codes en herstelcodes zijn beperkt tot tien pogingen per account in 15 minuten, ook tijdens het instellen.
Beheeromgeving alleen met tweede factor. De beheeromgeving van de exploitant opent alleen voor accounts met ingeschakelde tweede factor. De installatiechecklist meldt elk beheerdersaccount zonder tweede factor.
Sessies. De sessiecookie kan niet door scripts worden gelezen (HttpOnly), wordt alleen via HTTPS verzonden (Secure) en wordt niet meegestuurd met verzoeken van sites van derden die iets zouden kunnen wijzigen (SameSite=Lax). Bij het inloggen wordt een nieuwe sessie-ID aangemaakt, zodat een vooraf ondergeschoven ID niet meer geldig is; de server accepteert geen sessie-ID die hij niet zelf heeft uitgegeven. Elk account ziet zijn aangemelde apparaten en kan deze afzonderlijk afmelden.
“Ingelogd blijven” is optioneel en 30 dagen geldig, maar niet voor accounts met beheerrechten; deze melden zich altijd aan met wachtwoord en tweede factor. Het token bestaat uit twee delen; het verifiërende deel wordt in de database alleen als hash opgeslagen. Bij elk gebruik wordt het door een nieuw token vervangen, en zelfs bij gelijktijdige verzoeken is elk token slechts één keer geldig, zodat een gestolen token uiterlijk bij het volgende echte bezoek wordt opgemerkt.
Links in e-mails. Links voor het bevestigen van het adres en het opnieuw instellen van het wachtwoord worden in de database alleen als hash opgeslagen. De resetlink is één uur geldig, de link voor het bevestigen van een registratie 72 uur, de link voor het bevestigen van een gewijzigd adres 24 uur. Als het e-mailadres wordt gewijzigd, wordt een openstaande resetlink ongeldig.
Interfaces. API-sleutels, koppelcodes van de extensies en uitrolcodes worden alleen als hash opgeslagen. API-sleutels kunnen slechts een beperkt aantal keren per minuut worden gebruikt; koppelcodes van de extensies zijn 15 minuten en slechts één keer geldig.
Botbescherming op de openbare formulieren (registratie, login, wachtwoord, controle, headertool, opt-out, support en contact): Google reCAPTCHA, dat pas bij het verzenden wordt geladen. Alleen een geldig antwoord van Google met een voldoende score voor precies de actie van het formulier wordt geaccepteerd; als Google niet binnen drie seconden antwoordt, wordt de verzending geweigerd. Details staan in de Privacyverklaring.

3.3 Toegangscontrole: serverbeheer

De vanaf het internet bereikbare server laat via een pakketfilter alleen de diensten toe die hij aanbiedt, en blokkeert automatisch adressen na herhaalde mislukte aanmeldingen bij het serverbeheer.
Geautomatiseerde processen tussen de servers gebruiken eigen sleutels met nauw begrensde rechten. De sleutel waarmee de webserver nieuwe versies van de scanner uitlevert, mag op de scanserver alleen een vaste lijst opdrachten uitvoeren en alleen, uitsluitend schrijvend, naar de map van de scanner kopiëren; een interactieve aanmelding is daarmee niet mogelijk, en elke geweigerde opdracht wordt gelogd. Evenzo mag de scanserver screenshots alleen naar een bepaalde map op de webserver schrijven.
Het proces dat de website levert, heeft geen schrijftoegang tot de productie-installatie en geen sleutel voor de scanserver. Een in de beheeromgeving gestarte uitrol maakt alleen een taak aan, die een afzonderlijke run uitvoert.
Geheimen zoals databasegegevens en sleutels staan in configuratiebestanden buiten de geleverde map en worden bij de uitrol niet meegekopieerd. De configuratie van de webserver wordt niet via de webinterface verspreid.

3.4 Autorisatiecontrole: rechten binnen de dienst

Rollen. Elke werkruimte kent de rollen eigenaar, beheerder en lezer. Wijzigen, verwijderen, uitnodigen en het opslaan van inloggegevens zijn voorbehouden aan eigenaren en beheerders; alleen de eigenaar mag rollen wijzigen en leden verwijderen. Een uitnodiging is alleen geldig zolang de persoon die haar heeft verstuurd nog eigenaar of beheerder is. Lezers zien de adressen van webhooks en chatkanalen alleen ingekort tot de host, omdat het adres alleen al volstaat om in het kanaal te posten. De controle vindt plaats op de server, niet alleen in de interface.
Binding aan de werkruimte. Domeinen en instellingen zijn alleen toegankelijk voor leden van de werkruimte. Voor elke controle maakt de Dienst een rapport aan onder een willekeurige link die niet te raden is; de resultaten en screenshots van een controle zijn via deze link zonder inloggen toegankelijk, screenshots alleen samen met de link van hun rapport. De link verschijnt in het account en in meldingen; wie hem doorgeeft, geeft het rapport door.
Verzoeken die de toestand wijzigen vereisen een beveiligingstoken per sessie (CSRF-bescherming), dat in constante tijd wordt vergeleken.
“Bekijken als klant”. Voor support kan de exploitant de applicatie zien zoals een Klant die ziet. De weergave eindigt na één uur, blokkeert wijzigingen van wachtwoord, adres, tweede factor, apparaten, abonnement, export en verwijdering, sluit de beheeromgeving zolang zij actief is en wordt gelogd. Het beëindigen ervan meldt de exploitant volledig af; hij kan alleen terugkeren naar de beheeromgeving door opnieuw in te loggen met wachtwoord en tweede factor. De Klant kan het zien in zijn gegevensexport.
Beheer. Alleen enkele uitdrukkelijk gemachtigde accounts hebben beheerrechten; elke reset van een tweede factor door het beheer wordt gelogd.

3.5 Scheidingscontrole

De gegevens van klanten zijn logisch gescheiden per werkruimte. Elk lees- en schrijfpad in het ingelogde gedeelte draagt deze binding met zich mee; rapporten zijn daarnaast via hun link toegankelijk (paragraaf 3.4).
Ontwikkeling en productie draaien in gescheiden installaties met gescheiden databases en gescheiden databasegebruikers. De ontwikkelgebruiker heeft geen toegang tot de productiedatabase. Echte klantgegevens worden niet naar de ontwikkelomgeving gekopieerd; daar werken wij met gegenereerde voorbeeldgegevens.
Per omgeving heeft de scanner eigen toegangsgegevens met rechten alleen op de gegevens die hij voor zijn taken nodig heeft. Accounts, facturering en logs kan hij niet lezen.
Op de webserver draaien ook andere diensten van dezelfde aanbieder. Deze hebben eigen databases en eigen databasegebruikers zonder toegang tot de gegevens van deze dienst.

4. Versleuteling, pseudonimisering en gegevensminimalisatie

4.1 Inloggegevens voor de scan achter de login

Voor deze functie slaat de Klant de gebruikersnaam en het wachtwoord van een testaccount op. Dit zijn de gevoeligste gegevens in de dienst en ze worden daarom anders beschermd dan al het andere:

Bij het opslaan versleutelt de webserver ze met de openbare sleutel van de scanserver (ECIES: X25519 met een eenmalige sleutel per record, HKDF-SHA256, AES-256-GCM). De privésleutel bestaat alleen op de scanserver. Webserver, database en back-ups bevatten alleen versleutelde tekst; ook wij kunnen die daar niet lezen.
Elk record is cryptografisch aan zijn domein gebonden. Bij verplaatsing naar een ander domein mislukt de ontsleuteling.
Voor een scan wordt de versleutelde tekst aan de taak gekoppeld. De scanserver ontsleutelt deze en geeft de inloggegevens alleen via standaardinvoer door aan de controlecontainer, nooit als opdrachtregelargument dat in proceslijsten zichtbaar zou zijn. Zodra de scanserver de versleutelde tekst heeft gelezen, wordt deze uit de taak verwijderd; een run ruimt eventuele restanten uiterlijk na één uur op.
De inloggegevens worden nooit weergegeven, nooit gelogd, nooit via de API uitgevoerd en niet geëxporteerd. De interface toont alleen het eerste teken en de lengte van de gebruikersnaam. Bij het verwijderen wordt de versleutelde tekst overschreven.
Achter de login leest de scanner alleen: geen verzenden, geen actieve test, geen screenshots, geen pagina’s voor afmelden, verwijderen of opzeggen.

4.2 Verdere versleuteling en hashes

Wachtwoorden, herstelcodes, wachtwoorden van klantportalen, API-sleutels, koppel- en uitrolcodes, tokens voor “Ingelogd blijven”, sessie-ID’s in de apparatenlijst en links voor bevestiging en reset worden alleen als hash opgeslagen.
Geheimen voor de tweede factor worden versleuteld opgeslagen (paragraaf 3.2).
Wij beweren niet dat de volledige database in rust is versleuteld. De gevoelige waarden worden afzonderlijk beschermd, zoals hierboven beschreven.

4.3 Gegevensminimalisatie door ontwerp

Bezorgcontrole: Alleen de headers en maximaal de eerste 8 KB van de tekst worden gelezen. In de database komen alleen het tijdstip, de toewijzing, in voorkomend geval de ID van de testverzending en het resultaat van de authenticiteitscontrole (SPF, DKIM, DMARC), nooit de inhoud of een volledig afzenderadres. Het authenticiteitsresultaat van de meest recente e-mail wordt bij het domein bewaard en door het volgende overschreven; het bevat het IP-adres van de afleverende mailserver en het e-maildomein van de afzender. De e-mail wordt na succesvolle verwerking uit de mailbox verwijderd; als ophalen of verwijderen mislukt, gebeurt dat bij de volgende succesvolle run.
Controles: De structuur van de formulieren wordt opgeslagen met veldnamen, typen en labels, verplichte en zichtbaarheidsattributen, geen waarden; de beginstukken van vooraf ingevulde verborgen velden (tot 24 tekens) en van data-attributen (tot 60 tekens) leest de scanner alleen tijdens de controle en slaat hij niet op. De screenshots van de volledige controle worden niet afgeschermd; alleen de browsercontroles dekken invoervelden af. Ontvangeradressen van formulieren worden alleen als domein opgeslagen. Actieve testverzendingen bevatten alleen gemarkeerde testteksten zonder persoonsgegevens.
Extensies voor WordPress en TYPO3 geven alleen dagcijfers en kenmerken zoals de plugininventaris door, en bij een gekoppelde WordPress-plugin ook de domeinen van links uit geblokkeerde berichten voor de zwermbescherming (standaard ingeschakeld); geen andere inhoud, geen namen, adressen of IP-adressen van bezoekers. Optionele formulier- en veldfouttellingen zijn standaard uitgeschakeld.
“Fix it for me”: De ingeplakte code wordt alleen verwerkt zolang het verzoek duurt en wordt niet opgeslagen.
Badge: De badge-afbeelding op websites van klanten plaatst geen cookie en start geen sessie.
Operationele meldingen naar de telefoon van de exploitant zijn vaste teksten zonder variabelen, dus zonder namen, adressen of inhoud. Foutmeldingen per e-mail aan de exploitant bevatten de ruwe tekst van de foutmelding, niet opgeschoond en ingekort tot 400 tekens; in afzonderlijke gevallen kan deze adressen of links bevatten.
Zwermbescherming: Tussen de extensies van Klanten worden alleen domeinen uit links in geblokkeerde spam gedeeld; de uitwisseling van IP-netwerken is uitgeschakeld.
Locatie: Het land van een IP-adres wordt bepaald aan de hand van een lokaal databasebestand; er gaat geen adres naar een geolocatiedienst.

5. Bescherming tegen misbruik van de scanner

De scanner laadt pagina’s van derden met een echte browser. Zonder bescherming zou hij een instrument zijn waarmee iemand van buitenaf ons interne netwerk of andere niet-openbare doelen zou kunnen bereiken (server-side request forgery). Daarom zijn er twee onafhankelijke lagen en wordt elke afzonderlijke run geïsoleerd.

5.1 Geïsoleerde run

Elke controle draait in een eigen container, die daarna wordt verwijderd. Deze draait zonder beheerdersrechten, zonder extra besturingssysteembevoegdheden en zonder de mogelijkheid om rechten te verhogen. Het bestandssysteem is alleen-lezen, op kleine vluchtige gebieden na.
Geheugen, aantal processen en looptijd zijn begrensd; een run die de tijd overschrijdt, wordt beëindigd.

5.2 Netwerk: twee lagen

Eerste laag, in de scanner: Vóór de scan en vervolgens bij elk afzonderlijk verzoek van de browser, inclusief omleidingen en ingesloten inhoud, wordt gecontroleerd waarnaar het adres verwijst. Private, lokale, gereserveerde en documentatienetwerken (IPv4 en IPv6) worden geweigerd, evenals andere poorten dan de voor het web gebruikelijke. De browser staat geen service workers toe, en WebSocket-verbindingen worden gesloten, omdat beide deze controle zouden kunnen omzeilen.
Tweede laag, in het netwerk: De containers draaien in een eigen netwerk. Firewallregels staan vandaar alleen verbindingen naar het internet op webpoorten toe; verbindingen naar private netwerken, waaronder ons interne netwerk met webserver en database, worden geblokkeerd. Uitzonderingen die de controlerun zelf nodig heeft, zijn beperkt tot het noodzakelijke en beschreven in onze interne documentatie. Deze laag werkt ook als een naam pas na de eerste controle anders wordt omgezet.

5.3 Verzoeken door de webserver

Waar de webserver zelf adressen van derden opvraagt – voor het bewijs van zeggenschap over het domein, voor de headertool, voor het zoeken naar blootgestelde bestanden, voor pulsverzoeken, voor RDAP-query’s en voor het controleren van certificaten, voor webhooks en chatmeldingen en voor het optionele tweede meetpunt – gelden dezelfde regels: alleen webprotocollen, op de gebruikelijke webpoorten (webhooks en chatmeldingen alleen via HTTPS op de standaardpoort), alleen openbare adressen, een verbinding alleen met precies het vooraf gecontroleerde adres, zodat een naam achteraf niet naar een intern doel kan worden omgeleid, omleidingen helemaal niet gevolgd of alleen handmatig gevolgd en telkens opnieuw gecontroleerd, korte tijdslimieten; voor het bewijs van zeggenschap over het domein, voor pulsverzoeken en voor het tweede meetpunt bij browsercontroles bovendien een begrensde responsgrootte.

5.4 Wat de scanner niet doet op sites van derden

Actieve testverzendingen (maximaal vijf per controle) bestaan voor Klanten alleen voor domeinen waarvoor bewijs van zeggenschap is geleverd (DNS, metatag, bestand of extensie); de enige uitzondering zijn interne controles van onze eigen test- en demodomeinen. De hostnaam van een domein met bewijs van zeggenschap kan niet worden gewijzigd, zodat het bewijs niet op een andere host overgaat. Al het andere is passief: pagina’s lezen zoals een bezoeker.
Browsercontroles gaan tot vlak vóór het verzenden en activeren geen bestelling, betaling of verzending.
Domeinen op de opt-outlijst worden niet gecontroleerd; lopende monitoring eindigt bij de eerstvolgende geplande controle.

6. Integriteit: overdracht en invoer

6.1 Transport

De applicatie is vanaf het internet alleen via HTTPS bereikbaar; de browser krijgt de instructie om een jaar lang alleen HTTPS te gebruiken (HSTS). Certificaten worden automatisch vernieuwd.
Verdere headers beperken het insluiten van de applicatie in pagina’s van derden, het raden van bestandstypen en het verzenden van formulieren naar doelen van derden. Een content security policy laat in de applicatie alleen die scripts draaien die de server met het betreffende antwoord vrijgeeft; actuele browsers voeren geïnjecteerde scripts of event handlers in de HTML niet uit.
De mailbox van de bezorgcontrole wordt via een versleutelde verbinding met certificaatverificatie opgehaald.
Webhooks kunnen worden ondertekend met een geheim van de Klant (HMAC-SHA256 met tijdstempel), zodat de ontvanger herkomst en integriteit kan verifiëren. Verzoeken aan het optionele tweede meetpunt worden ondertekend, en bij browsercontroles ook de antwoorden daarvan.
Openlijk vermeld: Verbindingen binnen ons interne netwerk zijn niet overal versleuteld. De inloggegevens voor de scan achter de login blijven overal versleuteld (paragraaf 4.1).

6.2 Invoercontrole en logs

Belangrijke handelingen in accounts en werkruimten (zoals inloggen, wijzigingen aan domeinen, meldingsbestemmingen en rechten, verwijderingen, supporttoegang) worden in het activiteitenlog vastgelegd met account, tijdstip, IP-adres en land, en na 365 dagen verwijderd.
Registraties van paginabezoeken die voor beveiliging en misbruikpreventie worden bijgehouden, worden na 60 dagen verwijderd, foutlogs na 90 dagen, inhoud van verzonden e-mails na 30 dagen. Toegangstokens in opgevraagde adressen en referrers, zoals die van rapport- of portaallinks, verschijnen in de registraties van paginabezoeken alleen gemaskeerd.
De aanvaarding van de contractdocumenten wordt opgeslagen met de getoonde versie, de controlesom daarvan, tijdstip, IP-adres en browseridentificatie.
Bewijslogs kunnen worden voorzien van een tijdstempel van een externe tijdstempelautoriteit; daarheen gaat alleen een controlesom van de inhoud, niet de inhoud zelf.

7. Beschikbaarheid en veerkracht

7.1 Back-up

Van de database wordt elke nacht een back-up gemaakt. Een back-up krijgt pas zijn definitieve naam nadat de inhoud is gecontroleerd: succesvolle afronding van het back-upprogramma, ten minste één record, evenveel tabellen als de database heeft, en de afsluitende regel van een volledige run. Oudere back-ups worden pas na een geslaagde nieuwe verwijderd.
Elke back-up wordt na 14 dagen verwijderd. De opslaglocatie ligt buiten elke geleverde map; een locatie binnen het project wordt geweigerd.
Hersteltest: Eenmaal per week wordt de meest recente back-up in een wegwerpdatabase geladen, tabel voor tabel vergeleken met de productie en weer verwijderd. Het resultaat wordt opgeslagen.
Als een back-up of een test mislukt, gaat er een melding uit per e-mail en naar de telefoon van de exploitant.
Herstel na een incident: Als de database uitvalt of gegevens beschadigd raken, zetten wij de meest recente geteste back-up terug. Wijzigingen sinds die back-up, in de regel maximaal die van één dag, kunnen daarbij verloren gaan; als een back-up is mislukt, dienovereenkomstig meer. Daarna voeren wij bekende latere verwijderverzoeken opnieuw uit (paragraaf 8). Wij verbinden ons niet aan een bepaalde hersteltijd.
Grens, openlijk vermeld: De back-ups worden momenteel op dezelfde locatie bewaard als de database en zijn niet afzonderlijk versleuteld. Ze beschermen tegen bedieningsfouten, foutieve wijzigingen en beschadigde gegevens, niet tegen verlies van de server zelf. Een versleutelde kopie op een tweede locatie is gepland (paragraaf 10).
De inloggegevens voor de scan achter de login staan in de back-ups alleen als versleutelde tekst; het geheim van de tweede factor alleen in versleutelde vorm, met een sleutel buiten de database.

7.2 Monitoring

Een statusrun controleert elke vijf minuten de componenten van de dienst, waaronder de database, de wachtrij en de hartslag van de scanner, die de scanner ook bij inactiviteit regelmatig schrijft. Als een component uitvalt, gaat er een melding uit; als hij herstelt, een sein veilig.
Wederzijdse bewaking: Een statusrun kan de uitval van de machine waarop hij draait niet melden. De scanserver controleert daarom elke minuut of de applicatie reageert en meldt na meerdere opeenvolgende mislukkingen met een vaste tekst aan de telefoon van de exploitant. Omgekeerd bewaakt de webserver de hartslag van de scanner; de installatiechecklist toont of de wederzijdse bewaking actief is.
Foutalarm: Een fouttype dat nog nooit is voorgekomen, wordt eenmalig direct gemeld; een opeenhoping van fouten veroorzaakt slechts één signaal naar de telefoon van de exploitant; eenmaal per dag wordt een overzicht verstuurd. Zo horen wij niet pas van een Klant over een fout.
Grens, openlijk vermeld: Beide servers staan op dezelfde locatie. Een uitval van de volledige locatie, bijvoorbeeld van stroom of internetverbinding, wordt door geen enkel alarmeringsmechanisme gemeld, maar door een mens opgemerkt.

7.3 Wijzigingen en uitrol

Nieuwe versies worden eerst in de gescheiden ontwikkelomgeving gebouwd en getest. De uitrol controleert alle voorwaarden voordat het eerste bestand wordt geschreven, voert de wijzigingen aan het databaseschema uit en laat lopende controles ordelijk afronden voordat de scanner opnieuw start.
Voor het traject van een nieuwe Klant is er een smoketest via echte HTTP, die na omschakelingen wordt uitgevoerd. Wij beweren niet dat er vóór elke afzonderlijke uitrol een geautomatiseerde testsuite draait.

8. Verwijdering en bewaartermijnen

Een verwijderrun handhaaft elke nacht de termijnen die in de Privacyverklaring en de Verwerkersovereenkomst zijn vermeld. Hij leest dezelfde instellingen waaruit de getallen in de teksten afkomstig zijn; voor deze termijnen lopen tekst en gedrag dus niet uiteen.
Controleresultaten inclusief screenshots worden na 13 maanden verwijderd (de meest recente per domein blijft), extensiecijfers na 13 maanden, afleverlogs van meldingen na 90 dagen, supportverzoeken na 24 maanden.
Het verwijderen van een domein verwijdert de gegevens van het domein, inclusief controles, formulieren, bevindingen, screenshots, rapporten, taken, meldingsbestemmingen en -logs, incidenten, bezorggegevens, inloggegevens voor de scan achter de login en bewijsmateriaal.
Het verwijderen van een account gebeurt onmiddellijk; werkruimten zonder andere leden worden met hun gegevens verwijderd, werkruimten met andere leden gaan over op een ander lid, eerst op beheerders, en daaronder op het langst aanwezige lid. Tot hun eigen termijnen verlopen, blijven bewaard: de logs waarvan de vermeldingen het oude accountnummer behouden, dat niet meer naar een bestaand account verwijst, inclusief de verwijdervermelding, evenals verzonden e-mails, het bewijs van de totstandkoming van de overeenkomst, supportverzoeken, rapporten van prospectcontroles (tot 90 dagen) en factuurgegevens bij Stripe; details staan in de Privacyverklaring.
Verwijderde gegevens blijven in back-ups staan totdat deze na 14 dagen verlopen. Gericht verwijderen binnen een back-up vindt niet plaats; als een back-up wordt teruggezet, worden bekende latere verwijderverzoeken handmatig opnieuw uitgevoerd.

9. Organisatie en evaluatie

Personen: De dienst wordt momenteel door de eigenaar zelf geëxploiteerd. Andere personen krijgen alleen toegang na een geheimhoudingsverklaring en alleen voor zover noodzakelijk, en zij verwerken gegevens uitsluitend op onze instructie (Art. 29 en Art. 32(4) AVG).
Subverwerkers: Wij schakelen ze alleen in na toetsing van hun garanties en op basis van een overeenkomst overeenkomstig Art. 28(4) AVG, en vermelden ze op de pagina Subverwerkers; details zijn geregeld in de Verwerkersovereenkomst.
Inbreuken in verband met persoonsgegevens: Als een inbreuk in verband met persoonsgegevens verwerkersgegevens betreft, informeren wij de Klant onverwijld, indien mogelijk binnen 48 uur; details zijn geregeld in de Verwerkersovereenkomst.
Melden van kwetsbaarheden: Wij nemen meldingen aan via Beveiliging en via het bestand /.well-known/security.txt.
Installatie- en lanceringschecklist: In de beheeromgeving meet een checklist de status van beveiligingsrelevante instellingen, zoals back-up, beheerders zonder tweede factor, mailinstellingen en hartslag, en toont afwijkingen.
Evaluatie van deze maatregelen (Art. 32(1)(d) AVG): bij elke belangrijke wijziging van de dienst, na elk beveiligingsincident en verder ten minste eenmaal per jaar. Daarbij beoordelen wij of de maatregelen doeltreffend zijn en nog bij de risico’s passen, en leggen wij het resultaat vast in een nieuwe versie van deze pagina of, als er niets verandert, met de datum van de evaluatie in paragraaf 11. Doorlopend meet de installatie- en lanceringschecklist de status van de instellingen die zij omvat.
Externe audits: Er worden momenteel geen externe penetratietests uitgevoerd en er zijn geen beveiligingscertificeringen. Dat wordt hier vermeld zodat niemand ervan uitgaat dat ze er zijn.

10. Gepland, nog niet geïmplementeerd

Deze punten zijn geen toegezegde maatregelen totdat ze hier in een nieuwe versie als geïmplementeerd worden vermeld:

Back-up op een tweede locatie: een versleutelde kopie van de nachtelijke back-up buiten de server, zodat zelfs een volledig verlies van de server niet tot gegevensverlies leidt.
Tweede meetpunt: Onafhankelijke bevestiging van browsercontroles vanaf een tweede locatie is in de dienst voorbereid, maar niet ingericht. Zonder dit meetpunt is er geen bevestiging vanaf een tweede locatie.
Versteviging van het serverbeheer: Dit loopt nog. Om de in paragraaf 1 genoemde redenen publiceren wij geen details.

11. Status en versie

Versie 1.1 · Laatst bijgewerkt: 22 oktober 2026 · bij afwijkingen tussen de taalversies heeft de Poolse versie voorrang in plaats van de Duitse; verder geen wijzigingen.
Versie 1.0 · Laatst bijgewerkt: 11 oktober 2026 · eerste versie als afzonderlijke pagina; voorheen Bijlage 2 bij de Verwerkersovereenkomst. Gecorrigeerd ten opzichte van de vorige bijlage: de hersteltest draait wekelijks, de back-ups staan op dezelfde server, er draait geen geautomatiseerde testsuite vóór elke uitrol, verbindingen in het interne netwerk zijn niet overal versleuteld. Nieuw beschreven: versleuteling van de inloggegevens voor de scan achter de login, isolatie van de scanner, wederzijdse bewaking en foutalarm.
Wijzigingen worden met een nieuw versienummer hier en in het overzicht Wijzigingen in de contractdocumenten gepubliceerd; bij een afzwakking van maatregelen geldt de aankondigingstermijn van de Verwerkersovereenkomst.
Bij afwijkingen tussen de taalversies heeft de Poolse versie voorrang.

Hoe kunnen we helpen?