Beveiliging voor reisbureaus en touroperators: data, betalingen en GDS
Reisbureaus en touroperators verwerken in elke fase van een reis persoonlijke gegevens. Deze gids laat zien hoe je in kaart brengt welke gegevens je bewaart, toegang beveiligt, betaalgegevens beschermt, technologiepartners beoordeelt en je voorbereidt op een beveiligingsincident.
Waar het risico begint
Waar beveiligingsproblemen bij een reisbureau beginnen
De meeste beveiligingsincidenten beginnen met een gewone reistaak. Een nieuwe klant wil met spoed een groepsboeking maken. Een leverancier stuurt een betaalverzoek. Een bericht meldt dat je GDS-login is verlopen. Een voormalige freelancer heeft nog toegang tot een systeem waar je team dagelijks mee werkt.
Deze situaties zetten je onder druk, omdat je team de reiziger wil helpen en de boeking wil beschermen. Door die druk sla je makkelijk een verificatiestap over of vul je inloggegevens in op de verkeerde pagina.
Reisgegevens vertellen bovendien veel over een persoon. Ze laten zien waarheen iemand wil reizen, wanneer diegene weg is, met wie diegene reist en hoe je diegene bereikt. Een reisprogramma voor een gezin, een zakelijke reisboeking en een dossier voor een groepsreis bevatten elk andere soorten persoonsgegevens.
Blootstelling
Vijf risicopunten om op te letten in een boeking
Volg één boeking door je werkproces
- Een nieuwe reiziger of een nieuw bedrijf vraagt om een groot aantal tickets, voordat je kunt controleren wie diegene vertegenwoordigt.
- Een e-mail verwijst naar een inlogpagina die lijkt op die van je GDS, betaalprovider of leveranciersportaal.
- Paspoortkopieën, betaalgegevens of actuele reisprogramma’s staan in mailboxen, spreadsheets of gedeelde mappen.
- Een filiaal, zelfstandige medewerker, leverancier of voormalige werknemer heeft nog toegang tot boekingssystemen.
- Een ransomware-incident blokkeert de reisprogramma’s en contactgegevens die je team nodig heeft om reizigers te helpen.
Elk probleem raakt meer dan alleen privacy. Het kan leiden tot ongeautoriseerde ticketuitgifte, chargebacks, debit memo’s, meldingen aan klanten, tijdverlies en verstoringen tijdens een lopende reis.
Een dreiging specifiek voor de reisbranche
Valse reizigersaanvragen en overgenomen GDS-accounts
Naast datalekken kampen reisbureaus met een tweede soort beveiligingsincident: fraudeurs kunnen met een valse klantaanvraag of een gestolen GDS-login ervoor zorgen dat het reisbureau tickets uitgeeft via het eigen account.
In 2026 meldde de Airlines Reporting Corporation meer activiteit rond onbevoegde toegang tot de GDS. ARC beschreef twee manieren om bij een reisbureau binnen te komen: een fraudeur doet zich voor als een legitiem reisbureau om toegang tot de GDS te krijgen, of een phishingbericht onderschept de inloggegevens van een medewerker. Met toegang kan de fraudeur zonder toestemming tickets uitgeven via het account van het reisbureau.
ARC meldde ook valse sites van Sabre Agency Workspace en trainingssites, bedoeld om inloggegevens van medewerkers te stelen. De pagina’s leken op vertrouwde reisportalen, maar de links leidden naar domeinen die er sterk op leken. Een valse GDS-pagina kan een aanvaller een geldige login opleveren, zonder dat de GDS-aanbieder zelf is gehackt.
Valse boekingsaanvragen: haast maskeert zwakke verificatie
ARC waarschuwde reisbureaus voor valse aanvragen voor zakelijke reizen en groepsreizen. Kenmerken zijn directe vertrekken, medische noodgevallen, onvolledige betaalgegevens, onbekende routes en verzoeken om de normale controles over te slaan.
Pauzeer wanneer: een nieuwe klant veel tickets wil voordat je het bedrijf, de reizigers, het reisprogramma en de betaling kunt verifiëren.
Valse GDS-sites: een bekend logo kan een gestolen loginpagina verbergen
Phishingberichten kunnen beweren dat een GDS-account is verlopen, dat een reservering geverifieerd moet worden of dat een workspace dringend opnieuw moet inloggen. De link kan naar een valse Sabre-portal of reisbureauportal leiden.
Gebruik: een vertrouwde bladwijzer of een handmatig ingevoerd adres van de leverancier. Log niet in via een onverwachte link in een e-mail.
Toegang via derden: je eigen systeem hoeft niet de toegangspoort te zijn
ARC meldde een geval waarin onbevoegd tickets werden uitgegeven nadat een filiaal van een derde partij was gehackt, terwijl het ticketingsysteem van het reisbureau zelf niet direct was aangetast.
Controleer: de toegang van filialen, contractors, zelfstandige agenten, leveranciers en oud-medewerkers. Verwijder die toegang zodra de samenwerking of functie eindigt.
Voordat je team een ticket uitgeeft, moet het twee vragen beantwoorden: “Komt deze aanvraag van een echte klant?” en “Brengt deze login me bij de echte GDS?” Bouw beide controles in de werkwijze in voordat iemand een ticket uitgeeft.
01
Breng in kaart welke data je reisbureau verwerkt
Je kunt informatie die je niet kunt terugvinden, ook niet beschermen. Begin met een eenvoudig overzicht van je data. Volg een boeking van de eerste aanvraag tot de nazorg na de reis en noteer elk systeem, elke medewerker en elke leverancier die ermee te maken krijgt.
Vragen
Stel deze vragen bij elk type data
- Welke informatie verzamelen we?
- Waarom hebben we die nodig?
- Waar slaan we die op?
- Wie kan die bekijken, wijzigen, downloaden of delen?
- Welke leveranciers of platforms ontvangen die?
- Wanneer moeten we die verwijderen?
Systemen
Neem de systemen mee die je team dagelijks gebruikt
- E-mail, CRM en GDS
- Mid-officeplatform en boekhoudsoftware
- Betaalprovider, gedeelde schijven en spreadsheets
- Software voor reisprogramma’s, reisapps en leveranciersportalen
Groepeer informatie vervolgens op risico. Openbare bestemmingsinformatie vraagt een ander beschermingsniveau dan paspoortgegevens, betaalgegevens of het noodcontact van een zakenreiziger. Geef de meest gevoelige data de minste toegangspunten.
Kijk na wat je team bewaart. Oude paspoortkopieën, dubbele spreadsheets, gedownloade boekingsbestanden en e-mailbijlagen vergroten het risico. Bepaal per categorie een bewaartermijn en verwijder informatie zodra je die niet meer nodig hebt. Houd daarbij rekening met de wettelijke en contractuele regels die in jouw markt gelden.
02
Accounts en toegang beveiligen
Gehackte accounts geven aanvallers directe toegang tot boekingsgegevens, e-mailgesprekken, betaalprocessen en klantdossiers. Bescherm elk account met maatregelen die je team consequent kan toepassen.
Vereis multifactorauthenticatie
Schakel multifactorauthenticatie in voor e-mail, CRM, cloudopslag, boekingssystemen, betaalprogramma’s, beheerdersaccounts en elk ander platform dat dit ondersteunt. Een gestolen wachtwoord mag niet de enige sleutel tot een bedrijfssysteem zijn.
Gebruik phishingbestendige authenticatie als een aanbieder die biedt. Is die optie er niet, kies dan een authenticatie-app of beveiligingssleutel in plaats van alleen sms-berichten.
Geef iedereen een eigen account
Deel geen inloggegevens van een algemeen account van het reisbureau. Met persoonlijke accounts zie je wie een dossier heeft geopend, pas je rechten aan als iemand van functie verandert en trek je de toegang in als een medewerker of freelancer vertrekt.
Geef mensen de toegang die ze nodig hebben voor hun werk. Een salescoördinator moet misschien reizigersgegevens kunnen inzien, terwijl een beheerder instellingen moet kunnen beheren.
Gebruik een wachtwoordmanager
Met een wachtwoordmanager maakt je team unieke wachtwoorden aan en deelt het toegang via beheerde kluizen in plaats van via e-mail of spreadsheets. Gebruik nooit hetzelfde wachtwoord voor je e-mailaccount en voor een leverancier of boekingsplatform.
Controleer de toegang minstens twee keer per jaar en na elke functiewijziging. Verwijder voormalige medewerkers, oude freelancers, ongebruikte koppelingen en accounts die geen actief proces meer ondersteunen.
GDS
Bescherm de toegang tot GDS en ticketing
- Schakel multifactorauthenticatie in overal waar de GDS of een gekoppelde dienst dit ondersteunt.
- Controleer nieuwe zakelijke klanten via contactgegevens die je zelf hebt opgezocht, niet alleen via het e-mailverzoek.
- Bekijk de ticketactiviteit regelmatig, vooral bij vertrekken op korte termijn, ongebruikelijke routes, enkele reizen, nieuwe reizigersprofielen en plotselinge stijgingen in volume.
- Trek de toegang in zodra een medewerker, freelancer, vestiging of leverancier de samenwerking beëindigt.
- Heeft iemand inloggegevens ingevoerd op een verdachte pagina, reset dan het wachtwoord, registreer MFA opnieuw, scan het apparaat en neem direct contact op met de GDS en ARC.
03
Train je team in het herkennen van echte aanvallen
De meeste reisbureaus ontvangen berichten die vertrouwd lijken: een factuur van een leverancier, een verzoek om een vluchtwijziging, een betaallink van een hotel of een dringend bericht van een leidinggevende. Aanvallers gebruiken die vertrouwde situaties om druk te zetten.
Pauzeer
Leer je team om even te pauzeren als een bericht vraagt om
- Een wachtwoord, eenmalige code of betaalgegevens
- Een wijziging van de bankgegevens van een leverancier
- Een dringende overboeking of terugbetaling
- Een paspoortkopie of klantenlijst
- Een link om in te loggen op een boekings- of betaalsysteem
Controleer gevoelige verzoeken via een bekend kanaal. Bel de leverancier op een telefoonnummer dat al in je administratie staat, niet op het nummer in het bericht. Meld verdachte berichten snel, zodat je team collega’s kan waarschuwen.
CISA adviseert kleine en middelgrote bedrijven om phishingbewustzijn, sterke wachtwoorden, multifactorauthenticatie en software-updates tot hun basisbeveiliging te rekenen. Die maatregelen vormen een bruikbaar startpunt voor een reisbureau, zonder dat je een groot technisch team nodig hebt.
04
Beveilig apparaten en bedrijfssoftware
Je team kan reisgegevens openen via laptops, telefoons, tablets en thuisnetwerken. Stel een minimumstandaard vast voor elk apparaat dat verbinding maakt met bedrijfssystemen.
Standaard
Een minimumstandaard voor elk apparaat
- Installeer updates van het besturingssysteem en van applicaties snel.
- Schakel volledige schijfversleuteling in op laptops en mobiele apparaten.
- Gebruik automatische schermvergrendeling na een korte periode van inactiviteit.
- Houd de bescherming tegen malware actief en beperk beheerdersrechten.
- Scheid zakelijke accounts waar mogelijk van privéaccounts.
- Download geen klantbestanden naar onbeheerde privéapparaten.
- Verwijder de toegang van verloren apparaten en wis ze op afstand als de technologie dat toelaat.
Controleer elke integratie die met je belangrijkste systemen is verbonden. Een oude connector of ongebruikte automatisering kan toegang behouden lang nadat het oorspronkelijke project is afgelopen. Houd een lijst bij van integraties, hun doel, hun eigenaar en de gegevens die ze kunnen lezen of versturen.
05
Ga zorgvuldig om met betaalgegevens
Betaalgegevens verdienen een eigen werkwijze. Zet volledige creditcardnummers of beveiligingscodes niet in e-mail, chat, spreadsheets, reisdocumenten, screenshots of gedeelde mappen.
Aanbieder
Gebruik gehoste betaalformulieren of tokenisatie
Als een aanbieder de kaartgegevens opslaat, controleer dan wat je reisbureau zelf nog moet doen en welke PCI DSS-verplichtingen gelden. De PCI Security Standards Council legt uit dat PCI DSS geldt voor organisaties die betaalrekeninggegevens opslaan, verwerken of doorsturen, en voor systemen die de beveiliging ervan kunnen beïnvloeden.
Regel voor medewerkers
Geef medewerkers een duidelijke regel voor betaalverzoeken
Een klant moet weten welke betaalpagina hij moet gebruiken, en je team moet weten hoe het een echt betaalbericht herkent. Houd kaartgegevens buiten de werkstroom voor reisprogramma’s wanneer het proces dat toelaat.
06
Controleer de beveiliging van je technologiepartners
Een reisbureau kan intern goed werken en toch risico’s overnemen van een leverancier. Controleer de systemen die reizigersgegevens, betaalgegevens, documenten en locatiegegevens verwerken.
Stel elke belangrijke technologieaanbieder deze vragen:
| Vraag | Wat je wilt weten |
|---|---|
| Hoe versleutelen jullie gegevens? | Bescherming tijdens de verzending en tijdens de opslag door de aanbieder |
| Hoe melden gebruikers zich aan? | MFA, SSO, wachtwoordregels en maatregelen voor accountblokkering |
| Hoe beperken jullie de toegang van medewerkers? | Rollen, minimale rechten, toegangscontroles en beheerdersinstellingen |
| Hoe herstellen jullie na een incident? | Back-upfrequentie, herstelpunten, hersteltests en bedrijfscontinuïteit |
| Hoe testen jullie de dienst? | Onafhankelijke tests, beheer van kwetsbaarheden en veilige releaseprocessen |
| Waar hosten en verwerken jullie gegevens? | Regio’s, subverwerkers, grensoverschrijdende doorgifte en contractuele waarborgen |
| Wat gebeurt er na afloop van het contract? | Gegevensexport, verwijdering, bewaartermijnen en bevestiging van verwijdering |
| Hoe informeren jullie klanten? | Contactpersonen bij incidenten, responsproces en toezeggingen over meldingen |
Vraag de aanbieder om de beveiligingsdocumentatie, de privacyvoorwaarden, de verwerkersovereenkomst en de lijst met subverwerkers. Zie certificeringen als één onderdeel van je beoordeling. Je moet nog steeds begrijpen hoe de aanbieder de specifieke dienst beheert die je reisbureau gaat gebruiken.
07
Maak back-ups en test het herstel
Met back-ups herstel je na ransomware, per ongeluk verwijderde gegevens, systeemstoringen en andere incidenten. Ze helpen alleen als ze de informatie bevatten die je team nodig heeft en je die ook echt kunt terugzetten.
Bepaal je kritieke systemen
Bij een reisbureau gaat het bijvoorbeeld om boekingsgegevens, actuele reisprogramma’s, contactgegevens van reizigers, bevestigingen van leveranciers, financiële gegevens en de supporthistorie.
Stel een hersteldoel vast
Bepaal hoeveel recente gegevens je kunt missen en hoe snel je team het werk moet kunnen hervatten. Bescherm back-ups tegen gewone gebruikersaccounts en zorg dat een aanvaller niet met één gehackte login alle kopieën kan verwijderen.
Test elk jaar een herstel
Test minstens één keer per jaar een herstel. Laat iemand de herstelde bestanden openen en controleren of het team ermee kan werken bij een echte verstoring. Leg het resultaat vast en los tekortkomingen op zolang de oefening vers in het geheugen ligt.
08
Stel een incidentplan op
Een incidentplan voorkomt verwarring wanneer je team weinig informatie en tijd heeft. Houd de eerste versie zo kort dat iedereen er direct mee kan werken. Leg vast:
Plan
Wat je incidentplan moet bevatten
- Wie de aanpak leidt en wie dringende beslissingen mag nemen.
- Hoe medewerkers een verdachte e-mail, een verloren apparaat of een gehackt account melden.
- Welke technologieleveranciers, verzekeraars, juridisch adviseurs en autoriteiten je moet contacteren.
- Hoe je een apparaat of account isoleert zonder bewijs te vernietigen.
- Hoe je reizigers blijft ondersteunen als boekings- of communicatiesystemen offline gaan.
- Hoe je beoordeelt welke gegevens zijn getroffen en hoe je volgens de geldende regels met klanten communiceert.
- Hoe je systemen herstelt en na het incident de oorzaak onderzoekt.
Houd één keer per jaar een korte oefening. Geef het team een realistisch scenario, zoals een gehackte mailbox met paspoortkopieën of een ransomware-aanval die de toegang tot actuele reisprogramma’s blokkeert. Controleer of iedereen weet wie je moet bellen, waar de back-up staat en hoe je reizigers helpt terwijl de systemen herstellen.
De wettelijke meldplicht hangt af van de landen, de soorten gegevens, de contracten en de betrokken personen. Laat een gekwalificeerd juridisch adviseur bevestigen welke regels voor jouw bedrijf gelden. Je incidentplan moet die adviseur snel de informatie geven die nodig is.
09
Bouw een vaste beveiligingsroutine op
Beveiliging verbetert als je team het als een vaste werkgewoonte ziet. Voeg een klein aantal controles toe aan je bestaande managementritme.
| Moment | Controle |
|---|---|
| Elke dag | Meld verdachte berichten, volg de betalingsprocedures en voer dringende beveiligingsupdates uit |
| Elke maand | Controleer waarschuwingen, nieuwe gebruikers, voormalige gebruikers, koppelingen en ongebruikelijke toegang |
| Elk kwartaal | Verwijder verouderde exports, beoordeel belangrijke leveranciers en actualiseer de richtlijnen voor medewerkers |
| Twee keer per jaar | Controleer gebruikersrechten en beheerdersaccounts |
| Elk jaar | Test back-ups, oefen het incidentplan en controleer je datakaart |
Noteer per controle wie de eigenaar is en op welke datum je die hebt uitgevoerd. Met een eenvoudig register kan je team duidelijk laten zien wat het heeft gecontroleerd en wat het heeft aangepast.
mTrip
Zo pakt mTrip gegevensbeveiliging aan
Als je een reisplanner voor reisbureaus en touroperators of een reisapp in jouw huisstijl beoordeelt, vraag de aanbieder dan om de beveiligingsmaatregelen in dezelfde praktische termen toe te lichten. mTrip publiceert zijn beveiligingspraktijken voor reisbureaus, touroperators en TMC’s.
Gehost op Amazon Web Services
Het platform draait op Amazon Web Services. Europese klanten worden gehost in Frankfurt (Duitsland), met geüploade bestanden opgeslagen in Londen (Verenigd Koninkrijk). Andere klanten worden gehost in Noord-Virginia (Verenigde Staten).
Versleuteld tijdens verzending en opslag
mTrip geeft aan dat verkeer van het platform en de API TLS 1.2 of hoger gebruikt. Databases, bestandsopslag en back-ups worden in rust versleuteld met AES-256. De applicatie versleutelt bovendien gevoelige reizigersgegevens, zoals e-mailadressen, telefoonnummers, geboortedatums en boekingsreferenties.
Dagelijkse back-ups, elk jaar getest
Het platform maakt dagelijks versleutelde back-ups, met point-in-time recovery over zeven dagen. mTrip kopieert back-ups naar een tweede AWS-regio, beschermt ze tegen verwijdering en test minstens één keer per jaar een herstel.
Beheerde toegang en onafhankelijke tests
mTrip beschrijft beheerde toegang, multifactorauthenticatie, logging van beheerdersacties, continue detectie van bedreigingen en minstens één keer per jaar een onafhankelijke test van het platform en de mobiele apps.
Klanten kunnen beveiligingsdocumenten opvragen via het mTrip Trust Center. Vergelijk de actuele gegevens met jouw eigen eisen voordat je een technologieleverancier kiest.
Beveiligingsbeoordeling
Vragen voor elke leverancier van reistechnologie
Vraag waar gegevens worden gehost, hoe toegang wordt beheerd, hoe back-ups worden getest, hoe incidenten worden gemeld en wat er met jouw gegevens gebeurt als het contract eindigt.
Begin hier
Begin met de maatregelen die de meeste risico’s verkleinen
Met een kort eerste project kom je al een flink eind:
Actieplan
Zes maatregelen voor een eerste project
- Breng de gegevens in jouw boekings- en reisprogrammaproces in kaart.
- Schakel multifactorauthenticatie in voor elk belangrijk account.
- Verwijder oude gebruikers, gedeelde logins en ongebruikte koppelingen.
- Houd volledige betaalkaartgegevens uit e-mails, documenten en spreadsheets.
- Controleer of back-ups werken door een herstel te testen.
- Schrijf een incidentplan en oefen het met je team.
Gegevensbeveiliging beschermt de reizigerservaring waar jouw reisbureau hard aan werkt. Ook kan je team zo veiliger boekingen, documenten en ondersteuning bij verstoringen beheren naarmate het aantal reizen groeit.
Meer tips vind je in de best practices voor reisdocumenten en de checklist voor zorgplichtsoftware van mTrip.
De bredere reissector
Wat andere reisorganisaties van aanvallen hebben geleerd
Deze voorbeelden gaan over grotere reisorganisaties, maar dezelfde problemen kunnen ook voorkomen in de werkwijze van een reisbureau of touroperator: verouderde systemen, gestolen inloggegevens, betaalgegevens, toegang voor leveranciers en zwakke herstelplannen.
Hotelgroep
Marriott en de reserveringsdatabase van Starwood
In november 2018 maakte Marriott bekend dat een onbevoegde partij sinds 2014 toegang had tot het netwerk van Starwood. De database bevatte gegevens van maximaal ongeveer 500 miljoen gasten. Bij circa 327 miljoen gasten ging het om combinaties van namen, adressen, telefoonnummers, e-mailadressen, paspoortnummers, gegevens van loyaliteitsaccounts, geboortedata en aankomst- en vertrekinformatie.
Wat je hieruit kunt leren: Controleer overgenomen systemen, oude koppelingen en databases van overgenomen bedrijven. Houd een actueel overzicht van je data bij, verwijder gegevens die je niet meer nodig hebt en houd toezicht op de toegang tot reserveringsbestanden.
Luchtvaartmaatschappij
British Airways en betaalgegevens op de website
British Airways meldde in 2018 een incident met klantgegevens die via de website waren ingediend. De Britse Information Commissioner’s Office stelde later vast dat het om gegevens van ongeveer 429.000 mensen ging, waaronder inlog-, betaalkaart-, boekings-, naam- en adresgegevens.
Wat je hieruit kunt leren: Beveilig openbare boekingsformulieren, beheerdersaccounts, betaalprocessen en gekoppelde diensten. Bewaar betaalgegevens niet in systemen die ze niet nodig hebben en let op ongebruikelijke activiteit.
Luchtvaartmaatschappij
easyJet en een grote klantendatabase
easyJet maakte in 2020 een datalek bekend dat ongeveer 9 miljoen klanten trof. Bij het incident waren ook de kaartgegevens van 2.208 klanten betrokken. De omvang laat zien hoe snel één gehackt systeem kan uitgroeien tot een probleem voor klantcommunicatie, juridische zaken en klantenservice.
Wat je hieruit kunt leren: Weet welke categorieën gegevens je bewaart, wie toegang nodig heeft en hoe je getroffen klanten gaat bereiken. Je incidentplan moet naast technisch herstel ook de klantenservice omvatten.
TMC
CWT en de verstoring door ransomware
In 2020 werd de TMC CWT getroffen door een ransomware-aanval. Volgens Reuters beweerden de aanvallers 30.000 bestanden te hebben gekopieerd en betaalde CWT tijdens de afhandeling losgeld. Het incident laat zien hoe snel een systeemstoring gevolgen heeft voor een bedrijf waarvan de teams lopende reizen beheren en reizigers ondersteunen.
Wat je hieruit kunt leren: Back-ups en herstelprocedures verdienen net zoveel aandacht als preventie. Test of je team nog bij de belangrijkste reisgegevens kan en reizigers kan helpen als je hoofdsystemen uitvallen.
Bekijk je werkproces voor reisgegevens samen met mTrip
Bespreek met het mTrip-team je reisprogrammagegevens, reisdocumenten, reisapps in jouw huisstijl en beveiligingseisen. Lees eerst de beveiligingspagina van mTrip als je een leveranciersbeoordeling start.
Verder lezen
Bronnen en verder lezen
- NIST Cybersecurity Framework 2.0
- CISA: Secure Your Business
- PCI Security Standards Council: Merchant Resources
- Marriott: beveiligingsincident met de reserveringsdatabase van Starwood-gasten
- UK Information Commissioner’s Office: handhavingsdossier over British Airways
- UK Information Commissioner’s Office: handhavingsdossier over easyJet
- Reuters: CWT paid $4.5 million ransom to ransomware gang
- ARC: Fraud alerts and schemes affecting travel agencies
- ARC: Reasonable Care and Cyber Security Guide
- ARC: Required Agent Security Training