Sandbox vs productie: waarom je nooit test op je live bedrijfsdata

Door Clen Mourik

Testen op je live bedrijfsdata lijkt efficiënt, maar kan je bedrijf tienduizenden euro's kosten. In dit artikel lees je waarom een testomgeving geen luxe is en welke concrete risico's je loopt als je rechtstreeks op productie test.

Hoeveel uur per week besteed jij aan het oplossen van problemen die eigenlijk niet hadden hoeven te gebeuren? Een klant die een testfactuur ontvangt. Een leverancier die belt over een bestelling die nooit geplaatst is. Voorraadstanden die kloppen noch in je systeem, noch in je magazijn.

De oorzaak is vaak dezelfde: een koppeling of update die rechtstreeks op je live systeem is getest. Zonder sandbox. Zonder vangnet. Met alle gevolgen van dien.

En toch zie ik het elke week gebeuren bij MKB-bedrijven. Een aannemingsbedrijf dat een nieuwe koppeling tussen hun projectmanagementsysteem en Exact Online laat bouwen. Een groothandel die hun voorraadkoppeling wil uitbreiden. Een transportbedrijf dat een nieuw track & trace-systeem implementeert. Ze testen allemaal op hun productieomgeving, omdat "het toch maar een kleine test is" of "we hebben geen testomgeving".

Tot het misgaat.

Inhoudsopgave

• Belangrijkste punten
• Wat is een sandbox testomgeving precies?
• De risico's van testen op productiedata
• Wat er misgaat als je geen testomgeving hebt
• De juridische kant: AVG en testdata
• Wat kost een data-incident echt?
• Hoe maak je een testomgeving aan?
• 7 veelgemaakte fouten met testomgevingen
• Veelgestelde vragen

Belangrijkste punten

Wat is een sandbox testomgeving precies?

Een sandbox is een geïsoleerde omgeving waarin je veilig kunt experimenteren, testen en ontwikkelen zonder dat het impact heeft op je live bedrijfssystemen. Denk aan een speeltuin waarin je alles kunt uitproberen zonder dat het echte gevolgen heeft.

Het werkt zo: je maakt een kopie van je productieomgeving, maar dan volledig gescheiden. Wijzigingen in de sandbox hebben geen effect op je echte data. Facturen die je daar aanmaakt, worden niet verstuurd. Orders die je test, komen niet bij leveranciers terecht. Voorraadmutaties raken je echte voorraad niet aan.

Bij projecten waar we de testfase serieus nemen, zien we dat 80% van de problemen in de sandbox wordt ontdekt en opgelost. Die 80% hoeft dus nooit je echte bedrijfsvoering te raken.

Het verschil tussen ontwikkel, test, acceptatie en productie

Professionele softwareontwikkeling werkt met een OTAP-structuur: Ontwikkel, Test, Acceptatie en Productie. Elk stadium heeft zijn eigen omgeving:

• Ontwikkelomgeving: hier schrijft de developer de code, bouwt de koppeling, test de eerste basis-functionaliteit
• Testomgeving: hier wordt de koppeling uitgebreid getest met testdata die de productie nabootst
• Acceptatieomgeving: hier test jij als klant of alles werkt zoals je verwacht
• Productieomgeving: hier draait je echte bedrijf, met echte klanten en echte data

Deze scheiding voorkomt dat een fout in fase 1 direct je hele bedrijf platlegt. Het klinkt als overkill voor het MKB, maar de principes gelden voor iedereen. Je hoeft niet alle vier de omgevingen te hebben, maar minimaal een test- én productieomgeving is geen luxe.

De risico's van testen op productiedata

Laten we eerlijk zijn: wat kan er nou echt misgaan? Een heleboel, blijkt in de praktijk.

Risico 1: Je verstuurt testdata naar echte relaties

Een koppeling tussen je ERP en je mailsysteem test je door een factuur aan te maken. Maar als je dat op productie doet, gaat die factuur ook echt de deur uit. Naar een echte klant. Voor een bedrag dat niet klopt. Met een ordernummer dat niet bestaat.

