Dit document beschrijft de beveiligingsmaatregelen waarmee SupportCore de gegevens van klanten en hun eindklanten beschermt. Het is bedoeld voor wie een leveranciersbeoordeling uitvoert, een verwerkersovereenkomst toetst of eenvoudigweg wil weten waar hij aan toe is. Waar wij iets niet doen, staat dat er ook.

1. Reikwijdte

Dit beleid geldt voor het SupportCore-platform: de webapplicatie, de bijbehorende API's, de chatvoorziening, de koppelingen met systemen van klanten en de infrastructuur waarop dat draait. Het geldt niet voor de systemen van klanten zelf, noch voor de kanalen die zij ons laten benaderen; de scheidslijn daartussen staat in hoofdstuk 12.

Twee beginselen sturen elke afweging. Ten eerste: gegevens van een klant zijn van die klant. Wij verwerken ze uitsluitend om de dienst te leveren en ontlenen er geen ander recht aan. Ten tweede: een systeem dat namens een organisatie met haar klanten communiceert, mag nooit meer kunnen dan die organisatie uitdrukkelijk heeft toegestaan. Waar die twee beginselen botsen met gemak, wint het beginsel.

2. Governance

De verantwoordelijkheid voor informatiebeveiliging ligt bij de directie en is niet gedelegeerd naar een individuele ontwikkelaar. Beveiligingsrelevante wijzigingen — aan authenticatie, autorisatie, isolatie, versleuteling of de bevoegdheden van de AI-laag — worden als zodanig behandeld: expliciet beoordeeld vóór uitrol, en achteraf herleidbaar in de versiegeschiedenis en het wijzigingslogboek.

Dit document wordt ten minste jaarlijks herzien en bovendien telkens wanneer een wijziging daar aanleiding toe geeft. De datum bovenaan geeft de laatste herziening.

3. Gegevens: classificatie en levenscyclus

Wij onderscheiden drie categorieën, elk met een eigen behandeling.

Klantinhoud — de berichten, bijlagen en records die via de kanalen van een klant binnenkomen of uit diens systemen worden opgehaald. Hierin zijn wij verwerker. Deze gegevens worden nooit buiten de omgeving van de betreffende klant gebracht, niet samengevoegd met die van anderen en niet gebruikt voor productverbetering.

Bedrijfsgegevens — accountgegevens, instellingen, facturatie en correspondentie met de klant. Hierin zijn wij verwerkingsverantwoordelijke.

Geheimen — koppelingssleutels, mailboxtokens en vergelijkbare inloggegevens waarmee toegang tot systemen van derden wordt verkregen. Deze categorie kent de zwaarste behandeling: geheimen worden afzonderlijk versleuteld opgeslagen, zijn na opslag niet meer uitleesbaar via de applicatie, en worden nooit teruggetoond in een scherm, een logregel of een foutmelding.

Bewaartermijnen volgen het doel: klantinhoud zolang de klant de dienst gebruikt en volgens diens instelling, bedrijfsgegevens zolang de relatie loopt en de wettelijke bewaarplicht dat vergt, technische logboeken niet langer dan voor onderzoek naar storingen en misbruik nodig is.

4. Toegangsbeheer

Toegang berust op het beginsel van minimale rechten en wordt op drie niveaus afgedwongen.

Menselijke toegang. Toegang tot productieomgevingen is beperkt tot personen die deze voor hun taak nodig hebben, verloopt via persoonlijke accounts — nooit via gedeelde inloggegevens — en wordt vastgelegd. Rechten worden ingetrokken wanneer de noodzaak vervalt.

Toegang binnen de applicatie. Gebruikers van een klant hebben rollen met verschillende bevoegdheden; handelingen met gevolgen (instellingen wijzigen, koppelingen beheren, permissies verlenen) zijn voorbehouden aan de eigenaarsrol.

Toegang van componenten. Onderdelen van het systeem draaien met de rechten die hun taak vereist en niet meer. De applicatierol op de database is bewust beperkt en beschikt niet over de bevoegdheden die de isolatie in hoofdstuk 5 zouden kunnen omzeilen.

5. Isolatie tussen organisaties

Dit is de belangrijkste eigenschap van een gedeeld platform en daarom in lagen uitgevoerd, zodat één fout niet volstaat.

De applicatie beperkt elke bewerking tot de organisatie waartoe de aanvrager behoort. Onafhankelijk daarvan dwingt de database die scheiding zelf af: gegevens zijn per organisatie afgeschermd op rijniveau, waardoor een bevraging die door een programmeerfout buiten de eigen organisatie zou reiken, daar eenvoudigweg niets aantreft. Deze tweede laag is niet afhankelijk van de juistheid van de eerste — dat is precies het doel ervan.

