> over > voorwaarden en beleid > Beveiligingsmaatregelen

Beveiligingsmaatregelen

Beveiligingsmaatregelen van ProcessMind

Ingangsdatum: 14 september 2026

Dit document beschrijft de technische en organisatorische maatregelen („TOM’s”) die ProcessMind B.V. handhaaft om de vertrouwelijkheid, integriteit en beschikbaarheid van Klantgegevens te beschermen. ProcessMind hanteert een gelaagde beveiligingsaanpak waarbij meerdere onafhankelijke beveiligingslagen Klantgegevens op elk niveau beschermen — van netwerk en infrastructuur tot identiteit, autorisatie, gegevensisolatie, versleuteling, monitoring en softwareontwikkeling. Deze maatregelen vormen een aanvulling op de Verwerkersovereenkomst, het Privacybeleid en het SaaS-hostingbeleid. ProcessMind beoordeelt en actualiseert deze maatregelen ten minste jaarlijks.

Klantgegevens worden nooit verkocht aan of gedeeld met derden, of door derden voor hun eigen doeleinden gebruikt.

1. Infrastructuurbeveiliging

1.1 Cloudplatform. ProcessMind wordt uitsluitend gehost op Amazon Web Services (AWS) in de EU (Frankfurt, Duitsland, eu-central-1). AWS beschikt over certificeringen voor ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 en PCI DSS. Raadpleeg AWS Compliance Programs voor een volledige lijst.

1.2 Serverloze architectuur. De toepassingslogica van ProcessMind draait op AWS Lambda en door AWS beheerde diensten. ProcessMind beheert geen langdurig actieve applicatieservers die door klanten worden beheerd, waardoor een groot deel van het werk voor het patchen van besturingssystemen en het beveiligen van servers vervalt.

1.3 Netwerkgrenzen. ProcessMind beheert een AWS VPC voor database- en netwerkbeheersmaatregelen. Aurora PostgreSQL draait in private subnetten zonder uitgaand internetverkeer, is niet openbaar toegankelijk en VPC-flowlogs zijn ingeschakeld. ProcessMind plaatst applicatie-Lambda-functies standaard niet binnen de VPC. Lambda-functies maken via de AWS RDS Data API verbinding met Aurora over TLS, met gebruik van IAM- en Secrets Manager-authenticatie.

1.4 Content delivery en edge-beheersmaatregelen. De website voor klanten, de frontend-SPA en het openbare verkeer naar bronnen worden geleverd via Amazon CloudFront. Voor alle CloudFront-distributies geldt een minimaal TLS-beleid van TLS 1.2 (2021). De distributies van de website en frontend-SPA voegen ook beveiligingsheaders toe aan reacties, waaronder HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, een referrerbeleid en een permissionsbeleid. De distributie van openbare bronnen gebruikt CloudFront Origin Access Control om de origin-bucket privé te houden. API-verkeer van klanten wordt afzonderlijk afgehandeld via Amazon API Gateway: HTTPS-verzoek-/antwoordverkeer wordt geleverd via een HTTP API op een speciaal API-subdomein en realtime clientverbindingen worden geleverd via een afzonderlijke API Gateway WebSocket API op een speciaal WebSocket-subdomein.

1.5 Scheiding van omgevingen. De productie- en ontwikkelomgevingen gebruiken afzonderlijke AWS-accounts, afzonderlijke databases en afzonderlijke infrastructuurstacks. Ontwikkelaarsreferenties geven geen toegang tot productie-Klantgegevens.

2. Gegevensversleuteling

2.1 Versleuteling tijdens verzending. Alle gegevens die tussen clients en ProcessMind-diensten worden verzonden, worden versleuteld met TLS 1.2 of hoger. Eindpunten voor klanten zijn toegankelijk via HTTPS. S3-buckets, SNS-topics en SQS-wachtrijen die rechtstreeks door ProcessMind zijn aangemaakt, vereisen uitsluitend SSL-toegang. Voor toegang tot databases via de RDS Data API en voor andere aanroepen van AWS-diensten wordt HTTPS/TLS gebruikt.

