Nieuwe tools goedkeuren: zo werkt het goedkeuringsproces in ComplianceHive

Elke week duiken er nieuwe tools op. Vooral AI-tools. En bijna allemaal willen ze toegang tot een of andere vorm van data. Voordat je team de nieuwste app gaat uitproberen die iemand op Product Hunt tegenkwam, wil je weten wat die app met jullie gegevens doet. De AVG vereist dat, en eerlijk gezegd is het ook gewoon verstandig.

Deze handleiding loopt door de vragen die je moet stellen en laat zien hoe het ChangeRequest-goedkeuringsproces in ComplianceHive het hele traject vastlegt.

Waarom een goedkeuringsproces voor software?

Je team gebruikt waarschijnlijk al tientallen tools. Projectmanagementsoftware met klantnamen erin, AI-schrijfassistenten die verwerken wat mensen erin plakken, wachtwoordmanagers met de sleutels tot alles.

Zonder een proces gaan mensen gewoon hun gang. Iemand maakt een gratis account aan, voert klantgegevens in, en verder weet niemand dat die tool bestaat. Zo beland je data op plekken die je niet kunt traceren, en dat is precies het probleem dat de AVG probeert op te lossen.

Een goedkeuringsproces hoeft niet zwaar te zijn. Het moet er gewoon zijn.

Vijf vragen voordat je een tool goedkeurt

Voordat je ja zegt tegen een nieuwe tool, loop je deze vragen langs. Ze gaan over het juridische, de beveiliging en de kosten.

1. Welk probleem lost deze tool op?

Begin hier. Als niemand helder kan uitleggen waarom het team deze tool nodig heeft, zegt dat genoeg. "Het ziet er gaaf uit" is geen reden. "We zijn vier uur per week bezig met data overzetten tussen spreadsheets" wel.

2. Welke gegevens krijgt de tool te zien?

Breng precies in kaart wat erin gaat. Klantnamen? E-mailadressen? Financiele gegevens? Interne documenten? Het antwoord bepaalt hoe groot de impact is als er iets misgaat.

3. Waar wordt de data opgeslagen?

Locatie is belangrijker dan veel mensen denken. Data in de EU valt onder de AVG. Data in de Verenigde Staten kan onderworpen zijn aan toegangsverzoeken van de Amerikaanse overheid. Sommige sectoren hebben nog strengere regels over waar data mag staan. Check waar de leverancier zijn servers daadwerkelijk heeft staan, niet alleen waar het bedrijf gevestigd is.

4. Hoe beschermen ze jouw data?

Is de data versleuteld tijdens transport en in opslag? Heeft de leverancier certificeringen zoals ISO 27001 of SOC 2? Verkopen of delen ze data met derden? Jouw klanten vertrouwen hun informatie aan jou toe. De leverancier moet dat vertrouwen ook waarmaken.

5. Wat kost het?

Een voor de hand liggende vraag, maar stel hem zorgvuldig. Een gratis tool met zwakke beveiliging kan je uiteindelijk meer kosten dan een betaalde tool met degelijke dataprotectie. En "gratis" betekent vaak dat jouw data het product is.

Hoe ComplianceHive dit aanpakt

In ComplianceHive loopt elke wijziging via een ChangeRequest. Als je bekend bent met pull requests in softwareontwikkeling, is het concept vergelijkbaar: iemand stelt een wijziging voor, reviewers bekijken het, en de wijziging gaat pas door na goedkeuring.

Dit is geen optionele instelling. Zo werkt het product.

Zo ziet de flow eruit:

Stap 1: Een collega voegt een Systeem toe of wijzigt er een

In ComplianceHive heten de tools en software die je organisatie gebruikt Systemen. Wanneer een collega een nieuw Systeem wil toevoegen of een bestaand Systeem wil bijwerken, vult diegene de gegevens in. Dit maakt een ChangeRequest aan met de status DRAFT.

Eén ChangeRequest kan meerdere Systemen bevatten. Stel dat je team een nieuwe projectmanagementtool wil adopteren en de oude wil uitfaseren. Beide wijzigingen gaan in dezelfde ChangeRequest.

Stap 2: Indienen ter beoordeling

Wanneer de ChangeRequest klaar is, zet de collega de status op PENDING_APPROVAL. Iedereen met reviewrechten krijgt een notificatie.

Stap 3: Reviewers beoordelen de ChangeRequest

Collega's met reviewrechten bekijken de voorgestelde wijzigingen. Ze beoordelen de ChangeRequest als geheel, niet de individuele Systemen apart. Eén review, alle gerelateerde wijzigingen gedekt.

Hier komen de vijf vragen van hierboven terug. Reviewers checken of de indiener ze voor elk Systeem in het verzoek heeft beantwoord.

Stap 4: Goedkeuren (of terugsturen)

Als reviewers tevreden zijn, gaat de ChangeRequest naar APPROVED. De wijzigingen worden vervolgens doorgevoerd op de daadwerkelijke Systeemrecords, en de ChangeRequest doorloopt APPLIED tot CLOSED.

Als er iets niet klopt, kan een enkele reviewer de ChangeRequest afwijzen. De status gaat naar REJECTED. Van daaruit kan de indiener het verzoek heropenen en terugzetten naar DRAFT om aan te passen en opnieuw in te dienen.

Stap 5: De audittrail

Elke actie op een ChangeRequest wordt vastgelegd. Wie het indiende, wie het reviewde, wanneer het werd goedgekeurd, wat er veranderde. De audittrail leeft op de ChangeRequest zelf. Als een auditor ooit vraagt "wie heeft deze tool goedgekeurd en wanneer?", heb je precies één plek om naar te wijzen.

Systeemstatussen

Zodra een Systeem bestaat in ComplianceHive, heeft het drie mogelijke statussen:

• DRAFT: wordt opgezet, nog niet in gebruik.
• ACTIVE: goedgekeurd en in gebruik door je organisatie.
• ARCHIVED: uitgefaseerd.

Drie statussen, geen grijze gebieden. Je kunt altijd zien welke tools je organisatie op dit moment gebruikt en welke zijn opgeborgen.

Alles bij elkaar

Stel de vijf vragen bij elk verzoek voor een nieuwe tool. Laat de ChangeRequest-flow het reviewproces en de papieren trail afhandelen. Wanneer de auditor langskomt, heb je alles gedocumenteerd op één plek in plaats van te graven in e-mailthreads en Slack-berichten.

Een gedocumenteerd goedkeuringsproces lost niet alles op, maar het is een goed begin.

Benieuwd hoe ComplianceHive er in de praktijk uitziet? Bekijk de functiepagina, of kijk op de prijzenpagina welk plan bij je past.