Sessies zijn gebonden aan één organisatie. Een gebruiker die toegang heeft tot meerdere organisaties, wisselt daartussen langs een expliciete controle op lidmaatschap; een gestolen sessiecookie verschaft daarmee nooit toegang tot een organisatie waartoe de betrokkene niet behoort.

6. Cryptografie

Al het verkeer van en naar het platform verloopt uitsluitend over versleutelde verbindingen; onversleutelde verzoeken worden doorgeleid, niet beantwoord. Gegevens in rust zijn versleuteld op opslagniveau. Geheimen (hoofdstuk 3) kennen daarbovenop een eigen versleuteling met een sleutel die gescheiden van de gegevens wordt beheerd, zodat toegang tot een reservekopie op zichzelf geen toegang tot systemen van derden oplevert.

Wij publiceren geen algoritmen, sleutellengtes, protocolversies of rotatietermijnen op deze pagina; zie hoofdstuk 14.

7. Beheersing van de AI-laag

Hier onderscheidt dit platform zich van gangbare supportsoftware, en hier is de beheersing dan ook het strengst uitgewerkt. Een taalmodel is in onze architectuur een opsteller, geen uitvoerder.

Menselijke tussenkomst bij handelingen. Handelingen met gevolgen in de systemen van de klant — annuleren, wijzigen, terugbetalen, aanmaken — worden door de AI uitsluitend voorgesteld. Uitvoering volgt pas na goedkeuring door een bevoegd persoon. De klant bepaalt per soort handeling of dat zo blijft; bepaalde categorieën, waaronder terugbetalingen, zijn structureel niet automatiseerbaar.

Identiteitscontrole vóór persoonsgegevens. Voordat gegevens over een order, boeking of account worden gedeeld, moet vaststaan dat de vrager daar rechthebbende op is. Bij onvoldoende bewijs volgt geen gedeeltelijke informatie en evenmin een bevestiging of ontkenning van het bestaan van het record — dat laatste is zelf een gegeven.

Verankering in bronnen. Antwoorden worden gevormd op basis van de kennisbank en de gekoppelde systemen van de klant. Ontbreekt een grondslag, dan wordt geëscaleerd naar een mens in plaats van gegist. Uitgaande antwoorden passeren een geautomatiseerde controle die niet-onderbouwde beweringen tegenhoudt.

Modelleveranciers als subverwerkers. Taalmodellen worden betrokken bij externe leveranciers. Klantinhoud die daarheen gaat, wordt niet gebruikt voor het trainen of verbeteren van hun modellen; dit is contractueel vastgelegd. Welke leveranciers dit zijn, in welke rol en met welke waarborgen, staat in het verwerkingsregister.

Herleidbaarheid. Van elk gegenereerd antwoord is vastgelegd welke bronnen en welke systeemaanroepen eraan ten grondslag lagen. Een antwoord dat achteraf ter discussie staat, is daarmee reconstrueerbaar.

8. Logging, detectie en respons

Aanmeldingen, wijzigingen aan instellingen, verleende permissies, uitgevoerde handelingen en het opvragen van gegevens worden vastgelegd met actor, tijdstip en herkomst. Klanten kunnen hun eigen logboek inzien; het is daarmee geen intern instrument maar een verantwoordingsmiddel.

Daarnaast bewaken wij afwijkende patronen: ongebruikelijke hoeveelheden gegevens die in korte tijd worden opgehaald, herhaalde mislukte aanmeldingen over meerdere accounts, en verkeerspieken uit één herkomst. Overschrijding van een drempel leidt tot vastlegging, alarmering en waar passend tot tijdelijke begrenzing van de betreffende handeling.

Wij zetten daarbij bewust niet automatisch accounts of netwerkadressen op slot. Een automatisme dat toegang ontzegt, is zelf een aanvalsmiddel: het laat zich misbruiken om rechtmatige beheerders buiten te sluiten, en het maakt van een storing een uitsluiting. Begrenzen, vastleggen en alarmeren gebeurt geautomatiseerd; het ontzeggen van toegang is een menselijk besluit.

Incidenten. Bij een vermoed beveiligingsincident volgen wij een vaste volgorde: vaststellen, beperken, herstellen, vastleggen en informeren. Betreft het een inbreuk in verband met persoonsgegevens, dan informeren wij de betrokken klant zonder onnodige vertraging, zodat deze zijn eigen meldplicht binnen de wettelijke termijn kan nakomen. Wij melden niet namens de klant, tenzij anders overeengekomen — de klant is in die verhouding verwerkingsverantwoordelijke.

9. Continuïteit en herstel

