Rampenherstel, bedrijfscontinuïteit en incidentrespons
Rampenherstel, bedrijfscontinuïteit en incidentrespons van ProcessMind
Ingangsdatum: 14 september 2026
Dit document bevat een samenvatting op hoofdlijnen van de procedures van ProcessMind B.V. voor herstel na calamiteiten („DR”), bedrijfscontinuïteit („BCP”) en de respons op beveiligingsincidenten voor haar clouddienst. Het vormt een aanvulling op de Beveiligingsmaatregelen, het SaaS-hostingbeleid, de Service Level Agreement en de Verwerkersovereenkomst.
Het licht onze huidige aanpak toe en schept geen afzonderlijke contractuele doelstellingen voor hersteltijd of herstelpunt, garanties voor gegevensduurzaamheid, kennisgevingstermijnen, serviceniveaus of aansprakelijkheidsnormen, behalve voor zover uitdrukkelijk bepaald in de toepasselijke overeenkomst, DPA of SLA.
1. Doelstellingen en toepassingsgebied
ProcessMind hanteert deze procedures om:
- de vertrouwelijkheid, integriteit en beschikbaarheid van Klantgegevens tijdens een verstorende gebeurtenis te beschermen
- kritieke productiecomponenten van de dienst te herstellen na storingen in systemen die door ProcessMind worden beheerd
- incidentbeheer, klantcommunicatie en operationele besluitvorming voort te zetten tijdens dienstonderbrekingen
- te herstellen van storingen in infrastructuur, implementaties, applicaties of de gegevenslaag met behulp van gedocumenteerde procedures en infrastructuurdefinities die onder versiebeheer staan
- Beveiligingsincidenten te identificeren en te beoordelen, bedreigingen in te dammen, de onderliggende oorzaken weg te nemen, getroffen systemen te herstellen, waar vereist te communiceren en geleerde lessen vast te leggen
Deze procedures zijn van toepassing op de productieclouddienst van ProcessMind en op beveiligingsgebeurtenissen waarbij subverwerkers of clouddiensten betrokken zijn, voor zover deze de Dienst beïnvloeden en ProcessMind redelijkerwijs in staat is deze te onderzoeken en te beheren. Ontwikkel- en testomgevingen zijn gescheiden en worden niet beschouwd als hersteldoelen voor toezeggingen met betrekking tot productieomgevingen voor klanten.
2. Strategie voor weerbaarheid
2.1 Regionale opzet. Productiediensten worden gehost in AWS EU (Frankfurt, Duitsland, eu-central-1). De architectuur is gebaseerd op door AWS beheerde diensten binnen die regio, die AWS over meerdere Availability Zones verspreid beheert. 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-instantie binnen de regio. ProcessMind beheert momenteel geen tweede actieve regio voor klantgegevens.
2.2 Beheerde en serverless diensten. ProcessMind maakt gebruik van AWS Lambda, Amazon API Gateway, Amazon CloudFront, Amazon Aurora PostgreSQL, Amazon S3, Amazon SQS, Amazon SNS en Amazon CloudWatch. Hierdoor is er minder afhankelijkheid van langdurig draaiende servers die door klanten worden beheerd en wordt herstel door herbouw vanuit de broncode ondersteund voor applicatie- en statische componenten.
2.3 Scheiding van omgevingen. Productie- en ontwikkelomgevingen draaien in afzonderlijke AWS-accounts met afzonderlijke databases en infrastructuurstacks. Hierdoor wordt het risico verkleind dat ontwikkelactiviteiten van invloed zijn op herstelwerkzaamheden in productie.
2.4 Monitoring en detectie. CloudWatch-alarmen, dashboards, meldingen van dead-letter queues, gecentraliseerde logboekregistratie en synthetische servicemonitoring ondersteunen de detectie, triage en escalatie van incidenten. Mogelijke incidenten kunnen ook aan het licht komen via supportverzoeken, meldingen van medewerkers, kennisgevingen van leveranciers of andere aanleidingen voor onderzoek.
3. Herstelprioriteiten
Tijdens een ernstig incident zijn de herstelprioriteiten van ProcessMind doorgaans:
- De integriteit van klantgegevens beschermen en verdere schade voorkomen.
- Het incident indammen en de getroffen systemen stabiliseren.
- De toegang tot de kernproductieomgeving en kritieke workflows herstellen.
- De werking van de dienst, de integriteit van gegevens en de monitoring valideren voordat het herstel als voltooid wordt beschouwd.
- Statusupdates, gevolgen voor klanten en vervolgacties communiceren.
De precieze volgorde kan variëren afhankelijk van de aard van het incident, waaronder de vraag of het gevolgen heeft voor de integriteit van gegevens, de toegang voor klanten, asynchrone verwerking of ondersteunende infrastructuur.
4. Procedures voor rampenherstel
4.1 Incidentverklaring en coördinatie. Wezenlijke dienstonderbrekingen en beveiligingsincidenten worden getrieerd volgens de procedures voor incidentrespons. ProcessMind wijst een incidentleider aan, beperkt deelname aan de respons tot bevoegd personeel, beoordeelt de ernst en omvang, coördineert technische hulpverleners en volgt herstelacties totdat het incident is opgelost of de ernst ervan is verlaagd.
4.2 Indamming. ProcessMind stelt zich commercieel redelijkerwijs in om de voortdurende gevolgen te stoppen of te beperken voordat met uitgebreider herstel wordt begonnen. Afhankelijk van de aard van de storing kunnen indammingsmaatregelen bestaan uit het terugdraaien van recente wijzigingen, het uitschakelen van getroffen toegangspaden, het isoleren van defecte componenten, het pauzeren van achtergrondverwerking terwijl integriteitscontroles worden uitgevoerd, het intrekken of vernieuwen van inloggegevens of het blokkeren van misbruik.
4.3 Wegnemen van de oorzaak. Nadat de onmiddellijke gevolgen zijn gestabiliseerd, werkt ProcessMind eraan de onderliggende oorzaak of bijdragende omstandigheid weg te nemen. Dit kan bestaan uit het toepassen van code- of configuratiecorrecties, het verwijderen van schadelijke artefacten, het vernieuwen van geheimen, het herstellen van een vertrouwde configuratie of het afsluiten van blootgestelde toegangspaden.
4.4 Databaseherstel. Aurora PostgreSQL voert doorlopend geautomatiseerde back-ups uit met een bewaartermijn van zeven (7) dagen en ondersteunt herstel naar een bepaald tijdstip. Als een storing op databaseniveau, beschadiging of onbedoelde destructieve wijziging herstel noodzakelijk maakt, kan ProcessMind herstellen vanaf de meest geschikte recente back-up of naar een geselecteerd tijdstip, de herstelde omgeving valideren en het applicatieverkeer terugleiden naar het herstelde databasepad.
4.5 Herstel van objecten en artefacten. Uploads van klantbestanden en operationele artefacten worden opgeslagen in Amazon S3. Versiebeheer is ingeschakeld voor de uploadbucket en resourcebuckets ter ondersteuning van herstel na onbedoelde verwijdering of overschrijving. Website- en frontend-implementatiebuckets worden beschouwd als reproduceerbare artefacten en kunnen opnieuw vanuit de broncode worden opgebouwd in plaats van als back-up te worden hersteld.
4.6 Herstel van asynchrone workloads. Asynchrone verwerkingspaden gebruiken dead-letter queues om mislukte gebeurtenissen te bewaren voor onderzoek. Herstel kan bestaan uit het opnieuw proberen van mislukte berichten, het opnieuw uitvoeren van verwerkingslogica of het opnieuw afspelen van werk wanneer de onderliggende workflow veilige herverwerking ondersteunt.
4.7 Herbouw van applicaties en infrastructuur. De infrastructuur wordt beheerd met infrastructuur-als-code-definities die onder versiebeheer staan. Als applicatie-infrastructuur of statische assets opnieuw moeten worden aangemaakt, kan ProcessMind de getroffen componenten opnieuw opbouwen en implementeren aan de hand van definities en bouwartefacten die onder versiebeheer staan.
4.8 Validatie voordat de dienst wordt hervat. Voordat een incident wordt afgesloten, valideert ProcessMind de status van de dienst met behulp van beschikbare monitoring, logboeken, synthetische controles en gerichte functionele verificatie, en herstelt het getroffen functionaliteit met behulp van gevalideerde implementatie-, herstel- en infrastructuurprocedures. Er kan aanvullend onderzoek plaatsvinden wanneer het incident betrekking had op gegevensherstel of risico’s voor de gegevensintegriteit.
5. Maatregelen voor bedrijfscontinuïteit
5.1 Operationele continuïteit. ProcessMind houdt gedocumenteerde operationele procedures bij, zodat incidentafhandeling, de ontvangst van supportverzoeken van klanten, de respons van engineering en besluitvorming tijdens verstorende gebeurtenissen kunnen doorgaan.
5.2 Communicatie. Bij wezenlijke productie-incidenten stelt ProcessMind zich commercieel redelijkerwijs in om updates te verstrekken via supportkanalen voor klanten en, waar passend, via de openbare statuspagina op processmind.com/status.
5.3 Beheerd wijzigingsbeheer. Een softwareontwikkelingscyclus met gelaagde beveiliging, meerdere onafhankelijke geautomatiseerde validatielagen, gecontroleerde implementaties, gecentraliseerde monitoring en evaluatie na incidenten wordt gebruikt om vermijdbare uitval te beperken en de continuïteit in de loop der tijd te verbeteren.
5.4 Beveiliging tijdens herstel. Herstelmaatregelen worden uitgevoerd volgens dezelfde algemene beveiligingsbeginselen die gelden tijdens de normale bedrijfsvoering, waaronder toegang op basis van minimale bevoegdheden, waar beschikbaar geregistreerde operationele activiteiten en gecontroleerde toegang tot productiesystemen en -gegevens.
6. Samenvatting van back-ups en gegevensbescherming
6.1 Databaseback-ups. Geautomatiseerde Aurora-back-ups zijn versleuteld en worden zeven (7) dagen bewaard; herstel naar een bepaald tijdstip is binnen die bewaartermijn mogelijk.
6.2 S3-beschermingsmaatregelen. Amazon S3 biedt een hoge duurzaamheid voor opgeslagen objecten. Voor buckets met wijzigbare klantgegevens wordt vertrouwd op duurzaamheid en versiebeheer binnen de primaire regio. ProcessMind heeft momenteel geen S3-replicatie tussen regio’s ingeschakeld voor die buckets.
6.3 Logboeken en diagnostiek. Gecentraliseerde logboeken, alarmen en telemetrie ondersteunen het onderzoeken van storingen en het valideren van herstel. Deze mechanismen ondersteunen de bedrijfscontinuïteit, maar worden niet op zichzelf aangeboden als een afzonderlijk back-upproduct.
7. Identificatie en triage van incidenten
7.1 Eerste beoordeling. Gemelde gebeurtenissen worden getrieerd om vast te stellen of ze voldoen aan de definitie van een Beveiligingsincident, welke systemen of gegevens mogelijk zijn getroffen, wat de waarschijnlijke omvang en ernst zijn en of onmiddellijke indamming nodig is. Bewijs wordt bewaard op een wijze die passend is bij de aard van het incident en de betrokken systemen.
7.2 Piketdienst en escalatie. ProcessMind heeft een piketdienst voor productie-incidenten, waaronder 24/7-dekking voor Kritieke incidenten (zoals gedefinieerd in de Service Level Agreement), zodat incidenten op elk moment kunnen worden bevestigd en getrieerd.
7.3 Documentatie. ProcessMind documenteert belangrijke onderzoeksbevindingen, responsmaatregelen en herstelbeslissingen, zodat het tijdsverloop van het incident en de daaruit voortvloeiende corrigerende maatregelen achteraf kunnen worden beoordeeld.
8. Communicatie en kennisgeving
8.1 Interne communicatie. ProcessMind coördineert de responsmedewerkers, besluitvormers en ondersteuningskanalen, zodat de technische respons en de communicatie met klanten gedurende de gehele levenscyclus van het incident op elkaar afgestemd blijven.
8.2 Kennisgeving aan klanten. In geval van een Beveiligingsincident waarvoor op grond van de DPA of toepasselijke wetgeving een kennisgeving vereist is, stelt ProcessMind de getroffen klanten zonder onnodige vertraging en, indien haalbaar, binnen tweeënzeventig (72) uur nadat ProcessMind kennis heeft gekregen van het incident op de hoogte. Kennisgevingen bevatten doorgaans de aard en omvang van het incident, indien bekend de getroffen categorieën gegevens, de maatregelen die zijn genomen om het incident in te dammen en te verhelpen, en waar relevant aanbevolen maatregelen voor klanten.
8.3 Voortgangsupdates. Als het incident nog gaande is of belangrijke feiten veranderen, verstrekt ProcessMind vervolgupdates zodra aanvullende geverifieerde informatie beschikbaar komt. Bij bredere verstoringen van de productiedienst kan ProcessMind ook klantondersteuningskanalen gebruiken en, waar passend, de openbare statuspagina op processmind.com/status.
9. Testen, beoordeling en onderhoud
ProcessMind beoordeelt deze procedures ten minste jaarlijks en na belangrijke incidenten of ingrijpende architectuurwijzigingen, oefent periodiek relevante onderdelen van de respons- en herstelbenadering (zoals het terugzetten van back-ups, het opnieuw opbouwen van implementaties, monitoring, waarschuwingen en incidentcommunicatie) en verwerkt de geleerde lessen in zijn beveiligings-, betrouwbaarheids- en bedrijfscontinuïteitsprocedures.
10. Beperkingen en contractuele grenzen
Dit document is een samenvatting op hoofdlijnen en beschrijft niet elke interne runbook, escalatieroute, onderzoeksmethode of stap voor bewijsverwerking in operationeel detail. Het verplicht ProcessMind niet tot een afzonderlijk ontwerp voor failover tussen regio’s, onveranderlijke opslagbewaring voor alle wijzigbare buckets of onafhankelijke RTO/RPO-garanties, behalve voor zover dit uitdrukkelijk is bepaald in de toepasselijke overeenkomst of opdracht.
Bij tegenstrijdigheid tussen dit document en de toepasselijke Klantovereenkomst, Gegevensverwerkingstoevoeging, Service Level Agreement of dwingende wetgeving, prevaleren die bronnen.