Ik heb het een transportbedrijf zien overkomen: ze testten een koppeling naar hun track & trace-portaal. Vijftig testberichten gingen naar echte klanten, inclusief onzin-trackingnummers. De klantenservice stond die dag roodgloeiend.

Risico 2: Data wordt permanent vervuild

Testdata verdwijnt niet vanzelf. Die testklant die je aanmaakt? Die staat nu voor altijd in je CRM. Die testorder? Die telt mee in je statistieken. Die testartikelcode? Die kan per ongeluk besteld worden.

Een groothandel die we begeleiden had 200+ testproducten in hun systeem staan. Niemand wist meer welke echt waren en welke test. Het opschonen kostte twee volle werkdagen.

Risico 3: Je overschrijft productiedata per ongeluk

Dit is de nachtmerrie: een UpdateConnector die bedoeld was voor test draait op productie. In één keer worden 500 klantrecords overschreven met testdata. Of erger: gewist.

Volgens onderzoek van Iron Mountain is 33% van dataverlies te wijten aan menselijke fouten. Testen op productie is daar een schoolvoorbeeld van.

Risico 4: Processen worden onbedoeld getriggerd

Moderne bedrijfssoftware is slim. Te slim soms. Een testorder aanmaken triggert automatisch een picklijst in het magazijn. Een testfactuur activeert een betalingsherinnering. Een testmedewerker wordt aangemeld bij de salarisverwerking.

Het probleem is dat je vaak niet eens weet welke processen er allemaal geactiveerd worden. Wat in de sandbox een onschuldige test is, kan op productie een lawine van acties in gang zetten.

Wat er misgaat als je geen testomgeving hebt

Laat me je vier voorbeelden geven uit de praktijk. Geen namen, maar wel echte situaties die we zijn tegengekomen.

De aannemer die bestelde bij leveranciers

Een bouwbedrijf met 15 man liet een koppeling bouwen tussen hun projectmanagementsysteem en hun inkoop. De implementatiepartner wilde "even snel iets testen" en maakte vijf testbestellingen aan. Op de productieomgeving.

Die bestellingen gingen rechtstreeks naar drie leveranciers. Complete orderbevestigingen, met leverdatum, afleveradres (het bedrijfspand), en een bestelbedrag van in totaal €18.000. Twee leveranciers hadden de orders al ingepland voordat iemand doorhad wat er gebeurde.

Annuleren kostte niet alleen vertrouwen, maar ook €250 aan annuleringskosten. Plus twee uur bellen en uitleggen.

De groothandel met vervuilde voorraad

Een technische groothandel koppelde hun webshop aan hun voorraadsysteem. De developer testte op productie "omdat we toch maar een paar producten hebben". Bij het testen werden 40 artikelen per ongeluk op voorraad 0 gezet.

Die artikelen verdwenen uit de webshop. Klanten die probeerden te bestellen, kregen "niet leverbaar" te zien. Het duurde drie dagen voordat iemand doorhad waarom de verkoop opeens terugliep. De omzetderving? Ongeveer €6.000 voor die week.

De logistiek dienstverlener en de AVG

Een transportbedrijf wilde hun systemen moderniseren. Om "realistische" testdata te hebben, kopieerde de leverancier de productiedatabase naar een testserver. Inclusief 50.000 klantrecords met namen, adressen en telefoonnummers.

Die testserver had test/test als inloggegevens. Standaard. Volgens Berenschot zijn testservers een dankbare plek voor criminelen om persoonsdata te stelen, en dat gebeurt vaak ongezien.

Gelukkig ontdekte hun IT-leverancier het tijdens een beveiligingsscan. Maar het had een volledig datalek kunnen zijn, met alle AVG-boetes van dien.

De webshop met facturen naar testklanten

Een B2B-webshop testte een automatische koppeling tussen hun Shopify-omgeving en AFAS. Zonder testomgeving in AFAS. De developer maakte drie testorders aan, maar gebruikte bestaande debiteurnummers "om te kijken of het werkt".