2.2 Versleuteling in rust. Aurora PostgreSQL is in rust versleuteld met door de klant beheerde AWS KMS-sleutels die automatisch worden geroteerd. S3-buckets voor klantgegevens en operationele gegevens die rechtstreeks door ProcessMind zijn aangemaakt, waaronder buckets voor uploads, bronnen en toegangslogboeken, gebruiken door de klant beheerde KMS-sleutels. CloudWatch-loggroepen, SNS-topics en SQS-wachtrijen die rechtstreeks door ProcessMind zijn aangemaakt, gebruiken eveneens door de klant beheerde KMS-sleutels. SST-beheerde origin-buckets voor de website en frontend gebruiken door AWS beheerde server-side S3-versleuteling (SSE-S3 / AES-256) in plaats van door de klant beheerde KMS-sleutels.

2.3 Sleutelbeheer en geheimen. Databaseversleutelingssleutels worden centraal beheerd via AWS KMS en de toegang tot sleutels wordt geregeld door IAM-beleidsregels volgens het beginsel van minimale bevoegdheden. Databasegegevens worden opgeslagen in AWS Secrets Manager. Het Aurora-mastergeheim en het geheim voor de beperkte applicatiegebruiker worden elke dertig (30) dagen automatisch geroteerd. Productiesleutels en -geheimen worden nooit in broncode opgeslagen; uitsluitend voor ontwikkeling bestemde referenties zijn gescheiden van productie. Sommige ondersteunende bronnen die door AWS/CDK/SST worden beheerd, blijven versleuteling gebruiken die door AWS wordt beheerd wanneer de dienst of het framework geen configuratie voor door de klant beheerde sleutels beschikbaar stelt.

3. Gegevensisolatie en gegevenslocatie

3.1 Tenantisolatie. Elke klanttenant krijgt een eigen, geïsoleerde database-instantie. Klantgegevens worden op databaseniveau nooit vermengd met gegevens van andere klanten. Gedeelde metadata (bijvoorbeeld accountgegevens, facturering en koppelingen tussen gebruikers en tenants) wordt opgeslagen in een afzonderlijke database met meerdere tenants en strenge toegangscontroles. Gedeelde tabellen die zijn afgebakend op tenant- en organisatieniveau worden bovendien beschermd door PostgreSQL-beleidsregels voor beveiliging op rijniveau (RLS), die worden afgedwongen via een context op databaseniveau die aan het verzoek is gekoppeld.

3.2 Gegevenslocatie. Alle Klantgegevens, waaronder databases, bestandsuploads, back-ups en queryresultaten, worden uitsluitend opgeslagen in de EU (Frankfurt, Duitsland). Wanneer voor een specifieke verwerkingsactiviteit een subverwerker buiten de EER wordt ingeschakeld (bijvoorbeeld voor de verwerking van AI-modellen of betalingen), valt de doorgifte onder een passende doorgiftemechanisme zoals beschreven in het Addendum gegevensverwerking. De subverwerker en de locatie van de verwerking worden vermeld in de lijst van subverwerkers.

3.3 Bewaring en verwijdering van gegevens. De bewaartermijnen en termijnen voor verwijdering zijn vastgelegd in sectie 6 van de Verwerkersovereenkomst. Klanten kunnen hun gegevens op elk moment verwijderen via de applicatie of door contact op te nemen met ProcessMind. Back-upkopieën worden verwijderd zodra de toepasselijke bewaartermijnen voor back-ups verstrijken (sectie 7.1).

4. Identiteits- en toegangsbeheer

4.1 Authenticatie. ProcessMind ondersteunt Single Sign-On (SSO) via Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC en LinkedIn OAuth 2.0/OIDC. ProcessMind treedt op als relying party en slaat geen gebruikerswachtwoorden op. Multifactorauthenticatie wordt afgedwongen door de identiteitsprovider — bijvoorbeeld: wanneer een organisatie Microsoft Entra ID (Azure AD) koppelt, zijn de eigen MFA- en toegangsbeleidsregels van die organisatie van toepassing.

