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-11-04.

Gegevensversleuteling #

De hieronder vermelde gevoelige databasevelden worden in rust versleuteld met Rails ActiveRecord Encryption met niet-deterministische versleuteling (elke versleuteling produceert een unieke cijfertekst, wat patroonanalyse voorkomt). Veldversleuteling omvat geen volledige databasedumps of bijlagen; die worden afzonderlijk versleuteld, zoals beschreven onder bijlagen en back-ups.

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.

Bijlagen #

Bestanden die zijn bijgevoegd bij meldingen, berichten en interne notities, spraakopnamen en exports van zaakgegevens worden in rust versleuteld in Hetzner Object Storage met AES-256, onder een afzonderlijke willekeurige sleutel voor elk bestand (serverzijdige versleuteling met door de klant verstrekte sleutels). De sleutel wordt met elk opslagverzoek meegestuurd en Hetzner weigert elke leesactie zonder deze sleutel. EthicsPortal bewaart de sleutel in de database onder de hierboven beschreven ActiveRecord Encryption, zodat de inloggegevens voor de opslag alleen geen bestand kunnen lezen: daarvoor zijn ook de database en de versleutelingssleutels van de applicatie nodig. Bestanden bereiken geautoriseerde gebruikers via streaming door de applicatie, nooit via een directe opslaglink.

Bestanden die vóór 6 oktober 2026 zijn geüpload, zijn op die datum opnieuw versleuteld, en hun onversleutelde kopieën, inclusief bewaarde eerdere versies, zijn verwijderd. Bestanden die geen meldingsgegevens zijn, zoals profielfoto’s en deelafbeeldingen van organisaties, worden niet op deze manier versleuteld. Niets hiervan beschermt tegen een compromittering van de applicatieserver, die de inloggegevens voor de opslag, de database en de sleutels samen bevat.

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

Anonimiteit en privacy #

IP-adressen #

EthicsPortal legt het IP-adres van een melder niet vast bij meldingen, berichten of auditvermeldingen, en de applicatielogs voor het meldkanaal bevatten geen IP-adressen.

Snelheidsbeperking op het meldkanaal (indiening van meldingen, opzoeken van zaken, berichten) is gebaseerd op een ingekorte, gesleutelde SHA-256-hash van het verzoek-IP. De hash is pseudoniem, niet anoniem: hij kan niet als adres worden teruggelezen, maar wie over het applicatiegeheim beschikt, zou kandidaat-adressen ertegen kunnen toetsen. Hij wordt alleen gebruikt voor het venster van de snelheidsbeperking (maximaal 10 minuten); een achtergrondtaak verwijdert hem binnen 5 minuten na afloop van het venster uit de cache.

De TLS-proxy vóór de applicatie houdt een eigen verzoeklog bij: IP-adres, verzoekpad, user agent en antwoordstatus. Het pad van de pagina waarop een melder de melding bekijkt, bevat het zaak-ID, dus een regel voor die pagina kan aan de melding worden gekoppeld. Ze worden bewaard in één logbestand van 10 MB dat wordt overschreven zodra het vol is, momenteel na ongeveer twee dagen; de 7-daagse serversnapshots die onder back-ups worden beschreven, kunnen een kopie bevatten.

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.

In een pdf blijven de namen bij opmerkingen en de metadata van ingesloten foto’s, zoals GPS-positie en serienummer van de camera, behouden. Een melder die deze wil laten verwijderen, moet foto’s als afzonderlijke afbeeldingsbestanden uploaden en opmerkingen verwijderen voordat een pdf wordt geüpload.

Virusscanning #

Bestanden die zijn bijgevoegd bij meldingen, berichten en interne notities, 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.

Meldingen per e-mail #

Elk meldkanaal heeft een eigen e-mailadres op report.ethicsportal.eu. Een e-mail naar dat adres wordt een zaak in dat meldkanaal, net als een melding via het online meldformulier. Meldingen per e-mail staan standaard aan. Een organisatie kan ze uitschakelen in de instellingen van het meldkanaal; het adres weigert dan binnen een minuut nieuwe e-mail.