AFAS genereerde keurig drie facturen en verstuurde ze per mail. Naar echte klanten. Voor orders die zij nooit hadden geplaatst. De eerste klant belde binnen tien minuten. Verward, geïrriteerd en niet meer zo zeker of hij wel met dit bedrijf wilde blijven werken.

De juridische kant: AVG en testdata

Hier wordt het serieus. Testen met productiedata is niet alleen onhandig, het is vaak ook illegaal.

De Autoriteit Persoonsgegevens is heel helder: "Het testen van informatiesystemen mag alleen met fictieve (verzonnen) gegevens of met persoonsgegevens die weinig risico met zich meebrengen." Kopieer je klantdata naar een testomgeving? Dan verwerk je persoonsgegevens niet op de juiste manier en overtreed je de AVG.

Waarom de AVG dit verbiedt

De redenering is simpel: testomgevingen zijn minder goed beveiligd dan productieomgevingen. Ze hebben vaak standaard wachtwoorden, minder strikte toegangscontroles en worden niet altijd gemonitord. Precies de plek waar je géén persoonsgegevens wilt hebben.

Het aantal datalekken stijgt hard. In 2023 was er een stijging van 21% in gemelde datalekken in Nederland, en volgens Attic Security werd één op de vier mkb-bedrijven in 2024 slachtoffer, met een gemiddelde schadepost van €270.000.

Wat zijn de alternatieven?

Je hebt drie opties:

1. Fictieve testdata: je verzint klanten, orders en producten. Juridisch het veiligst.
2. Geanonimiseerde data: je neemt productiedata maar husselt alle persoonsgegevens. Jan Jansen wordt Peter de Vries, telefoonnummers worden vervangen, e-mailadressen aangepast.
3. Minimale echte data met toestemming: je gebruikt een handjevol echte records, maar alleen van mensen die daar expliciet toestemming voor hebben gegeven.

In de kennisbank op onze site vind je meer artikelen over AVG-compliant werken met koppelingen.

Wat kost een data-incident echt?

Laten we het even concreet maken. Wat kost het als het misgaat?

Ter vergelijking: een testomgeving opzetten kost vaak tussen de €500 en €2.000 eenmalig, afhankelijk van je softwarepakket. Bij systemen als AFAS of Exact Online kun je een testomgeving vaak zelf aanmaken zonder extra kosten.

Ik zeg altijd: als je niet wilt investeren in een testomgeving, bereid je dan voor om te investeren in schadebeperking. Het een of het ander gaat je geld kosten.

De verborgen kosten

Wat deze tabel niet laat zien, zijn de verborgen kosten:

• Tijd van medewerkers die orders moeten annuleren, klanten moeten terugbellen, data moeten herstellen
• Vertrouwen van klanten dat je kwijtraakt
• Orders die niet doorgaan omdat klanten twijfelen aan je professionaliteit
• Stress en frustratie in je team

Volgens onderzoek kost dataverlies en ongeplande downtime Nederlandse bedrijven 3,2 miljard euro per jaar. Voor het MKB kunnen de kosten van downtime oplopen tot tienduizenden euro's per uur.

Hoe maak je een testomgeving aan?

Goed, je bent overtuigd. Maar hoe pak je het praktisch aan?

Optie 1: Ingebouwde testomgeving in je softwarepakket

Veel moderne cloudpakketten hebben ingebouwde mogelijkheden voor een testomgeving. Bij AFAS bijvoorbeeld:

1. Open je productieomgeving
2. Ga naar Algemeen / Omgeving / Beheer / Aanvragen omgeving
3. Kies "Omgeving kopiëren als nieuwe testomgeving"
4. AFAS maakt een kopie op basis van de back-up van afgelopen nacht
5. De testomgeving krijgt een naam die begint met T (bijvoorbeeld T12345AB) en een aparte URL

Cruciaal aandachtspunt bij AFAS: zorg dat communicatieprofielen worden geblokkeerd (via Algemeen / Communicatieservice / Communicatieprofiel) en geplande taken worden uitgeschakeld (via Algemeen / Beheer / Geplande taak). Anders stuur je vanuit je testomgeving toch echte e-mails.

