Hoe audit je een ATS of deze goed beveiligd is?

Een security-audit van een ATS controleert of de beveiligingsmaatregelen van het systeem én de eigen inrichting daadwerkelijk werken. Kijk onder meer naar gebruikersrechten, MFA, encryptie, logging, koppelingen, back-ups, incidentprocedures, hosting en certificeringen. Vraag bewijsstukken op bij de leverancier en test waar mogelijk zelf de inrichting. Voor technische penetratietesten is toestemming en een duidelijke scope nodig. Herhaal de audit periodiek en na belangrijke wijzigingen.

Inleiding

Een leverancier kan zeggen dat een ATS veilig is, maar een organisatie moet die claim ook kunnen beoordelen. Een security-audit kijkt daarom verder dan certificaten en documentatie. De controle omvat de techniek van de leverancier, de eigen configuratie, gebruikers, koppelingen en procedures. Dat maakt zichtbaar waar beveiligingsrisico’s werkelijk zitten.

Wat is een security-audit van een ATS?

Een security-audit is een gestructureerde beoordeling van de beveiliging van het recruitmentsysteem. Daarbij wordt gecontroleerd welke maatregelen bestaan, of ze correct zijn ingericht en of er bewijs is dat ze functioneren.

Een audit kan plaatsvinden tijdens de selectie van een nieuw ATS, vóór de livegang of periodiek tijdens het gebruik. De diepgang verschilt per organisatie. Een kleinere werkgever kan werken met een vragenlijst en documentcontrole. Een grote organisatie kan daarnaast securityspecialisten, technische tests en externe auditrapporten inzetten.

Begin met de scope van de audit

Een audit werkt alleen wanneer duidelijk is wat wordt beoordeeld. Kijk daarom niet alleen naar het centrale ATS. Neem ook onderdelen mee die toegang hebben tot kandidaatdata of het recruitmentproces ondersteunen.

De scope kan bijvoorbeeld bestaan uit:

het ATS zelf;
het kandidatenportaal en sollicitatieformulieren;
Single Sign-On en gebruikersaccounts;
API’s en andere koppelingen;
werken-bij-sites;
AI-functionaliteiten;
hosting en cloudinfrastructuur;
back-ups en herstelprocedures;
subleveranciers met toegang tot gegevens.

Leg ook vast wie verantwoordelijk is voor ieder onderdeel. Sommige maatregelen liggen bij de ATS-leverancier, terwijl gebruikersrechten en interne procedures vaak door de klant worden beheerd.

Vraag eerst beveiligingsdocumentatie op

Een leverancier moet belangrijke beveiligingsmaatregelen kunnen onderbouwen. RecruitmentTech adviseert bij een leveranciersbeoordeling onder meer te kijken naar encryptie, rollen en rechten, MFA, logging, back-ups, beveiligingstesten, certificeringen en incidentprocedures.

Vraag bijvoorbeeld om:

een actuele beschrijving van de beveiligingsarchitectuur;
ISO 27001-certificering en bijbehorende scope;
informatie over hosting en datalocaties;
beleid voor kwetsbaarheden en beveiligingsupdates;
informatie over periodieke penetratietesten;
overzicht van relevante subleveranciers;
back-up- en herstelprocedures;
incident- en datalekprocedures.

Een certificaat of vragenlijst is nuttig bewijs, maar vormt geen volledige audit. Controleer vervolgens ook de daadwerkelijke inrichting.

Audit gebruikersrechten en accounts

Een van de belangrijkste controles vindt plaats binnen de eigen ATS-omgeving. Bekijk welke gebruikers toegang hebben en of hun rechten nog aansluiten op hun werkzaamheden.

Selecteer bijvoorbeeld willekeurig enkele recruiters, hiring managers en beheerders. Controleer welke vacatures, kandidaatprofielen en beheerschermen zij kunnen openen.

Let speciaal op voormalige medewerkers, tijdelijke accounts en externe recruiters. Accounts die niet meer nodig zijn moeten worden afgesloten. Beheerdersrechten moeten beperkt blijven tot medewerkers die deze daadwerkelijk nodig hebben.