• Eigen mailserver. Mail voor deze adressen wordt ontvangen door de eigen mailserver van EthicsPortal op dezelfde infrastructuur in Duitsland, niet door een externe e-mailprovider. De server accepteert alleen mail voor adressen van meldkanalen, weigert elk ander adres en stuurt niets door.
• Transportversleuteling. De server biedt TLS 1.2 of hoger aan met een certificaat van Let’s Encrypt. TLS is opportunistisch: een verzendende server die het niet ondersteunt, levert onversleuteld af.
• Adres van de afzender verborgen voor behandelaars. Het adres van de afzender wordt versleuteld opgeslagen en wordt nooit aan behandelaars getoond, niet in de zaak, de pdf of exports. EthicsPortal gebruikt het alleen om de melder de ontvangstbevestiging en berichten over nieuwe berichten te sturen.
• Toegang zonder e-mail. De ontvangstbevestiging bevat het zaak-ID en een eenmalig wachtwoord voor de beveiligde inbox, dat wordt vervangen wanneer de melder voor het eerst inlogt. Vragen en antwoorden blijven in de inbox, niet in e-mail. Als het eigen domein van de afzender het adres in zijn DMARC-beleid afwijst, wordt de melding bewaard, maar wordt er geen wachtwoord verstuurd. Na 10 meldingen per e-mail aan één organisatie, of 50 binnen heel EthicsPortal, binnen 24 uur worden volgende meldingen bewaard, maar gaat er geen e-mail uit: geen ontvangstbevestiging naar de melder en geen e-mailbericht naar de beheerders, die de zaak wel in de applicatie zien.
• Bijlagen. Bestanden krijgen dezelfde verwijdering van metadata en dezelfde virusscan als uploads via het formulier. Bestanden die niet kunnen worden geaccepteerd (een ander type, te groot of niet op te schonen), worden weggelaten, en de melder krijgt te horen hoeveel.
• Kopieën. Een bericht wacht in de wachtrij van de mailserver op dezelfde server alleen tot de applicatie het overneemt. De applicatie bewaart de oorspronkelijke e-mail versleuteld tot de zaak is opgeslagen en verwijdert hem dan. De logs van de mailserver registreren adressen van meldkanalen, nooit het adres van de afzender.
• Controle van de afzender. SPF, DKIM en DMARC worden gecontroleerd op de infrastructuur van EthicsPortal. Er worden geen berichtgegevens naar een externe spam- of reputatiedienst verzonden.

E-mail is niet anoniem: de e-mailprovider van de melder, en de mailsystemen van de organisatie als de melder vanaf een werkaccount schrijft, kunnen kopieën en gegevens van het bericht bewaren. De ontvangstbevestiging vermeldt dit en linkt naar het online meldformulier voor melders die anoniem willen blijven.

E-mail voor updates #

Het online meldformulier heeft een optioneel e-mailveld voor updates. Het adres ontvangt de ontvangstbevestiging en een bericht wanneer een behandelaar schrijft, nooit de inhoud van de melding. Het wordt versleuteld opgeslagen en, net als het adres van de afzender van een melding per e-mail, op geen enkele pagina voor behandelaars, in geen pdf en in geen export getoond. Het blijft beschikbaar wanneer de melder anoniem meldt. Alleen een melder die anoniem melden uitzet en “mijn e-mailadres ook aan de zaakbehandelaars tonen” aanvinkt, maakt er een contactadres van dat behandelaars zien.

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 Plausible Analytics alleen op de marketingwebsite, geleverd via ons eigen domein. Het plaatst geen cookies en slaat geen IP-adressen op. Cloudflare, dat de marketingwebsite levert, verwerkt verzoekmetadata, waaronder IP-adressen, zoals beschreven in de Privacyverklaring. Het meldkanaal 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 openen hun melding met een zaak-ID (WB-XXXX-XXXX) en een wachtwoord dat het systeem genereert wanneer de melding wordt ingediend.
• 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.

Inloggen door melders #

Melders loggen in met hun zaak-ID en een wachtwoord. Het zaak-ID identificeert de zaak en is niet geheim. Het wachtwoord bestaat uit 16 willekeurige cijfers en wordt door het systeem gegenereerd wanneer de melding wordt ingediend; de melder kiest het niet. Het wordt uitsluitend opgeslagen als bcrypt-digest, dus niemand kan het herstellen, en EthicsPortal heeft geen functie waarmee de melder, de zaakbehandelaar of de exploitant het opnieuw kan instellen. Een melder die het wachtwoord kwijtraakt, dient een nieuwe melding in en vermeldt daarin het zaak-ID. Meldingen die vóór 18 oktober 2026 zijn ingediend, behouden het 6-cijferige wachtwoord dat de melder destijds koos, en dat blijft werken. 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.

Direct na het indienen toont een ontvangstbewijs het adres van de veilige inbox, het zaak-ID en het wachtwoord. Het blijft alleen in die browser beschikbaar zolang de zaak ontgrendeld is, en verdwijnt wanneer de inbox na 30 minuten zonder activiteit wordt vergrendeld of wanneer de melder afsluit. Op de inlogpagina is het wachtwoordveld een zichtbaar tekstveld met automatisch aanvullen uitgeschakeld, in plaats van een gemaskeerd wachtwoordveld, zodat browsers niet aanbieden het wachtwoord op te slaan. Een door het werk beheerde browser zou het anders kunnen synchroniseren met het account van de werkgever. Plakken werkt, en spaties worden genegeerd.