Optie 2: Een aparte licentie voor testen

Bij sommige systemen heb je een aparte testlicentie nodig. Die is vaak goedkoper dan een productielicentie, soms zelfs gratis voor partners of bestaande klanten. Check bij je softwareleverancier wat de mogelijkheden zijn.

Optie 3: Een staging-omgeving laten bouwen

Voor maatwerk-integraties bouwen wij bij SyncIT vaak een aparte staging-omgeving. Dat is een tussenlaag tussen test en productie, waar de koppeling draait met geanonimiseerde data maar wel de echte infrastructuur. Zie onze integratie-combinaties voor voorbeelden.

Wat moet je checken na het aanmaken?

• Zijn alle e-mailinstellingen uitgeschakeld?
• Zijn alle automatische taken gepauzeerd?
• Zijn API-koppelingen naar externe systemen gedisconnect?
• Hebben ontwikkelaars aparte inloggegevens voor test en productie?
• Is duidelijk welke omgeving je gebruikt? (Bij AFAS krijg je een groene balk bovenaan de testomgeving.)

7 veelgemaakte fouten met testomgevingen

Ook met een testomgeving kan het misgaan. Dit zijn de klassiekers:

1. De testomgeving bestaat niet (meer)

Het overkomt me vaker dan je denkt: een bedrijf denkt dat ze een testomgeving hebben, maar niemand weet waar die is of hoe je erin komt. Of de testomgeving is er ooit geweest maar na een systeem-upgrade verdwenen.

Check regelmatig of je testomgeving nog bestaat en toegankelijk is. En documenteer waar je hem vindt en wie er toegang toe heeft.

2. Test en productie zijn niet meer sync

Je testomgeving is drie maanden oud. Sindsdien heb je nieuwe producten toegevoegd, klantgroepen aangepast en prijsafspraken gewijzigd. Test je nu een koppeling op die oude testomgeving? Dan test je niet realistisch.

Maak regelmatig een nieuwe kopie van productie naar test. Bij AFAS kan dat met één klik, bij andere systemen moet je het plannen.

3. E-mails gaan toch de deur uit

Dit is de klassieker bij AFAS-gebruikers. Je denkt dat je testomgeving geen mails verstuurt, maar de communicatieprofielen staan nog aan. Resultaat: klanten krijgen toch testberichten.

Check altijd of alle uitgaande communicatie is geblokkeerd voordat je begint met testen.

4. Zelfde API-tokens voor test en productie

Bij het bouwen van integraties gebruiken developers API-tokens om systemen te laten communiceren. Gebruik je dezelfde tokens voor test en productie? Dan kan een testscript per ongeluk op je live data draaien.

Maak altijd aparte tokens aan voor je testomgeving. En gebruik duidelijk andere namen, zodat je niet per ongeluk de verkeerde gebruikt.

5. Testen met productiedata "omdat het realistischer is"

Ik snap de verleiding. Echte klantdata geeft een realistischer beeld dan fictieve testklanten. Maar zoals we al zagen: het is een AVG-overtreding en een beveiligingsrisico.

Investeer tijd in het opbouwen van goede fictieve testdata. Maak verschillende klantprofielen, producten met verschillende prijzen, scenario's met kortingen en BTW-varianten. Die dataset kun je steeds hergebruiken.

6. Geen duidelijk onderscheid tussen omgevingen

Je browser heeft vijf tabs open. Eentje is productie, eentje is test. Maar welke is welke? Voordat je het weet, test je op de verkeerde omgeving.

Geef je testomgeving een duidelijk andere URL, favicon en login-kleur. Bij AFAS krijg je automatisch een groene balk bovenaan de testomgeving, wat enorm helpt.

7. Denken dat sandbox alleen voor developers is

Een testomgeving is niet alleen voor techneuten. Het is ook de plek waar jij als ondernemer een nieuwe flow kunt uitproberen, een rapport kunt testen, of kunt kijken hoe een nieuwe proceswijziging uitpakt.

