Het belangrijkste over de beveiliging van Raisetalk
- Geen enkele openstaande kwetsbaarheid in de volledige scope van Raisetalk op 19 augustus 2026: applicatiecode, afhankelijkheden, containerimages, cloudconfiguratie, virtuele machines en het publiek blootgestelde oppervlak. Dat is geen toestand die we één keer bereiken, het is een toestand die we vasthouden.
- Zes oppervlakken worden continu geanalyseerd, en twee bouwstenen beschermen de uitvoering: een applicatiefirewall die in de API is ingebouwd, in blokkeermodus, en de controle van de beveiligingsstatus van de werkstations.
- Geen enkele alert wordt door een machine gesloten. Elke groep findings wordt een ticket: grondoorzaak, controle of de kwetsbaarheid in onze code werkelijk bereikbaar is, correctie, controle na de deployment. Een mens trekt de conclusie, en het spoor blijft bewaard.
- De resultaten zijn met bewijsstukken controleerbaar, en op twee niveaus: de pagina Beveiliging en compliance toont de details van de controles waaraan is voldaan, criterium per criterium, elke dag automatisch gemeten; het volledige auditrapport vraagt u aan via de badge in de footer van deze site. De gedetailleerde rapporten per normenkader (dertien in totaal: ISO 27001, SOC 2, NIS2, DORA, AVG, PCI DSS, OWASP, NIST 800-53, CIS v8, HIPAA, HITRUST, ENS, UK Cyber Essentials) worden op aanvraag verstrekt.
- Deze scores zijn geen certificeringen, en we zullen ze nooit zo voorstellen. Ze meten technische controles waaraan is voldaan, geen managementsysteem dat door een geaccrediteerde instelling is gevalideerd.
- Certificering en penetratietest zijn een aanvulling, en ze komen daarna. Een jaarlijkse audit zegt niets over de kwetsbaarheid die vanochtend is gepubliceerd in een transitieve afhankelijkheid.
Een basis die gisteren gezond was, is dat vandaag niet meer
Software gaat niet achteruit omdat u eraan sleutelt. Ze gaat achteruit omdat de wereld eromheen beweegt. U hebt al drie weken geen regel code gewijzigd, en toch is uw product vanochtend misschien kwetsbaar: er is net een CVE gepubliceerd voor een transitieve afhankelijkheid die u nooit bewust hebt gekozen, de basisimage van uw container bevat een systeembibliotheek waarvan de ondersteuning net is beëindigd, een binary van een leverancier bevat een bevroren versie van een externe bibliotheek, een cloudinstelling die een jaar geleden nog aanvaardbaar was, is inmiddels een gedocumenteerde slechte praktijk.
Er worden vandaag meer dan honderd kwetsbaarheden per dag gepubliceerd, alle leveranciers samen. In dat tempo is de relevante vraag om een leverancier te beoordelen niet “bent u gecertificeerd?”. De vraag is: wat gebeurt er bij u tussen het moment waarop een kwetsbaarheid wordt gepubliceerd en het moment waarop ze is verholpen? Hoe lang duurt het, via welk mechanisme, met welk bewijs, en wie beslist dat ze verholpen is.
Die vraag gaat ons bijzonder aan. Raisetalk verwerkt gespreksopnames, transcripties en persoonsgegevens van eindklanten die nog nooit van ons hebben gehoord: ze hebben gewoon hun bank, hun verzekeraar of hun energieleverancier gebeld. Het vertrouwen dat men ons geeft, is gedelegeerd vertrouwen, en dat soort vertrouwen moet worden aangetoond in plaats van alleen verklaard.
Dit artikel beschrijft dus het mechanisme, niet de intentie. Wat we meten, hoe vaak, wat er gebeurt wanneer er een alert binnenkomt, wat we publiceren, en tot slot hoe deze aanpak zich verhoudt tot de twee andere klassieke antwoorden op de markt: de certificering en de penetratietest.
Wat we permanent analyseren
We gebruiken Aikido Security als platform voor analyse en bescherming. Die keuze heeft één eenvoudige reden: de dekking. Veel tools doen één ding heel goed, zoals statische codeanalyse of de controle van de cloudconfiguratie. Het probleem is dat een aanvaller zijn toegangsweg niet kiest op basis van hoe uw tools zijn ingedeeld. Een API-sleutel in een configuratiebestand, een CVE in een systeempakket van een containerimage en een te ruime IAM-rol op een serviceaccount zijn vanuit zijn standpunt volkomen gelijkwaardig.
Daarom worden zes oppervlakken continu gevolgd.
| Geanalyseerd oppervlak | Soort analyse | Wat dat concreet opvangt |
|---|---|---|
| Coderepository's | Statische analyse (SAST) Softwaresamenstelling (SCA) Detectie van secrets Infrastructure as code Licenties | Een mogelijke injectie op een route, een kwetsbare of verlaten afhankelijkheid, inloggegevens die per ongeluk zijn gecommit, een kwaadaardige afhankelijkheid die is gepubliceerd onder een naam die lijkt op die van een legitiem pakket |
| Containerimages | Systeempakketten Ingebouwde binaries Versies zonder ondersteuning | Een CVE in de interpreter of in een bibliotheek van de basisimage, een afhankelijkheid die bij het compileren is vastgezet in een binary van een derde |
| Cloudconfiguratie | Beveiligingsstatus van het project en zijn resources (CSPM) | Een serviceaccount met te veel rechten, een resource die zonder noodzaak is blootgesteld, versleuteling of logging die niet is ingeschakeld, een ontbrekende bescherming tegen verwijdering |
| Virtuele machines | Geïnstalleerde pakketten Hardening Opstartketen | Een systeempatch die niet is toegepast, een uitgeschakelde secure boot, een te ruime beheerderstoegang |
| Domeinen en publiek oppervlak | Open poorten TLS Security headers DNS-records | Een dienst die antwoordt terwijl dat niet zou mogen, een te ruim TLS-beleid, een ontbrekende security header, een e-mailconfiguratie die misbruikt kan worden voor spoofing |
| Geauthenticeerde API | Dynamische verkenning van de routes achter de login | Wat geen enkele oppervlaktescan ziet: het werkelijke gedrag van de routes die een geldig token vereisen |
Dat laatste punt verdient een toelichting, omdat het zelden wordt gedaan. Een scanner die bij de inlogpagina stopt, analyseert alleen de etalage. Daarom hebben we de scanner geauthenticeerde toegang tot de API gegeven, zodat hij ook verkent wat achter de authenticatie ligt, daar waar de routes zitten die werkelijk met de gegevens werken. Dat is minder comfortabel, omdat het automatisch meer findings oplevert. Juist daarom is het nuttig.
Wat beschermt terwijl de code draait
Analyseren is vinden wat misbruikt zou kunnen worden. Beschermen is stoppen wat op dat moment wordt misbruikt. Het een vervangt het ander niet, en we gebruiken twee afzonderlijke bouwstenen voor de tweede helft van het werk.
Een applicatiefirewall die in de API is ingebouwd. Zen draait niet vóór de applicatie zoals een klassieke WAF aan de voorkant: hij draait in het applicatieproces, waardoor hij toegang heeft tot de context die de voorkant niet heeft. Hij ziet niet alleen een verdachte tekenreeks in een HTTP-verzoek, hij ziet de SQL-query die werkelijk wordt opgebouwd, het commando dat werkelijk wordt uitgevoerd, het bestandspad dat werkelijk wordt geopend. Zo kan hij een tekenreeks die op een injectie lijkt, onderscheiden van een tekenreeks die er werkelijk een veroorzaakt. Bij ons draait hij sinds het najaar van 2025 in blokkeermodus, en niet alleen in observatiemodus: een gedetecteerde poging wordt onderbroken, niet alleen gelogd.
Die beslissing heeft een prijs, en dat moet gezegd: een firewall in blokkeermodus kan in theorie een legitiem verzoek onderbreken. Dat nemen we bewust voor lief, en daarom behandelen we versie-upgrades van deze bouwsteen ook met dezelfde voorzichtigheid als een functionele wijziging: voordat we ze uitrollen, controleren we wat ze veranderen aan de blokkeerbeslissingen.
De controle van de beveiligingsstatus van de werkstations. De tweede bouwsteen betreft onze eigen machines, die van waaruit we ontwikkelen en de productie beheren. Schijfversleuteling, sessievergrendeling, systeemupdates, actieve antivirus: deze punten worden continu op elk werkstation gecontroleerd. Dit is geen compliance voor de sier. Een onberispelijk platform dat wordt beheerd vanaf een onversleutelde laptop die openstaat in de trein, blijft een kwetsbaar platform, en de aanvaller die het op een softwareleverancier heeft gemunt, kiest zelden het product als eerste doelwit.
Wat er gebeurt wanneer er een alert binnenkomt
Hier zit het verschil tussen een aangekocht analyseplatform en een echte beveiligingspraktijk. Een tool die tweehonderd alerts meldt, produceert tweehonderd alerts. Hij produceert geen beveiliging. Beveiliging begint bij de volgende stap, de stap die niemand in een demo laat zien.
Ons proces is op papier gezet en wordt elke keer gevolgd, in dezelfde volgorde.
1. Groeperen per grondoorzaak. Een groep van zesendertig findings is bijna nooit zesendertig problemen. Vaak gaat het om één enkele regel in een lockfile van afhankelijkheden, die doorwerkt in drie containerimages en twee repository's. De eerste stap bestaat er dus in de ene grondoorzaak te scheiden van de getroffen oppervlakken, en te bepalen hoeveel afzonderlijke correcties er werkelijk nodig zijn. Zo verwart u het aantal alerts niet met de hoeveelheid werk, en behandelt u niet met spoed zesendertig symptomen in plaats van één probleem.
2. Een ticket openen, met een deadline. Voor elke behandelde groep wordt een ticket aangemaakt in de betrokken repository, met de ernst en de deadline voor de afhandeling. Niets bestaat alleen in een dashboard: wat geen ticket heeft, heeft geen eigenaar, en wat geen deadline heeft, heeft geen prioriteit.
3. Controle in onze eigen code. Dit is de stap die de scanner niet voor ons kan doen. Een CVE die voor een bibliotheek is aangekondigd, zegt niet of de kwetsbare code vanuit onze code bereikbaar is. We lezen de betrokken bestanden, bevestigen de werkelijk geïnstalleerde versie, de werkelijk gedeclareerde versiebeperking en de werkelijke aanroepers. Een SSRF-kwetsbaarheid in een functie die we nooit aanroepen, is niet even dringend als een deserialisatie die vanaf een publieke route bereikbaar is. Deze controle leidt soms tot de omgekeerde conclusie van de alert: een vals positief, dode code, of een correctie die al is doorgevoerd. In dat geval wordt de beslissing met de reden vastgelegd, en wordt het ticket nooit gewoon zonder gevolg gesloten.
4. De correctie, en alles wat daarbij hoort. Een herstelplan stopt niet bij een versiewijziging. Het omvat uitdrukkelijk de stappen buiten de code: de image opnieuw bouwen, een secret roteren, de geschiedenis herschrijven als er inloggegevens zijn blootgesteld, de betrokken dienst herstarten. Een secret dat uit de broncode is verwijderd, maar bij de leverancier nog geldig is, is niet verholpen.
5. Controle na de deployment, en daarna sluiting door een mens. We controleren of de correctie werkelijk aanwezig is in wat draait, en niet alleen in wat is gecommit. Een image die opnieuw is gebouwd maar niet uitgerold, verkeer dat na een rollback op de oude revisie vastgepind is gebleven: zulke afwijkingen komen vaak voor, en ze maken van een correctie een schijncorrectie. Pas daarna sluit een mens het ticket.
De regel die het geheel bijeenhoudt: geen automatische sluiting. Niet door de scanner, en niet door een tool die zou beslissen dat een finding aanvaardbaar is. Een alert die niet wordt verholpen, is een alert waarvan we documenteren waarom niet, met een naam en een datum. Dat is omslachtig, en precies dat maakt het verschil tussen een groen dashboard en een veilig product.
De basis van de hardening, in detail
Een detectiemechanisme is maar zo goed als de basis waarop het wordt toegepast. Hier volgen, zonder volledig te willen zijn, de keuzes die vandaag de infrastructuur van Raisetalk bepalen. Het zijn geen loze verklaringen: elk ervan wordt continu gecontroleerd door de hierboven beschreven analyses, en een afwijking wordt een alert.
- Geen enkele container draait met beheerdersrechten. Zowel de hoofdprocessen als de werkprocessen draaien onder een account zonder privileges, en de diensten luisteren op niet-geprivilegieerde poorten.
- De images bevatten geen enkele binary met SUID-bit, en een controle laat het bouwen van de image mislukken als er toch een opduikt. Een installatiestap die later wordt toegevoegd, zou er een kunnen herintroduceren zonder dat iets het signaleert: hardening die zichzelf niet bewaakt, gaat bij de volgende update altijd verloren.
- Secure boot is ingeschakeld op de virtuele machines, zodat de opstartketen wordt gecontroleerd voordat het systeem laadt.
- Beheerderstoegang verloopt via de identiteit, nooit via een gedeelde sleutel. Authenticatie via de cloudidentiteit, SSH-sleutels op projectniveau geblokkeerd, toegang tot de machines via een geauthenticeerde tunnel in plaats van via een blootgestelde beheerpoort.
- Elke dienst draait met een eigen account, beperkt tot de rechten die hij werkelijk nodig heeft, en nooit met een standaardaccount: die hebben per definitie veel te ruime rollen.
- De database dwingt zelf versleutelde verbindingen af, in plaats van dat over te laten aan de goede wil van de client die verbinding maakt.
- De publieke site past een strikte Content Security Policy toe, tot en met een verbod op inline styles: een echte beperking voor wie de componenten schrijft, en een injectieoppervlak minder.
Geen van deze punten is op zichzelf spectaculair. Het echte werk zit in hun combinatie, en vooral in het feit dat ze permanent worden gecontroleerd in plaats van één keer bij de installatie.
Waar we staan op 19 augustus 2026
Op de publicatiedatum van dit artikel toont het dashboard geen enkele openstaande alert in de volledige scope. De compliancerapporten die het platform genereert, geven de volgende resultaten.
| Normenkader | Wat het dekt | Score |
|---|---|---|
| ISO 27001 | Informatiebeveiliging, internationaal normenkader | 100% |
| SOC 2 | Controles op dienstverlening, referentie voor Angelsaksische kopers | 99% |
| OWASP | De meest voorkomende applicatierisico's | 100% |
| CIS v8 | Prioritaire beveiligingscontroles, technische basis | 100% |
| NIS2 | Europese richtlijn over cyberweerbaarheid | 100% |
| NIST 800-53 | Beveiligingscontroles van de Amerikaanse federale overheid | 100% |
| PCI DSS | Beveiliging van betaalgegevens | 100% |
| HIPAA | Gezondheidsgegevens, Amerikaans kader | 100% |
| DORA | Operationele weerbaarheid van de Europese financiële sector | 99% |
| HITRUST niveau 3 | Kader voor beveiliging en compliance, zorgsector | 100% |
| ENS | Spaans nationaal beveiligingsschema | 100% |
| AVG | Bescherming van persoonsgegevens | 100% |
| UK Cyber Essentials | Britse basis voor cyberhygiëne | 99% |
Het platform plaatst Raisetalk bovendien bij de 5% best beveiligde applicaties die het volgt. Dat is een relatieve vergelijking van een derde partij, en we vermelden ze ook als zodanig.
Wat deze cijfers zeggen, en wat niet. Ze meten welk deel van de technische controles die het platform volgt, is voldaan, binnen de scope die het observeert. Ze meten niet onze interne procedures, niet onze governance, niet de training van onze teams en niet de fysieke beveiliging van onze kantoren: met andere woorden een deel van wat een ISO-auditor als eerste bekijkt.
Een score van 100% op het normenkader ISO 27001 is dus geen ISO 27001-certificering, en we zullen het nooit anders schrijven. De twee verwarren zou precies het soort onnauwkeurigheid zijn dat dit artikel wil vermijden.
Transparantie: eerst de openbare pagina, dan het rapport op aanvraag
Een leverancier die beweert dat alles in orde is, vraagt u hem te geloven. Wij laten u liever zelf kijken. Dat gebeurt op twee niveaus.
Het eerste is openbaar, en gedateerd. De pagina Beveiliging en compliance toont de details van de technische controles waaraan is voldaan, criterium per criterium, voor zeven normenkaders: SOC 2, ISO 27001:2022, NIS2, DORA, AVG, PCI DSS en CIS Controls v8 (vijf bij de publicatie van dit artikel: DORA en PCI DSS kwamen er op 26 augustus 2026 bij, toen hun gegevens via de API beschikbaar werden). Ze wordt niet met de hand geschreven. Ze wordt elke dag opnieuw gegenereerd vanuit dezelfde bron die de cijfers in dit artikel levert, en ze toont duidelijk de datum van de laatste synchronisatie. Een compliancepagina die al zes maanden niet is veranderd, is geen compliancepagina, het is een screenshot.
Het tweede blijft op aanvraag. De badge in de footer van alle pagina's van deze site opent een formulier om toegang te vragen tot het rapport van de beveiligingsaudit. Het rapport wordt gegenereerd op basis van de werkelijke staat van het platform op het moment van de aanvraag, niet op basis van een statisch document dat eens en voor altijd is opgesteld: het is dezelfde bron die de cijfers hierboven levert.
Waarom blijft het volledige rapport op aanvraag, terwijl de details van de controles openbaar zijn? Omdat het verder gaat dan de pagina: de geschiedenis van de analyses, een momentopname van de openstaande punten, de dekking van de zes normenkaders die geen API hebben. Een beveiligingsrapport beschrijft een technische scope, en weten aan wie u het verstrekt, hoort bij de elementaire hygiëne. Het formulier is kort en de aanvraag wordt snel behandeld.
Voor ons is het ook een eenzijdige verbintenis. Een badge publiceren die toegang geeft tot een onafhankelijke meting van onze beveiligingsstatus, betekent vooraf aanvaarden dat een slechte maand zichtbaar wordt. Precies dat maakt de informatie de rest van de tijd nuttig.
De andere benaderingen, en waarom ze daarna komen
Wanneer een koper naar beveiliging vraagt, overheersen op de markt twee antwoorden. Beide zijn legitiem, en beide zijn op zichzelf onvoldoende. Ons standpunt laat zich in één woord samenvatten: de volgorde.
De ISO 27001-certificering
ISO/IEC 27001 certificeert een managementsysteem voor informatiebeveiliging. Een geaccrediteerde instelling controleert of u uw risico's hebt geïdentificeerd, maatregelen hebt vastgelegd en uw procedures hebt gedocumenteerd, en of u het geheel ook echt in de praktijk brengt. Het certificaat is drie jaar geldig, met jaarlijkse controle-audits. Het is serieus werk, dat een organisatie duurzaam structureert, en het is een sterk signaal voor een koper.
De beperkingen vloeien voort uit de aard van de certificering zelf, en ze zijn allerminst polemisch. De audit werkt met steekproeven, op een bepaalde datum. Hij valideert een managementsysteem, niet de technische staat van uw product op het moment dat uw prospect het certificaat leest. Niets in een certificaat dat in maart is behaald, vertelt u iets over de kritieke kwetsbaarheid die in oktober is gepubliceerd in een afhankelijkheid van de applicatie. Het certificaat bevestigt dat de organisatie over een proces beschikt om die te behandelen, en dat is iets heel anders dan bevestigen dat ze is behandeld.
Het is een foto, genomen door een professional, met een uitstekende camera. Het blijft een foto.
De penetratietest (pentest)
De penetratietest levert wat geen enkele scanner kan produceren: de intelligentie van een menselijke aanvaller. Drie zwakke plekken die elk op zich klein zijn aan elkaar koppelen om een toegang te krijgen die niet zou mogen bestaan, bedrijfslogica misbruiken die perfect overeenstemt met de code, bij het object van een andere klant komen door een id te manipuleren: dat spoort u niet op met patroonanalyse.
De beperking ervan is echter budgettair, en ze is structureel. U koopt een aantal dagen, dus u bakent een scope af. Alles buiten die scope wordt niet getest, en het rapport vermeldt dat vaak niet, of alleen in de kleine lettertjes... Het beschrijft wat is gevonden waar er is gezocht. Net als de certificering geldt de test voor één datum, één versie en vooral een beperkte scope. De deployment van de maand daarna maakt een deel ervan achterhaald.
De drie benaderingen naast elkaar
| Continue controle | ISO 27001-certificering | Penetratietest | |
|---|---|---|---|
| Wat wordt beoordeeld | De werkelijke technische staat van de volledige scope | Het managementsysteem voor beveiliging | Een vooraf afgebakende applicatiescope |
| Frequentie | Permanent | Initiële audit, daarna jaarlijkse controle | Eenmalig, op bestelling |
| Dekking | Volledig voor de gekoppelde oppervlakken | Via steekproeven | Beperkt door het toegekende budget |
| Geldigheid in de tijd | Altijd actueel | Eén datum, een cyclus van drie jaar | Eén datum, één versie |
| Wat het best wordt opgespoord | Bekende kwetsbaarheden, configuratieafwijkingen, blootgestelde secrets | Tekortkomingen in organisatie, procedures en governance | Fouten in bedrijfslogica, ketens van zwakke plekken, omzeilingen |
| Wat het niet ziet | Misbruikte bedrijfslogica | De technische staat van het product op een bepaald moment | Alles buiten de scope |
| Geleverd bewijs | Een actueel rapport, op aanvraag | Een certificaat | Een gedateerd rapport |
Deze drie kolommen vervangen elkaar niet. Ze vullen elkaar aan, in deze volgorde. U laten certificeren zonder continue controle betekent netjes een proces documenteren dat u niet kunt uitvoeren. Een penetratietest bestellen op een scope waar nog bekende kwetsbare afhankelijkheden rondslingeren, betekent tegen het tarief van een expert betalen voor wat een scanner gratis in één nacht vindt. En hem bestellen op een smalle scope, juist gekozen omdat u die al beheerst, betekent goed nieuws kopen in plaats van informatie: dat nieuws ligt vast op het moment dat de scope wordt opgesteld, niet op het moment van de test. Een nuttige penetratietest is er een waarvan de scope is gekozen om zijn moeilijkheid, en waarvan de omvang samen met de conclusie wordt meegedeeld.
Onze volgorde is dus deze: eerst de permanente meting en de systematische correctie, omdat dat vandaag de gegevens van onze klanten echt beschermt. Een ISO 27001-certificering wordt overwogen voor later, en een externe penetratietest staat op onze roadmap: ze zullen bestaande fundamenten valideren en aanvullen, niet vervangen en er ook niet de plaats van innemen.
Wat continue controle niet vervangt
Het zou oneerlijk zijn af te sluiten zonder te zeggen waar de grenzen liggen van wat we hier beschrijven.
Een analyseplatform kent uw vakgebied niet. Het weet dat een SQL-query via concatenatie wordt opgebouwd. Het weet niet dat een gebruiker van het ene team nooit de beoordelingen van een ander team mag zien. Die regels zijn eigen aan ons product, en geen enkele kwetsbaarhedendatabase bevat ze. Daarom onderhouden we intern ons eigen dreigingsmodel: de deploymenteenheden, de toegangsoppervlakken, de vertrouwensgrenzen en de bedrijfsregels die nooit mogen bezwijken. Het wordt nagelezen en bijgewerkt zoals code, en het dient als kaart wanneer we zoeken naar wat geen enkele tool in onze plaats zal zoeken.
Een compliancescore is geen garantie. Hij geeft aan dat er binnen de geobserveerde scope geen bekend probleem meer is. Dat is waardevol, en het zegt niets over de kwetsbaarheden die nog niet openbaar zijn. Niemand kan het tegendeel beloven, en wie dat wel doet, moet u wantrouwen.
Beveiliging blijft een keten. Ze omvat onze subverwerkers, onze leveranciers van AI-modellen, de hostingpartij en het gebruik dat uw eigen teams van het platform maken. Daarom horen de toegangscontrole op basis van rollen en bereik en de pseudonimisering van persoonsgegevens bij hetzelfde onderwerp als de kwetsbaarheden: ze bepalen wat beschermd blijft op de dag dat er elders iets bezwijkt.
Tot slot
We hadden een kort artikel kunnen schrijven: “nul kwetsbaarheden, dertien normenkaders, top 5%”. Het zou juist zijn geweest, en het zou niets hebben bewezen. De cijfers die in beveiliging tellen, zijn niet de cijfers die u toont, maar de cijfers die u kunt uitleggen: waar ze vandaan komen, wat ze dekken, wat ze buiten beschouwing laten, en wat er gebeurt op de dag dat ze verslechteren.
De beveiliging van software is geen toestand, het is een ritme. U bewijst ze niet met een jaarlijks document, maar met het vermogen om week na week te verwerken wat de meting aan het licht brengt, ook wanneer dat ongemakkelijk is, ook wanneer u daardoor een machine opnieuw moet opbouwen of een component moet aanpassen die prima werkte.
En omdat de bewering van een leverancier nooit opweegt tegen de controle door een koper: de details van de controles staan op de pagina Beveiliging en compliance, en het volledige rapport onderaan deze pagina.
Controleer het zelf
- Bekijk de details van de controles, normenkader per normenkader: de pagina Beveiliging en compliance, elke dag opnieuw gegenereerd
- Vraag het rapport van de beveiligingsaudit aan: naar het formulier, of klik op de badge in de footer.
- Onze antwoorden over gegevens en de AVG: de veelgestelde vragen
- Stel ons een concrete vraag: www.raisetalk.com/nl/contact
De cijfers in dit artikel geven de toestand weer die op 19 augustus 2026 is vastgesteld. Ze veranderen: daar zijn ze juist voor. Een beveiligingsdashboard dat al zes maanden niet is veranderd, is geen teken van een stabiel product, het is het teken van een meting die stilstaat. De goede vraag aan een leverancier, ook aan ons, is dus niet “is uw score vandaag goed?”. Het is “wat gebeurt er bij u op de dag dat hij dat niet meer is?”.