Wanneer medewerkers een melding vastleggen die telefonisch, tijdens een persoonlijk gesprek, per brief of per e-mail is ontvangen, en de melder de zaak online wil volgen, genereert het systeem een eenmalig wachtwoord dat de behandelaar aan de melder doorgeeft. Het werkt één keer: bij de eerste keer inloggen van de melder wordt het op de server vervangen door een nieuw wachtwoord dat alleen de melder ziet.

De toegang van de melder eindigt wanneer die op ‘Afsluiten’ klikt, of na 30 minuten zonder activiteit. Ongeveer twee minuten voor de vergrendeling biedt een waarschuwing aan om de inbox open te houden; reageert niemand, dan verdwijnt de zaak van het scherm. De toegang staat in een versleutelde cookie in de browser van de melder; de server bewaart geen sessie van de melder.

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 eigenaar van de organisatie, de laatste actieve beheerder en de aangewezen compliance officer van het meldkanaal kunnen niet worden gedeactiveerd. Alle deactiverings- en reactiveringsgebeurtenissen worden weggeschreven naar het auditlog met uitsluitend toevoegingen.

Het verwijderen van een lid deactiveert het lidmaatschap in plaats van het te verwijderen, zodat de audit trail en de meldingsgeschiedenis herleidbaar blijven. Een lidmaatschap wordt alleen definitief verwijderd wanneer het eigen account van het lid of de organisatie zelf wordt gewist.

Verwijdering van het account #

Wanneer een lid het eigen account sluit, wordt het e-mailadres vervangen door een niet-routeerbare placeholder en worden profielfoto, tweefactorreferenties, sessies, API-tokens en voorkeuren permanent verwijderd; het account kan zich niet meer authenticeren en niet meer worden gecontacteerd. Als het account nooit binnen een organisatie heeft gehandeld, wordt het record volledig verwijderd. Zo wel, dan blijft de naam van het lid behouden, terwijl de lidmaatschappen worden gedeactiveerd, zodat bewaarde zaaknotities, berichten en auditlogvermeldingen toerekenbaar blijven. De verwerkingsverantwoordelijke bepaalt de bewaartermijn volgens zijn gedocumenteerde instructies en het toepasselijke recht; het recht op gegevenswissing onder de AVG blijft onderworpen aan eventuele toepasselijke uitzonderingen voor wettelijke verplichtingen of rechtsvorderingen.

Een geschoond account kan zich langs geen enkele weg authenticeren: magic link, SSO-assertie of API-token.

Snelheidsbeperking #

Openbare endpoints van het meldkanaal zijn aan snelheidsbeperking onderworpen om misbruik en opsommingsaanvallen te voorkomen:

Snelheidsbeperking gebruikt de hierboven beschreven gesleutelde IP-hash — er wordt daarvoor geen IP-adres opgeslagen. De limiet per zaak-ID gebruikt het zaak-ID zelf als sleutel; dat wordt binnen 15 minuten uit dezelfde cache verwijderd.

Audit en naleving #

Audit trail met uitsluitend toevoegingen #

Gedefinieerde meldings- en accountgebeurtenissen worden gelogd met:

• Tijdstip (UTC)
• Actor (welke gebruiker of welk systeemproces de actie uitvoerde)
• Type actie (bijvoorbeeld melding aangemaakt, status gewijzigd, bericht verzonden, behandelaar toegewezen, melding geëxporteerd of melding verwijderd). Elke inzage van een bepaalde melding door een behandelaar wordt gelogd, ontdubbeld tot één vermelding per behandelaar per melding per 24 uur, en inzagen door de melder bij opvolging worden op dezelfde manier gelogd. Het lezen van andere resources wordt niet gelogd.

Auditlogvermeldingen kennen uitsluitend toevoegingen. Geen enkele gebruiker, ook geen organisatiebeheerder, kan een vermelding bewerken of er selectief één verwijderen: PostgreSQL-triggers weigeren wijziging en truncate op databaseniveau. Vermeldingen verdwijnen alleen via de bewaarcyclus of wanneer de organisatie zelf wordt verwijderd, en bevoorrechte database-interventie blijft een gedocumenteerd restrisico (risicoregister R-08). 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, verwijdert een achtergrondtaak de melding en de bijbehorende gegevens uit productie; back-upkopieën verlopen volgens de afzonderlijke gedocumenteerde levenscyclus.

E-mails aan een melder laten geen registratie achter in de verzendgeschiedenis van EthicsPortal. Na het verwijderen van de melding blijft er dus geen adres van een melder over.

De verwerkingsverantwoordelijke blijft verantwoordelijk voor de keuze van een termijn die voldoet aan de opslagbeperking van de AVG en de toepasselijke nationale regels voor het bewaren van gegevens.

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.

Maatregelen voor de toeleveringsketen beperken wat een gecompromitteerde release van een afhankelijkheid kan bereiken:

• Wachttijd voor nieuwe releases. Nieuwe gem-versies worden pas overgenomen als ze drie dagen openbaar zijn; versie-updates van Dependabot wachten 3, 7 of 14 dagen voor patch-, minor- en major-releases. Gekaapte releases worden doorgaans binnen die termijn ingetrokken.
• Vastgepinde CI-acties. Elke GitHub Actions-stap is vastgepind op een volledige commit-SHA, zodat een verplaatste tag niet kan veranderen wat er wordt uitgevoerd.
• Gecontroleerde downloads. Binaire bestanden die tijdens het bouwen van de containerimage worden opgehaald, worden gecontroleerd tegen een vastgelegde SHA-256-checksum.
• Bewaakte automatische updates. Pull requests van Dependabot worden pas automatisch samengevoegd nadat de volledige testsuite en de statische analyse zijn geslaagd.

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

Infrastructuur #

• De kernopslag van meldingen en zaakgegevens bevindt zich in de Europese Unie. E-mailbezorging en applicatietelemetrie hebben afzonderlijke ketens van downstream-leveranciers; zie de verwerkersovereenkomst.
• Er worden geen creditcardnummers of betaalgegevens opgeslagen op de servers van EthicsPortal. Alle betaalgegevens worden afgehandeld door Stripe.
• Mailjet verstuurt notificaties aan behandelaars en optionele ontvangstbevestigingen en berichten over nieuwe berichten aan melders. Berichten aan melders bevatten het e-mailadres van de ontvanger, het zaak-ID en een link, maar niet het verhaal van de melding. De ontvangstbevestiging van een melding die per e-mail is verstuurd, bevat ook een eenmalig wachtwoord voor de beveiligde inbox, dat wordt vervangen wanneer de melder voor het eerst inlogt. De downstream-ondersteuningsketen van Mailjet kan toegang van buiten de EER omvatten; zie de verwerkersovereenkomst.
• De marketingwebsite wordt geleverd via Cloudflare (CDN, Verenigde Staten); het meldkanaal en het behandelaarsportaal niet. Deze afzonderlijke verwerking van de openbare website en de doorgiftewaarborgen worden beschreven in de Privacyverklaring, niet in de lijst van subverwerkers in de verwerkersovereenkomst met de klant.

Back-ups en herstel #

EthicsPortal exploiteert drie complementaire back-uplagen, alle 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, en op aanvraag, en zet de laatste dump terug in een wegwerpomgeving. De proef ontsleutelt de dump, zet hem terug, vergelijkt elke tabel met de live productieomgeving en start vervolgens de applicatie op de teruggezette database om te bevestigen dat een versleutelde kolom nog steeds ontsleutelt, dat één versleutelde bijlage opent met de sleutel uit de teruggezette dump en dat van elke bijlage die ouder is dan een uur een kopie op de back-uplocatie staat, waarbij één kopie wordt geopend en tegen haar checksum wordt gecontroleerd — rijtellingen alleen kunnen een bruikbare back-up niet onderscheiden van cijfertekst waarvan de sleutel niet meer past. De versheid van de back-ups wordt continu bewaakt (waarschuwing als de meest recente dump ouder is dan 36 uur).

Versleuteling. Volgens Hetzner versleutelt Object Storage objecten standaard niet in rust, dus databasedumps worden versleuteld voordat ze de host verlaten: GnuPG symmetrisch AES-256, met een wachtwoordzin die alleen het backupproces kent en die buiten de machine is gedeponeerd. Velden die op applicatieniveau met Rails ActiveRecord Encryption zijn versleuteld, blijven daarnaast versleuteld binnen elke dump. Bijlagen worden in rust versleuteld met een sleutel per bestand (zie bijlagen). Die sleutels bestaan alleen in de database, dus elke versleutelde dump bevat ze. De bestanden zelf worden niet in de dump gekopieerd. Elk bestand wordt opgeslagen in Neurenberg en, onder dezelfde sleutel, gekopieerd naar een tweede bucket in Falkenstein; beide bewaren eerdere versies 28 dagen.

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.
4. Geen denial-of-service-aanvallen of grootschalige geautomatiseerde scans uit te voeren, geen social engineering op onze medewerkers te proberen en geen meldingen in te dienen via het meldkanaal van een klant.

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

Geen betaald bug bounty-programma. Openbaarmaking wordt niet beloond: wij vergoeden kwetsbaarheidsmeldingen niet en tekenen geen geheimhoudingsovereenkomsten, aanvaarden geen commerciële voorwaarden en voeren geen gesprekken als voorwaarde voor het ontvangen van een melding. Stuur het betrokken systeem, de reproductiestappen en de door u vastgestelde impact naar het bovenstaande adres.

Laatst bijgewerkt: 8 november 2026