Beveiliging #

EthicsPortal verwerkt gevoelige klokkenluidersgegevens. Op deze pagina documenteren wij de specifieke technische en organisatorische maatregelen die wij hebben getroffen. Het is geschreven voor compliance officers, FG’s en juridische teams die het platform beoordelen.

Laatst bijgewerkt: 2026-05-17.

Gegevensversleuteling #

Alle gevoelige velden worden in rust versleuteld met Rails ActiveRecord Encryption met niet-deterministische versleuteling (elke versleuteling produceert een unieke cijfertekst, wat patroonanalyse voorkomt).

Niet-deterministische versleuteling betekent dat deze velden op databaseniveau niet op waarde kunnen worden bevraagd. Zelfs met volledige databasetoegang kan een aanvaller niet zoeken naar een specifieke naam van een melder in de registraties.

Alle verbindingen met EthicsPortal gebruiken HTTPS/TLS. Onversleutelde HTTP-verzoeken worden omgeleid.

Anonimiteit en privacy #

IP-anonimisering #

Portaalroutes (indiening van meldingen, opzoeken van zaken, berichten) gebruiken een SHA256-eenrichtingshash van het verzoek-IP, uitsluitend voor snelheidsbeperking. De hash is niet omkeerbaar — het is niet mogelijk het oorspronkelijke IP uit de opgeslagen waarde te herstellen.

Op applicatieniveau wordt het ruwe IP-adres van de melder niet opgeslagen in de database, en applicatielogs voor portaalroutes worden opgeschoond om de anonimiteit van klokkenluiders te beschermen.

Verwijdering van bestandsmetadata #

Geüploade bestanden worden vóór opslag automatisch ontdaan van identificerende metadata:

Het verwijderen van metadata wordt server-side vóór opslag uitgevoerd. Voor bestandstypen die door exiftool worden verwerkt, hangt dit af van de aanwezigheid van de standaard productietooling.

Virusscanning #

Alle geüploade bestanden worden automatisch gescand op malware met ClamAV , een opensource-antivirusengine. Het scannen gebeurt server-side in een achtergrondproces na de upload. Bestanden die de scan niet hebben doorstaan, worden geblokkeerd voor aflevering en geïnfecteerde bestanden worden automatisch verwijderd.

Bestanden worden gescand op de infrastructuur van EthicsPortal — er worden geen bestandsgegevens naar scandiensten van derden verzonden.

Anonimiteit van de behandelaar #

Klokkenluiders zien nooit de echte namen of e-mailadressen van de personen die hun melding behandelen. Alle berichten van behandelaars worden weergegeven als “Zaakbehandelaar”. Dit beschermt de identiteit van de behandelaar en voorkomt social engineering.

Geen tracking #

EthicsPortal gebruikt geen trackingcookies, reclamepixels of fingerprintingscripts van derden. Wij gebruiken Cloudflare Web Analytics alleen op marketingpagina’s — het is cookievrij, verzamelt geen persoonsgegevens en is volledig AVG-conform. Het meldportaal zelf heeft geen analytics.

Huidige zekerheidsstatus #

EthicsPortal claimt op deze site momenteel geen geaccrediteerde ISO 27001-certificering. Het publiceert evenmin een onafhankelijke audit door een derde van de anonimiteitsarchitectuur. Mocht dat veranderen, dan worden de reikwijdte en de datum hier gepubliceerd.

Materiaal voor beveiligingsbeoordeling #

Klanten die inkoop- of juridisch beoordelingsmateriaal nodig hebben, kunnen dit tijdens de inkoop aanvragen. Beschikbaar materiaal kan onder meer omvatten: een ondertekende verwerkersovereenkomst, register- en belastingbewijs, een ingevulde beveiligingsvragenlijst en schriftelijke antwoorden over back-up- en herstelprocedures, geprivilegieerde productietoegang en de afhandeling van incidentrespons.

Toegangscontrole #

Autorisatie wordt op applicatieniveau afgedwongen met Pundit -policy’s.

• Behandelaars kunnen geen meldingen inzien waaraan zij noch zijn toegewezen, noch deelnemen. Deelnemers worden uitdrukkelijk toegevoegd door een beheerder of de primaire toegewezen persoon (bijvoorbeeld om juridisch of HR te betrekken).
• Melders hebben geen gebruikersaccount — zij benaderen hun melding via een zaak-ID (WB-XXXX-XXXX) plus een 6-cijferige toegangscode die zij bij indiening kiezen.
• Elke controlleractie controleert de autorisatie. Ongeoorloofde toegangspogingen worden geblokkeerd en gelogd.