Test MFA en Single Sign-On

Controleer niet alleen of multifactorauthenticatie beschikbaar is, maar ook of deze daadwerkelijk verplicht is ingesteld. Een functie die niemand gebruikt levert weinig beveiliging op.

Wanneer de organisatie Single Sign-On gebruikt, controleer dan ook wat er gebeurt wanneer iemand uit dienst gaat. De toegang tot het ATS moet automatisch of via een betrouwbaar proces worden ingetrokken.

Test daarnaast of gedeelde accounts bestaan. Iedere gebruiker hoort bij voorkeur een persoonlijk account te hebben, zodat activiteiten later aan een specifieke gebruiker kunnen worden gekoppeld.

Controleer logging en monitoring

Een audit moet vaststellen of belangrijke activiteiten worden geregistreerd. Denk aan aanmeldingen, wijzigingen in rechten, exports, verwijderingen en aanpassingen aan instellingen.

Voer eventueel een gecontroleerde test uit. Exporteer bijvoorbeeld met een testaccount enkele records en controleer vervolgens of deze actie correct in het log verschijnt.

Vraag ook hoe lang loggegevens beschikbaar blijven en wie ze kan bekijken. Bij een beveiligingsincident moeten organisatie en leverancier kunnen reconstrueren wat er is gebeurd.

Controleer alle ATS-koppelingen

Integraties vormen een belangrijk onderdeel van de audit. Een ATS kan goed beveiligd zijn terwijl een oude API-sleutel of externe koppeling te ruime toegang heeft.

Maak daarom een overzicht van alle actieve integraties en controleer per verbinding:

welke gegevens worden uitgewisseld;
welke rechten de koppeling heeft;
hoe authenticatie plaatsvindt;
of de koppeling nog daadwerkelijk wordt gebruikt;
wie verantwoordelijk is voor het beheer;
hoe toegang kan worden ingetrokken.

Verwijder ongebruikte koppelingen en oude API-sleutels. Geef een integratie alleen toegang tot gegevens die nodig zijn voor de betreffende functie.

Vraag naar penetratietesten

Een penetratietest onderzoekt actief of technische kwetsbaarheden kunnen worden misbruikt. Vraag de ATS-leverancier of periodiek onafhankelijke penetratietesten worden uitgevoerd en hoe kritieke bevindingen worden opgelost.

Vraag bij voorkeur naar een recente managementsamenvatting of andere passende onderbouwing. Leveranciers hoeven niet noodzakelijk het volledige technische pentestverslag te delen, omdat daarin gevoelige informatie kan staan.

Wil je zelf een penetratietest uitvoeren op een SaaS-ATS, doe dat nooit zonder afspraken met de leverancier. Het NCSC adviseert vooraf onder meer doel, scope, testvorm en verantwoordelijkheden vast te leggen. Ook toestemming van betrokken cloud- of andere derde partijen kan nodig zijn.

Test of back-ups echt herstelbaar zijn

Vraag niet alleen of de leverancier back-ups maakt. Controleer ook hoe vaak herstel wordt getest en welke hersteldoelstellingen gelden na een ernstig incident.

Het Digital Trust Center adviseert organisaties periodiek te testen of een back-up daadwerkelijk kan worden teruggezet. Dat principe is ook relevant bij een ATS. Een back-up die technisch bestaat maar niet bruikbaar blijkt tijdens een incident biedt weinig zekerheid.

Vraag bijvoorbeeld wanneer de laatste hersteltest heeft plaatsgevonden en hoe lang het duurde voordat de dienst weer beschikbaar was.

Controleer incidentprocedures

Een goede audit kijkt ook naar wat er gebeurt wanneer beveiliging faalt. Controleer of leverancier en klant weten wie welke actie uitvoert bij een hack, datalek of langdurige storing.

De Autoriteit Persoonsgegevens adviseert organisaties bij een datalek eerst overzicht te krijgen, het incident te stoppen, de risico’s te beoordelen en vast te stellen of melding nodig is. Daarvoor is actuele informatie van de ATS-leverancier noodzakelijk.