4.2 Sessiebeheer. Browsersessies gebruiken ondertekende JSON Web Tokens (JWT) die worden verzonden via beveiligde HttpOnly-cookies met SameSite- en Secure-vlaggen. De handtekeningen van tokens worden bij elk geauthenticeerd verzoek gevalideerd.

4.3 Autorisatiemodel. ProcessMind is voor de kern-API’s van de applicatie niet afhankelijk van native authorizers van API Gateway. Autorisatie wordt afgedwongen in gedeelde Lambda-handlerwrappers die de sessiestatus en de tenantafbakening valideren voordat de bedrijfslogica wordt uitgevoerd. Openbare routes zijn uitdrukkelijk toegestaan voor niet-geauthenticeerde processen, webhooks, gebeurtenisverwerking en CORS-preflightverzoeken. Externe API-eindpunten gebruiken speciale authenticatiehandlers. De toegang tot Klantgegevens is beperkt tot de context van de geauthenticeerde tenant of organisatie.

4.4 Minimale bevoegdheden. Interne systemen volgen het beginsel van minimale bevoegdheden. IAM-rollen worden beperkt tot de minimaal vereiste bronnen wanneer het framework een nauwkeurige afbakening toestaat. Sommige door SST/CDK gegenereerde rollen gebruiken ruimere beheerde of inline beleidsregels voor bindings en runtimebewerkingen; deze gevallen worden beoordeeld, waar mogelijk beperkt tot specifieke bronnen en als uitdrukkelijke uitzonderingen bijgehouden.

4.5 Toegangscontroles voor werknemers. De toegang van werknemers tot interne systemen wordt beheerd via Active Directory met SSO en verplichte MFA. Op rollen gebaseerde toegangscontrole (RBAC) zorgt ervoor dat de toegang tot Klantgegevens wordt beperkt tot bevoegd personeel dat deze gegevens voor de uitvoering van zijn taken nodig heeft. Toegangsrechten worden periodiek beoordeeld.

5. Logboekregistratie, monitoring en audit

5.1 Gecentraliseerde logging. HTTP API-toegangslogging en WebSocket-toegangslogging zijn ingeschakeld met gestructureerde JSON-velden en worden met een bewaartermijn van één (1) jaar naar Amazon CloudWatch Logs geschreven. Deze toegangsloggroepen zijn versleuteld met een door de klant beheerde AWS KMS-sleutel. Applicatielogs worden gecentraliseerd in Amazon CloudWatch-loggroepen die zijn versleuteld met een door de klant beheerde AWS KMS-sleutel en tien (10) jaar worden bewaard. Afzonderlijke audit- en telemetrieloggroepen zijn eveneens versleuteld met een door de klant beheerde AWS KMS-sleutel en worden tien (10) jaar bewaard. De exportgroep voor de Aurora PostgreSQL-engine-log wordt één (1) week bewaard.

5.2 Wat wel en niet wordt gelogd. ProcessMind logt HTTP API- en WebSocket-toegangsevenementen — het tijdstip van het verzoek, verzoekidentificatoren, de route of het pad, de responsstatus en de latentie. De toegangslogs bevatten niet het bron-IP-adres of de user-agent van de aanroeper. ProcessMind logt ook authenticatiegebeurtenissen, asynchrone foutpaden en ondersteunende Lambda-applicatieactiviteit in gecentraliseerde CloudWatch-loggroepen. VPC-flowlogs zijn ingeschakeld. ProcessMind heeft momenteel geen standaard CloudFront-toegangslogging ingeschakeld voor de website, de frontend-SPA of de distributies van openbare bronnen.

5.3 Monitoring en waarschuwingen. CloudWatch-waarschuwingen en -dashboards monitoren de systeemstatus, dead-letter queues en beveiligingsrelevante storingen. Storingen in asynchrone verwerking worden doorgestuurd naar versleutelde dead-letter queues (bewaartermijn van veertien (14) dagen; twee (2) dagen voor de queues voor miniaturen en zoekindexen), en DLQ-waarschuwingen activeren SNS-meldingen voor onderzoek. Daarnaast gebruikt ProcessMind Sentry voor realtime tracking van frontendfouten, prestatiemonitoring en sessieherhaling. Sessieherhalingen worden alleen opgenomen voor sessies waarin een fout optreedt; tekst, formulierinvoer en media worden in de herhalingen afgeschermd of geblokkeerd. Sentry-gegevens worden opgenomen in de EU (Frankfurt) en zijn beperkt tot ProcessMind-gebruiksgegevens (browserfouten, prestatietraces, apparaatgegevens en afgeschermde sessieopnamen). Sentry staat vermeld in de lijst van subverwerkers.