Van de productiegegevens worden dagelijks reservekopieën gemaakt en versleuteld bewaard. Op het maken van die kopieën staat geautomatiseerde bewaking: blijft een kopie uit, dan volgt een alarm. Een reservekopie waarvan pas bij herstel blijkt dat hij ontbrak, is geen voorziening maar een aanname.

Hersteldoelstellingen delen wij desgevraagd, evenals de datum van de laatste herstelproef.

10. Veilige ontwikkeling en kwetsbaarheidsbeheer

Wijzigingen worden versiebeheerd, beoordeeld en met geautomatiseerde tests uitgerold; de testsuite draait mee in de productieomgeving zodat wat getest wordt ook draait. Afhankelijkheden worden bijgehouden en bij bekende kwetsbaarheden bijgewerkt, met een urgentie die past bij de ernst en de blootstelling. Beveiligingsrelevante wijzigingen worden apart behandeld (hoofdstuk 2).

Gebruikersinvoer wordt behandeld als onbetrouwbaar, ook wanneer deze via een taalmodel het systeem binnenkomt — juist dan, omdat een model tekst van derden verwerkt en die tekst instructies kan bevatten.

11. Leveranciers en subverwerkers

Wij besteden onderdelen uit die wij niet zelf beter kunnen doen: hosting, e-mailbezorging, betalingsverwerking en taalmodellen. Met elke subverwerker zijn afspraken gemaakt over vertrouwelijkheid, beveiliging en het verbod om gegevens voor eigen doeleinden te gebruiken. Verwerking vindt plaats binnen de Europese Unie; waar een leverancier onvermijdelijk daarbuiten verwerkt, gebeurt dat onder de daarvoor bestemde waarborgen.

Het actuele register — leverancier, rol, verwerkte gegevens, vestiging en waarborg — verstrekken wij op verzoek. Klanten worden vooraf geïnformeerd over voorgenomen wijzigingen daarin.

12. Gedeelde verantwoordelijkheid

Een deel van de beveiliging ligt buiten ons bereik en binnen dat van de klant. Wij zijn verantwoordelijk voor het platform, de isolatie, de versleuteling, de bewaking en de beheersing van de AI-laag. De klant is verantwoordelijk voor: het toekennen en intrekken van rollen binnen de eigen organisatie, de zorgvuldigheid waarmee koppelingssleutels worden bewaard, de juistheid van de instellingen die bepalen wat de AI mag, en het toezicht op wat er namens de organisatie wordt verzonden. Wij bieden daarvoor de instrumenten — logboeken, permissies, wachttermijnen, steekproeven; het gebruik ervan is aan de klant.

13. Certificering — waar wij staan

SupportCore beschikt op dit moment niet over een ISO 27001-certificering of een SOC 2-rapportage. Wij vinden het belangrijker dat te zeggen dan het te suggereren. Wat wij wel doen, is dit beleid inrichten langs de domeinen die die normen hanteren — governance, toegangsbeheer, cryptografie, logging, continuïteit, leveranciersbeheer en incidentrespons — en ons daarop laten bevragen.

Voor organisaties met een formele leveranciersbeoordeling vullen wij een beveiligingsvragenlijst in en gaan wij, onder geheimhouding, in op onderwerpen die op deze pagina bewust globaal blijven.

14. Wat wij bewust niet publiceren

Op deze pagina staan geen versienummers, netwerktopologieën, namen van beveiligingscomponenten, sleutelgegevens of exacte drempelwaarden. Die informatie verhoogt de veiligheid van geen enkele lezer en verlaagt de inspanning voor wie kwaad wil. Het weglaten ervan is een maatregel, geen terughoudendheid — en het maakt de rest van dit document juist toetsbaar, omdat het gaat over eigenschappen die u ons kunt laten aantonen.

15. Kwetsbaarheden melden

Wij stellen meldingen op prijs en ondernemen geen juridische stappen tegen wie te goeder trouw meldt en zich aan het onderstaande houdt.

Meld aan security@supportcore.ai, met een beschrijving van de bevinding en de stappen om deze te reproduceren. U ontvangt binnen twee werkdagen een inhoudelijke reactie van een mens en blijft op de hoogte tot de bevinding is afgehandeld.

Wat wij vragen: geef ons redelijke gelegenheid tot herstel voordat u publiceert; beperk uw onderzoek tot wat nodig is om de bevinding aan te tonen; benader geen gegevens van anderen — stuit u daar onbedoeld op, staak dan en meld het. Geen geautomatiseerde scans die de dienst belasten, geen aanvallen op beschikbaarheid, geen social engineering van medewerkers of klanten, en geen fysieke toegangspogingen.

16. Contact

Vragen over dit beleid, een leveranciersbeoordeling of een vermoed incident: security@supportcore.ai. Vragen over persoonsgegevens en rechten van betrokkenen: privacy@supportcore.ai, of zie ons privacybeleid.