Controleer daarom contractueel:

hoe snel een leverancier een incident meldt;
welk contactpunt beschikbaar is;
welke informatie de klant ontvangt;
hoe onderzoek wordt ondersteund;
hoe verbetermaatregelen worden opgevolgd.

Gebruik certificeringen als bewijs, niet als eindpunt

ISO 27001 kan aantonen dat een leverancier informatiebeveiliging structureel beheert. Controleer wel of het ATS en de relevante dienstverlening daadwerkelijk binnen de scope van het certificaat vallen.

Een audit mag niet stoppen zodra een geldig certificaat is gevonden. Certificering van een managementsysteem betekent niet automatisch dat ieder technisch onderdeel van het ATS zonder kwetsbaarheden is. Combineer certificaten daarom met configuratiecontroles, bewijsstukken en technische tests.

Maak van de audit een periodieke controle

Een ATS verandert voortdurend. Er komen nieuwe gebruikers, koppelingen, AI-functies en softwareversies bij. Een audit van twee jaar geleden zegt daarom niet automatisch voldoende over de situatie van vandaag.

Plan minimaal periodiek een nieuwe beoordeling en voer tussentijdse controles uit bij belangrijke wijzigingen. Denk aan een nieuwe integratie, grote migratie, overname van de leverancier, security-incident of introductie van nieuwe AI-functionaliteit.

Praktijkvoorbeeld

Een organisatie gebruikt al drie jaar hetzelfde ATS en voert voor het eerst een uitgebreide security-audit uit. De leverancier heeft een geldig ISO 27001-certificaat en recente beveiligingstesten. De technische basis lijkt op orde.

Tijdens de eigen configuratiecontrole blijken echter veertien voormalige hiring managers nog toegang te hebben. Ook staat een oude integratie met een assessmenttool actief en blijkt MFA voor enkele externe gebruikers niet verplicht.

De organisatie trekt oude accounts en API-toegang in, verplicht MFA en voert voortaan ieder kwartaal een toegangscontrole uit. De audit laat daarmee zien dat leveranciersbeveiliging en eigen beheer afzonderlijk moeten worden gecontroleerd.

Checklist voor een ATS-security-audit

Leg vooraf de scope en verantwoordelijkheden vast.
Vraag actuele securitydocumentatie en certificeringen op.
Controleer gebruikersaccounts, rollen en beheerdersrechten.
Test of MFA en Single Sign-On correct zijn ingericht.
Controleer logging met enkele praktische testhandelingen.
Inventariseer alle API’s, koppelingen en subleveranciers.
Vraag bewijs van recente beveiligings- en penetratietesten.
Controleer of back-up en herstel aantoonbaar worden getest.
Beoordeel incident- en datalekprocedures.
Leg bevindingen, eigenaren en hersteltermijnen schriftelijk vast.

Veelgestelde vragen

Hoe vaak moet je een ATS auditen?

Voer periodiek een uitgebreide audit uit en controleer kritieke onderdelen vaker. Herhaal de beoordeling ook na belangrijke wijzigingen, nieuwe koppelingen of beveiligingsincidenten.

Mag je zelf een penetratietest uitvoeren op een ATS?

Niet zonder toestemming en duidelijke afspraken. Bij SaaS-software zijn systemen en infrastructuur eigendom of verantwoordelijkheid van andere partijen. Stem scope, methode en toestemming vooraf af met de ATS-leverancier.

Is ISO 27001 voldoende als security-audit?

Nee. ISO 27001 geeft informatie over het managementsysteem van de leverancier. Een ATS-audit moet daarnaast de technische functies, eigen configuratie, gebruikersrechten, koppelingen en procedures controleren.

Wie moet betrokken zijn bij een ATS-security-audit?

Betrek minimaal functioneel beheer en IT of informatiebeveiliging. Afhankelijk van de omvang kunnen ook privacy, juridische zaken, interne audit en externe securityspecialisten nodig zijn.