Tweefactorauthenticatie #

Behandelaars- en beheerdersaccounts kunnen TOTP-gebaseerde tweefactorauthenticatie inschakelen via elke standaard authenticator-app (Google Authenticator, 1Password, Authy en compatibele alternatieven). Eenmaal ingeschakeld vereist het aanmelden zowel de primaire inloggegevens als een roterende 6-cijferige code.

Melders authenticeren zich eveneens met twee factoren: het zaak-ID (iets wat zij bezitten) en de toegangscode die zij bij indiening kozen (iets wat zij weten). De toegangscode wordt uitsluitend opgeslagen als bcrypt-digest en kan niet worden hersteld. De inbox voor opvolging en het plaatsen van berichten zijn achter deze controle aan een sessie gebonden, zodat een gelekt zaak-ID alleen de melding niet kan lezen of de melder kan nabootsen.

Levenscyclus van de sessie #

Elke geauthenticeerde sessie registreert last_seen_at bij elk verzoek (gedebounced). Gebruikers kunnen hun actieve sessies bekijken, zien wanneer elke voor het laatst actief was, elke sessie afzonderlijk intrekken of zich vanuit de accountinstellingen in één keer afmelden bij alle andere sessies.

Sessies verlopen automatisch na 14 dagen inactiviteit. Het volgende verzoek vanuit een inactieve sessie vernietigt de server-side registratie, wist de cookie en dwingt herauthenticatie via een nieuwe magic link af. Een nachtelijke taak ruimt verlaten sessies op met dezelfde time-out, zodat user_agent en ip_address niet langer dan het inactiviteitsvenster worden bewaard, zelfs als de gebruiker nooit terugkeert.

Magic-link-authenticatie beperkt de impact van langdurige sessies: een gestolen sessiecookie levert geen herbruikbare inloggegevens op, en herauthenticatie vereist toegang tot e-mail.

Toegang en uitdiensttreding van leden #

Organisatietoegang wordt afgedwongen op de grens van het verzoek. Wanneer een lid wordt gedeactiveerd:

• Toegang tot de organisatie wordt onmiddellijk geweigerd, ook op eerder opgeslagen URL’s.
• Open zaaktoewijzingen worden ongedaan gemaakt.
• Deelnemerschappen worden verwijderd.
• De auditloggeschiedenis die aan het lid kan worden toegerekend, blijft behouden.
• Het gedeactiveerde lid wordt op de hoogte gesteld.
• Reactivering herstelt de eerdere zaaktoegang niet automatisch.

De laatste actieve beheerder en de eigenaar van de organisatie kunnen niet worden gedeactiveerd. Alle deactiverings- en reactiveringsgebeurtenissen worden weggeschreven naar het auditlog met uitsluitend toevoegingen.

Lidmaatschappen zonder nalevingsvoetafdruk (geen auditlogvermeldingen, geen toewijzingen, geen deelnemerschappen) worden bij verwijdering hard verwijderd; lidmaatschappen met een voetafdruk worden zacht gedeactiveerd zodat de audit trail herleidbaar blijft.

Snelheidsbeperking #

Endpoints van het openbare portaal zijn aan snelheidsbeperking onderworpen om misbruik en opsommingsaanvallen te voorkomen:

Snelheidsbeperking gebruikt de hierboven beschreven IP-eenrichtingshash — er wordt geen feitelijk IP opgeslagen.

Audit en naleving #

Audit trail met uitsluitend toevoegingen #

Elke actie in EthicsPortal wordt gelogd met:

• Tijdstip (UTC)
• Actor (welke gebruiker of welk systeemproces de actie uitvoerde)
• Type actie (melding aangemaakt, status gewijzigd, bericht verzonden, behandelaar toegewezen, melding ingezien, melding geëxporteerd, melding verwijderd, enz.)

Auditlogvermeldingen kennen uitsluitend toevoegingen. Ze kunnen door geen enkele gebruiker, ook niet door organisatiebeheerders, worden bewerkt of verwijderd. De volledige audit trail is opgenomen in pdf-zaakexports voor toezichthoudende controle.

Gegevensbewaring #

Organisaties configureren hun eigen bewaartermijn: 12, 24, 36, 48 of 60 maanden nadat een melding is gesloten. Wanneer de bewaartermijn verstrijkt, worden de melding en alle bijbehorende gegevens (berichten, bijlagen, auditlogvermeldingen) automatisch en permanent verwijderd door een achtergrondtaak.

Dit voldoet aan de eisen inzake opslagbeperking van de AVG (art. 5, lid 1, onder e) en de registratieverplichtingen van Richtlijn (EU) 2019/1937 (art. 17–18).