5.4 Bescherming van logboeken. Logboeken worden opgeslagen in speciale CloudWatch-loggroepen met toegangsbeheer en zijn in rust versleuteld. Productie- en ontwikkellogboeken zijn gescheiden op basis van omgevings- en accountgrenzen.

6. Geautomatiseerde validatie van beheersmaatregelen en kwetsbaarheidsbeheer

6.1 Wat ProcessMind doet. ProcessMind voert cdk-nag uit als onderdeel van de workflow voor het samenstellen en implementeren van de infrastructuur, met gebruik van meerdere regelsets uit de sector (waaronder AWS Solutions, NIST 800-53 en PCI DSS). Voor elke stack worden rapporten opgesteld en beoordeeld als onderdeel van het wijzigingsbeheer van de infrastructuur. Bevindingen worden aangemerkt als opgelost, aanvaard risico of geplande verbetering.

6.2 Hoe uitzonderingen worden beheerd. Uitsluitingen worden vastgelegd in een centraal register waar het framework dit toestaat, beperkt tot de betrokken stacks en voorzien van een schriftelijke motivering; wanneer een stack een inline-uitsluiting bevat, wordt deze naast die stack gedocumenteerd. Wanneer een bevinding is verholpen, wordt de bijbehorende uitsluiting bijgewerkt of verwijderd. ProcessMind beschouwt een uitsluiting niet als een algemene vrijstelling van beoordeling.

6.3 Wat ProcessMind momenteel niet doet. ProcessMind houdt wezenlijke uitzonderingen op beheersmaatregelen voor de infrastructuur bij en beoordeelt deze. De belangrijkste zijn:

applicatie-Lambdas worden standaard niet in de VPC geplaatst; ze bereiken Aurora via de RDS Data API over TLS, met authenticatie via IAM en Secrets Manager
geen enkel onderdeel van de dienst wordt beschermd door AWS WAF: AWS WAF ondersteunt API Gateway HTTP API’s niet en ook de overige toegangspunten worden niet door WAF beschermd (WebSocket-verbindingen gebruiken kortlopende HMAC-tokens; geografische beperkingen voor betalingen worden afgedwongen in het betalingssysteem); voor statische distributies is ook geen standaardtoegangsregistratie van CloudFront ingeschakeld
databaseherstel is gebaseerd op geautomatiseerde back-ups en herstel naar een bepaald tijdstip van Aurora, en niet op een afzonderlijk AWS Backup-plan of Aurora Enhanced Monitoring
er is geen S3-replicatie tussen regio’s of S3 Object Lock voor wijzigbare buckets
sommige ondersteunende bronnen die door AWS/CDK/SST worden beheerd, gebruiken door AWS beheerde versleuteling of ruimere, automatisch gegenereerde IAM-beleidsregels wanneer de dienst geen alternatief biedt dat door de klant kan worden beheerd

Het volledige register van uitzonderingen wordt bijgehouden naast de infrastructuurcode en is op verzoek beschikbaar. Het gebruik van cdk-nag regelpakketten is een technische validatie van beheersmaatregelen, geen externe certificering, auditverklaring of juridische verklaring van naleving van HIPAA, NIST of PCI DSS.

6.4 Beheer van afhankelijkheden. Softwareafhankelijkheden worden voortdurend gecontroleerd op bekende kwetsbaarheden. Kritieke kwetsbaarheden en kwetsbaarheden met een hoge ernst worden gepatcht met als streefdoel zeven (7) dagen. Afhankelijkheden worden volgens een vaste cyclus bijgewerkt.

