Een testomgeving bevat echte klantgegevens

Begin met een inventaris, niet met een oplossing. Veel kmo's weten niet precies wat er bij een kopie van de database is meegekomen. Loop deze plekken na:

• Database: klant-, bestel-, abonnee- en gebruikerstabellen, maar ook logtabellen en formuliertabellen met vrije tekstvelden.
• Bestanden: uploads, facturen als pdf, exports in csv of xlsx die iemand ooit in een map liet staan.
• Koppelingen: verbindingen met mailtools, betaalproviders, CRM en voorraadsystemen. Een testomgeving met live sleutels kan echte mails versturen of echte betalingen aanraken.
• Back-ups en logbestanden: ook die bevatten vaak volledige gegevens.

Noteer per plek: welk type gegeven (naam, e-mailadres, adres, telefoonnummer, bestelhistoriek), waar het staat en wie er nu toegang toe heeft. Dit lijstje is straks je overdrachtsdocument.

Een testomgeving op een gewone, openbare URL is voor iedereen bereikbaar die het adres kent of raadt. Beperk dat vóór je iets anders doet. Je kiest uit meerdere lagen, en ze vullen elkaar aan:

• Toegangscontrole op serverniveau: een inlog of IP-beperking vóór de website, zodat de pagina's niet eens laden zonder toestemming.
• Aparte accounts per persoon: geen gedeeld wachtwoord dat rondgaat.
• Sterke verificatie: de MDN-beveiligingsgids adviseert om gebruikers niet alleen met een wachtwoord te laten inloggen, en noemt passkeys als sterkste methode en tijdgebonden eenmalige codes (TOTP) als veiliger dan traditionele wachtwoorden (MDN over webbeveiliging).
• Een tijdelijke toegang: spreek vooraf af wanneer een account vervalt.

Let op een veelgemaakte denkfout: robots.txt is geen toegangscontrole. Het regelt wat crawlers mogen ophalen, maar blokkeert geen mens met de URL en garandeert niet dat een pagina uit een zoekindex wegblijft. Een gewone browsercontrole bewijst bovendien niets over wat Googlebot kan bereiken. Beveilig daarom met authenticatie, niet met een crawlverbod.

De testomgeving is zo veilig als de accounts die erbij kunnen: hostingpaneel, repository, CMS-beheer en de mailbox waarop wachtwoorden worden hersteld. Bij Google-accounts werkt tweestapsverificatie als extra laag voor het geval een wachtwoord wordt gestolen. Volgens de bron zet je dat aan via de beveiligingsinstellingen van je account, en bij een account via werk of school kan je beheerder dit beperken (Google over tweestapsverificatie).

Twee nuances uit die bron zijn handig voor je beleid. Een toegangssleutel slaat de tweede stap over omdat het apparaat zelf de verificatie levert. En een nieuw telefoonnummer voor de tweede stap kan tot 7 dagen nodig hebben voor Google het vertrouwt. Leg dus geen kritieke toegang vast op een nummer dat je net hebt toegevoegd. Voor andere diensten (hosting, CMS, repository) geldt dat de schermen en opties verschillen: controleer in de beheerinstellingen van elke dienst wat beschikbaar is.

Toegangsbeperking is een eerste hek. Het echte probleem verdwijnt pas als de gegevens er niet meer staan. Een fixture is een vaste, verzonnen testdataset die je zelf onderhoudt. Zo werk je:

1. Maak een nieuwe, lege testdatabase aan in plaats van de live database te kopiëren.
2. Laad een fixtureset met duidelijk verzonnen klanten, bijvoorbeeld namen als 'Testklant 001' en adressen op een eigen testdomein.
3. Dek de gevallen af die je moet testen: klant met meerdere bestellingen, klant zonder adres, bestelling met kortingscode, geannuleerde bestelling, buitenlands adres.
4. Gebruik testsleutels bij betaal- en mailkoppelingen, zodat er nooit een echte klant een bericht krijgt.
5. Kun je een structuur enkel testen met afgeleide echte data, anonimiseer dan vóór het kopiëren en niet erna: vervang namen, e-mailadressen, telefoonnummers en vrije tekstvelden. Controleer daarna steekproefsgewijs of er nog herkenbare gegevens in logtabellen of opmerkingvelden zitten.

Controleer ook of oude kopieën, exports en back-ups van vóór de opschoning nog ergens staan. Die zijn vaak vergeten en bevatten dan nog altijd de volledige gegevens.

Gebruik deze matrix vóór je iemand uitnodigt. Ze is bedoeld als eigen werkinstrument en geen juridische beoordeling.

Een fictief scenario, alleen als invoer en verwachte controles: een kmo laat een webshop door een externe partij herbouwen. De testomgeving blijkt een kopie van de live database te zijn met ongeveer 'enkele honderden' klantrecords (een bewust vaag, verzonnen gegeven). Het team gaat zo te werk:

1. Bestaande externe toegang wordt meteen ingetrokken en de inventaris uit stap 1 wordt ingevuld.
2. De omgeving wordt achter een inlog gezet.
3. De database wordt vervangen door een fixtureset van testklanten.
4. Koppelingen krijgen testsleutels.
5. Pas daarna wordt per externe een eigen account met einddatum aangemaakt.

Controle na wijziging (jij voert die zelf uit):

• Open de testomgeving in een privévenster zonder inlog en ook vanaf een ander netwerk: je mag geen inhoud zien. Dit bewijst alleen dat mensen er niet in kunnen, niet wat een crawler kan bereiken.
• Doorzoek de testdatabase op een bekend echt e-mailadres en op je eigen domein: je verwacht geen treffers.
• Controleer eerst dat alle koppelingen testsleutels gebruiken. Verstuur dan een testbestelling met een uniek, verzonnen testadres en controleer dat er geen echte mail of betaling vertrekt en dat de bestelling maar één keer is opgeslagen, ook als er een time-out of foutmelding verscheen.
• Zoek in logs en exportmappen naar oude kopieën.
• Controleer in Google Search Console met URL-inspectie (geïndexeerde versie, niet de livetest) of testpagina's ooit zijn geïndexeerd. Of dat gebeurd is, hangt af van wat eerder bereikbaar was; een livetest toont dat niet.
• Plan een datum om accounts van externen op te ruimen.

Wil je ook zien welke publieke signalen je website uitstraalt, bekijk ze dan via Marketing Scan. De scan meet zichtbare signalen en bewijst geen volledige technische implementatie, en voert niet alle bovenstaande controles uit.