CSRF-bescherming #

Alle formulierindieningen zijn beschermd tegen cross-site request forgery met de ingebouwde CSRF-tokens van Rails.

Veilige ontwikkellevenscyclus #

EthicsPortal volgt een gedocumenteerde ontwikkellevenscyclus voor wijzigingen die de dienst raken. De fasen worden hier vermeld zodat een inkoopbeoordelaar ze kan koppelen aan de beheersmaatregelen A.8.25–A.8.29 van ISO/IEC 27001:2022 (zie de beheersmaatregelenmap voor de volledige toewijzing).

Afhankelijkheids- en patchbeheer #

EthicsPortal rolt geen end-of-life-softwarecomponenten uit. De applicatie draait op actief ondersteunde releases van Rails, Ruby, PostgreSQL en het onderliggende besturingssysteem; upstream-beveiligingsreleases worden doorlopend toegepast.

Afhankelijkheden worden continu gescand in continuous integration:

• Brakeman signaleert Rails-specifieke kwetsbaarheden bij elke wijziging.
• bundler-audit controleert het Gemfile tegen de Ruby Advisory Database bij elke wijziging en opnieuw volgens een dagelijks schema, zodat nieuw bekendgemaakte adviezen worden opgemerkt, zelfs wanneer er geen code is gewijzigd.
• importmap audit scant JavaScript-imports op bekende kwetsbaarheden bij elke wijziging en opnieuw volgens een dagelijks schema.
• Dependabot opent wekelijks pull requests voor verouderde Ruby-gems en GitHub Actions, gegroepeerd per minor/patch-update.

Componenten die upstream end-of-life bereiken, worden vervangen of bijgewerkt voordat hun ondersteuningsvenster sluit.

Infrastructuur #

• Alle primaire gegevensverwerking vindt plaats binnen de Europese Unie.
• Er worden geen creditcardnummers of betaalgegevens opgeslagen op de servers van EthicsPortal. Alle betaalgegevens worden afgehandeld door Stripe.
• Mailjet wordt gebruikt voor transactionele e-mail (meldingen aan behandelaars, niet gericht aan klokkenluiders). Mailjet is gevestigd in Frankrijk en verwerkt alle gegevens binnen de EU.
• De marketingwebsite wordt geleverd via Cloudflare (CDN, Verenigde Staten); de meld- en behandelportalen niet. Zie de pagina sub-verwerkers voor de volledige lijst en de waarborgen voor doorgifte.

Back-ups en herstel #

EthicsPortal exploiteert twee complementaire back-uplagen, beide bewaard binnen de EU:

Hersteldoelstellingen. De recovery point objective (RPO) is 24 uur. De recovery time objective (RTO) is 4 uur. Deze doelstellingen verschijnen ook in de serviceniveau-overeenkomst .

Hersteltests. Een herstelproef draait elke maand automatisch via een CI-workflow die de laatste dump terugzet in een wegwerpomgeving, en op aanvraag via bin/backup-restore-test. De versheid van de back-ups wordt continu bewaakt (waarschuwing als de meest recente dump ouder is dan 36 uur).

Versleuteling. Databasedumps worden in rust versleuteld door Hetzner Object Storage; velden op applicatieniveau die onder Rails ActiveRecord Encryption zijn versleuteld, blijven versleuteld in de dump.

Operationele beoordeling #

Sommige operationele materialen worden tijdens de inkoopbeoordeling gedeeld in plaats van volledig op het open web te worden gepubliceerd, omdat ze infrastructuur- en responsdetails bevatten die zich beter lenen voor gecontroleerde openbaarmaking.

Onderwerpen die op verzoek tijdens de inkoop beschikbaar zijn:

• Samenvatting van geprivilegieerde productietoegang
• Workflow voor incidentrespons en escalatiecontacten
• Bedrijfscontinuïteit en reacties op uitdiensttreding/export van klanten

Responsible disclosure #

Als u een beveiligingskwetsbaarheid in EthicsPortal ontdekt, meld deze dan via security@ethicsportal.eu . Wij vragen u om:

1. De kwetsbaarheid niet openbaar te maken voordat wij de kans hebben gehad deze aan te pakken.
2. Voldoende detail te verstrekken zodat wij het probleem kunnen reproduceren en verhelpen.
3. Geen gegevens van andere klanten te benaderen of te wijzigen.

Wij bevestigen uw melding binnen 2 werkdagen en streven ernaar bevestigde kwetsbaarheden voortvarend te verhelpen.

Laatst bijgewerkt: 18 juni 2026