6.5 Veilige softwareontwikkelingscyclus (SDLC). ProcessMind hanteert bij softwareontwikkeling een gelaagde verdedigingsaanpak. Elke wijziging in de productieomgeving moet vóór implementatie meerdere onafhankelijke geautomatiseerde validatielagen doorlopen:

Statische analyse en typeveiligheid: De strikte modus van TypeScript en ESLint dwingen tijdens het compileren typecorrectheid, null-veiligheid en beveiligingsrelevante codeerpatronen af.
AI-ondersteunde codebeoordeling: AI-ondersteunde analyse biedt een aanvullend perspectief bij de beoordeling van pull requests om beveiligingsrisico’s, logische fouten en afwijkingen van conventies te identificeren, als aanvulling op geautomatiseerd testen.
Unit- en integratietests: een uitgebreide Vitest-testsuite valideert bedrijfslogica, patronen voor gegevenstoegang, API-gedrag en foutafhandeling aan de hand van actieve AWS-bronnen in de ontwikkelomgeving.
End-to-endtests: browsertests op basis van Playwright controleren kritieke gebruikersworkflows, waaronder authenticatie, gegevensupload, procesmodellering, simulatie en isolatie tussen tenants.
Scans op naleving van infrastructuurvereisten: cdk-nag valideert infrastructuur als code bij elke wijziging aan de hand van meerdere nalevingskaders.
Scans op kwetsbaarheden in afhankelijkheden: geautomatiseerde audits van afhankelijkheden blokkeren bekende kritieke kwetsbaarheden en kwetsbaarheden met een hoge ernst voordat deze de productieomgeving bereiken.

Menselijke beoordeling is gericht op architectuur, beveiligingsgrenzen en beslissingen op ontwerpniveau, en niet op inspectie van code op regelniveau. Bij structurele, beveiligingsgevoelige of infrastructuurwijzigingen is naast geautomatiseerde validatie uitdrukkelijke goedkeuring door een mens vereist.

Alle validatielagen worden via CI afgedwongen als verplichte samenvoegingscontroles voor wijzigingen in de applicatie en infrastructuur naar de main-branch. De publicatie van websitecontent en statische bestanden volgt een afzonderlijk, gedocumenteerd publicatieproces met controles tijdens de implementatie — waaronder een geautomatiseerde controle of de juridische documenten actueel zijn — en niet de CI-controle voor de applicatie. Noodreparaties in productie mogen de CI-controle omzeilen, maar moeten binnen vierentwintig (24) uur worden gevolgd door een volledige uitvoering van de pipeline en een evaluatie na het incident.

7. Back-ups en herstel na calamiteiten

7.1 Geautomatiseerde back-ups. Amazon Aurora maakt doorlopend geautomatiseerde back-ups met een bewaartermijn van zeven (7) dagen. Back-ups worden versleuteld met dezelfde door de klant beheerde KMS-sleutels als de brondatabases.

7.2 Point-in-time recovery. Aurora ondersteunt point-in-time recovery naar elke seconde binnen de bewaartermijn van de back-up, zodat gegevens snel kunnen worden hersteld in geval van beschadiging of onbedoelde verwijdering.

7.3 Duurzaamheid en versiebeheer van S3. Bestandsuploads en operationele artefacten worden opgeslagen in Amazon S3, dat een duurzaamheid van 99,999999999% (11 negens) biedt. Versiebeheer is ingeschakeld voor de uploadbucket en de bronbuckets ter ondersteuning van herstel en terugdraaiacties. Website- en frontend-implementatiebuckets bevatten reproduceerbare bouwartefacten en worden niet als back-upsysteem beschouwd. ProcessMind heeft momenteel geen S3-replicatie tussen regio’s ingeschakeld.

7.4 Bedrijfscontinuïteit. Procedures voor herstel na calamiteiten zijn gedocumenteerd en worden periodiek getest. Een samenvatting is beschikbaar in het document Herstel na calamiteiten, bedrijfscontinuïteit en incidentrespons. De architectuur is gebaseerd op door AWS beheerde diensten binnen de eu-central-1-regio, die AWS over meerdere Availability Zones exploiteert; het Aurora-cluster draait momenteel op één writer-instantie. Databaseherstel is daarom afhankelijk van geautomatiseerde back-ups en herstel naar een bepaald tijdstip, en niet van een standby binnen de regio. Aurora-back-ups, de duurzaamheid van S3, dead-letter queues en statische assets die opnieuw kunnen worden opgebouwd vanuit de bron maken deel uit van de herstelstrategie.