Gebruik je testomgeving regelmatig. Leer je systeem kennen zonder angst dat je iets kapot maakt. Dat geeft rust en grip.

Veelgestelde vragen

Kost een testomgeving extra geld?

Dat hangt af van je softwarepakket. Bij AFAS en Exact Online kun je vaak gratis een testomgeving aanmaken als bestaande klant. Bij andere systemen betaal je soms een gereduceerd tarief voor een testlicentie. Vraag bij je softwareleverancier wat de voorwaarden zijn.

Hoe vaak moet ik mijn testomgeving verversen?

Een goede regel: maak minimaal eens per kwartaal een nieuwe kopie van productie naar test. Doe je een grote update of bouw je een nieuwe koppeling? Ververs dan eerst je testomgeving, zodat je op actuele data test.

Kan ik mijn testomgeving gebruiken voor training van nieuwe medewerkers?

Absoluut, en dat is zelfs een van de slimste toepassingen. Nieuwe medewerkers kunnen in de testomgeving oefenen met het systeem zonder dat ze per ongeluk echte orders aanmaken of klantdata wijzigen. Maak wel eerst duidelijke testdata aan die ze kunnen gebruiken.

Wat is het verschil tussen een sandbox en een staging-omgeving?

In de praktijk worden de termen door elkaar gebruikt, maar technisch is er een verschil. Een sandbox is volledig geïsoleerd en gebruikt vaak fictieve data. Een staging-omgeving lijkt meer op productie qua infrastructuur en data, maar is nog niet live. Voor de meeste MKB-bedrijven is dat onderscheid niet zo relevant, het gaat erom dat je een veilige plek hebt om te testen.

Hoe voorkom ik dat testdata in mijn productieomgeving terechtkomt?

Gebruik verschillende API-tokens en inloggegevens voor test en productie. Geef ze duidelijk herkenbare namen. En check altijd dubbel in welke omgeving je zit voordat je een script draait of data importeert. Bij twijfel: stop en check eerst.

Moet ik mijn externe koppelingen ook testen in de sandbox?

Ja, maar let op dat externe systemen ook een testomgeving hebben. Test je een koppeling tussen AFAS en je webshop? Zorg dat beide systemen in testmodus draaien. Anders verstuur je vanuit je test-AFAS toch orders naar je live webshop.

Wat als mijn softwarepakket geen testomgeving ondersteunt?

Dan heb je twee opties: vraag de leverancier of er een workaround is, of overweeg om over te stappen naar een pakket dat wel moderne testfaciliteiten biedt. In 2025 is een testomgeving geen luxe meer, het is een basisbehoefte voor veilig werken. Check onze branche-oplossingen voor alternatieven.

Tijd om je testomgeving in te richten

Laten we het even samenvatten. Testen op productie lijkt efficiënt, maar de risico's zijn groot: vervuilde data, verstuurde testberichten, AVG-overtredingen en in het ergste geval een volledig datalek. De kosten van een incident lopen al snel op tot duizenden euro's, terwijl een testomgeving vaak weinig tot niets kost.

Het opzetten van een sandbox is geen rocket science. Bij moderne systemen als AFAS, Exact Online of Shopify is het een kwestie van een paar klikken. Het vraagt alleen dat je het prioriteit geeft.

Wat ik in de praktijk merk: bedrijven die serieus omgaan met testen, hebben minder problemen, minder stress en meer vertrouwen in hun systemen. Ze durven nieuwe koppelingen aan te gaan, processen te verbeteren en te experimenteren. Omdat ze weten dat ze een veilige omgeving hebben om dingen uit te proberen.

Ben je bezig met het automatiseren van processen of het bouwen van koppelingen tussen je systemen? En wil je het vanaf het begin goed aanpakken, inclusief een degelijke testopzet? Plan een adviesgesprek in. We kijken samen naar je situatie en bespreken hoe je veilig kunt testen zonder je live bedrijf te raken.