8. Incidentrespons

8.1 Melding van incidenten. In geval van een beveiligingsincident (zoals gedefinieerd in de DPA) stelt ProcessMind de getroffen klanten zonder onredelijke vertraging op de hoogte en, indien haalbaar, binnen tweeënzeventig (72) uur nadat ProcessMind van het incident kennis heeft genomen.

8.2 Incidentafhandeling. ProcessMind hanteert gedocumenteerde procedures voor incidentrespons die identificatie, indamming, uitroeiing, herstel en evaluatie na het incident omvatten. Een samenvatting is beschikbaar in het document Herstel na calamiteiten, bedrijfscontinuïteit en incidentrespons. De lessen die uit incidenten worden getrokken, worden verwerkt in beveiligingsmaatregelen en -processen.

8.3 Communicatie. Meldingen van incidenten bevatten de aard en omvang van het incident, de getroffen gegevenscategorieën, de maatregelen die zijn genomen om het incident in te dammen en aanbevolen acties voor de klant.

9. Organisatorische maatregelen

9.1. Beheer van informatiebeveiliging. ProcessMind onderhoudt een beheersysteem voor informatiebeveiliging dat is afgestemd op de beginselen van ISO 27001. ProcessMind heeft het certificeringstraject voor ISO 27001-certificering en SOC 2 Type II-attestatie gekozen; het formele certificeringsproces is nog niet gestart.

9.2 Beveiligingsbewustzijn. Alle medewerkers met toegang tot klantgegevens krijgen training in beveiligingsbewustzijn. Aanbevolen beveiligingspraktijken zijn opgenomen in de onboarding, ontwikkelworkflows en operationele procedures.

9.3 Beheer van leveranciers en subverwerkers. Subverwerkers zijn contractueel gebonden aan normen voor gegevensbescherming die gelijkwaardig zijn aan de normen in dit document. ProcessMind houdt een openbare lijst van subverwerkers bij en geeft ten minste dertig (30) dagen van tevoren kennis voordat een nieuwe subverwerker wordt ingeschakeld. Subverwerkers worden jaarlijks beoordeeld op naleving.

9.4 Vertrouwelijkheid. Alle medewerkers die bevoegd zijn om klantgegevens te verwerken, zijn gebonden aan schriftelijke geheimhoudingsverplichtingen.

10. Naleving en certificeringen

Kader / norm	Status
AVG (Algemene verordening gegevensbescherming van de EU)	Nageleefd
Gegevensopslag in de EU (Frankfurt, Duitsland)	Afgedwongen
AWS-infrastructuurcertificeringen (ISO 27001, SOC 2, PCI DSS)	Overgenomen via AWS
ISO 27001 (ProcessMind)	Gepland — certificeringstraject geselecteerd; formeel proces nog niet gestart
SOC 2 Type II (ProcessMind)	Gepland — certificeringstraject geselecteerd; formeel proces nog niet gestart
Geautomatiseerde validatie van infrastructuurbeheersmaatregelen (`cdk-nag` voor AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless)	Geïmplementeerd als validatie van technische beheersmaatregelen, niet als certificering
Standaardcontractbepalingen (SCC’s) voor internationale doorgiften	Geïmplementeerd (zie DPA)
Verwerkersovereenkomst (DPA)	Openbaar beschikbaar

Het gebruik van cdk-nag regelpakketten betekent niet dat ProcessMind formeel is gecertificeerd of onafhankelijk is gecontroleerd op naleving van HIPAA, NIST of PCI DSS. Deze regelpakketten worden gebruikt als technische waarborgen om het infrastructuurontwerp te valideren en tekortkomingen expliciet bij te houden.

Neem voor vragen over beveiliging of naleving, of om documentatie aan te vragen, zoals auditrapporten of ingevulde beveiligingsvragenlijsten, contact op via support@processmind.com.