> about > terms and policies > Security Measures

Security Measures

Security Measures
PDF

ProcessMind Security Measures

Effective date: September 14, 2026

This document describes the technical and organizational measures (“TOMs”) ProcessMind B.V. maintains to protect the confidentiality, integrity, and availability of Customer Data. ProcessMind follows a defense-in-depth approach where multiple independent security layers protect Customer Data at every level — from network and infrastructure through identity, authorization, data isolation, encryption, monitoring, and software development. These measures supplement the Data Processing Addendum, the Privacy Policy, and the SaaS Hosting Policy. ProcessMind reviews and updates these measures at least annually.

Customer Data is never sold to, shared with, or used by third parties for their own purposes.

1. Infrastructure Security

1.1 Cloud Platform. ProcessMind is hosted exclusively on Amazon Web Services (AWS) in the EU (Frankfurt, Germany, eu-central-1). AWS maintains ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3, and PCI DSS certifications. See AWS Compliance Programs for a full list.

1.2 Serverless Architecture. ProcessMind application logic runs on AWS Lambda and AWS-managed services. ProcessMind does not operate customer-managed long-lived application servers, which removes a large class of operating system patching and server hardening work.

1.3 Network Boundaries. ProcessMind maintains an AWS VPC for database and network controls. Aurora PostgreSQL runs in private subnets with no internet egress, is not publicly accessible, and VPC flow logs are enabled. ProcessMind does not place application Lambda functions inside the VPC by default. Lambdas reach Aurora through the AWS RDS Data API over TLS using IAM and Secrets Manager authentication.

1.4 Content Delivery and Edge Controls. Customer-facing website, frontend SPA, and public resource traffic is served through Amazon CloudFront. All CloudFront distributions enforce a minimum TLS policy of TLS 1.2 (2021). The website and frontend SPA distributions also add security response headers, including HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, referrer policy, and permissions policy. The public resources distribution uses CloudFront Origin Access Control to keep the origin bucket private. Customer-facing API traffic is handled separately through Amazon API Gateway: HTTPS request/response traffic is served through an HTTP API on a dedicated API subdomain, and real-time client connections are served through a separate API Gateway WebSocket API on a dedicated WebSocket subdomain.

1.5 Environment Segregation. Production and development environments use separate AWS accounts, separate databases, and separate infrastructure stacks. Developer credentials do not provide access to production Customer Data.

2. Data Encryption

2.1 Encryption in Transit. All data transmitted between clients and ProcessMind services is encrypted using TLS 1.2 or higher. Customer-facing endpoints are exposed over HTTPS. S3 buckets, SNS topics, and SQS queues created directly by ProcessMind enforce SSL-only access. Database access through the RDS Data API and other AWS service calls uses HTTPS/TLS.

2.2 Encryption at Rest. Aurora PostgreSQL is encrypted at rest using customer-managed AWS KMS keys with automatic key rotation. Customer-data and operational S3 buckets created directly by ProcessMind, including uploads, resources, and access-log buckets, use customer-managed KMS keys. CloudWatch log groups, SNS topics, and SQS queues created directly by ProcessMind also use customer-managed KMS keys. SST-managed website and frontend origin buckets use AWS-managed S3 server-side encryption (SSE-S3 / AES-256) rather than customer-managed KMS keys.

2.3 Key Management and Secrets. Database encryption keys are managed centrally via AWS KMS, and key access is governed by IAM policies following least-privilege principles. Database credentials are stored in AWS Secrets Manager. The Aurora master secret and the restricted application-user secret rotate automatically every thirty (30) days. Production keys and secrets are never stored in source code; development-only credentials are isolated from production. Some AWS/CDK/SST-managed supporting resources continue to use AWS-managed encryption where the service or framework does not expose customer-managed key configuration.

3. Data Isolation and Residency

3.1 Tenant Isolation. Each customer tenant receives a dedicated, isolated database instance. Customer Data is never commingled with other customers’ data at the database level. Shared metadata (e.g., account records, billing, user to tenant mappings) is stored in a separate multi-tenant database with strict access controls. Tenant- and organization-scoped shared tables are additionally protected by PostgreSQL row-level security (RLS) policies enforced through request-scoped database context.

3.2 Data Residency. All Customer Data, including databases, file uploads, backups, and query results, is stored exclusively in the EU (Frankfurt, Germany). Where a sub-processor located outside the EEA is engaged for a specific processing activity (for example, AI model processing or payment processing), the transfer is covered by an appropriate transfer mechanism as described in the Data Processing Addendum, and the sub-processor and its processing location are listed in the Sub-processor List.

3.3 Data Retention and Deletion. Retention and deletion timelines are set out in Section 6 of the Data Processing Addendum. Customers may delete their data at any time through the application or by contacting ProcessMind. Backup copies are removed as the applicable backup retention windows expire (Section 7.1).

4. Identity and Access Management

4.1 Authentication. ProcessMind supports Single Sign-On (SSO) via Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC, and LinkedIn OAuth 2.0/OIDC. ProcessMind acts as a relying party and does not store user passwords. Multi-factor authentication is enforced by the identity provider — for example, where an organization connects Microsoft Entra ID (Azure AD), that organization’s own MFA and access policies apply.

4.2 Session Management. Browser sessions use signed JSON Web Tokens (JWT) transmitted over secure, HttpOnly cookies with SameSite and Secure flags. Token signatures are validated on each authenticated request.

4.3 Authorization Model. ProcessMind does not depend on API Gateway native authorizers for its core application APIs. Authorization is enforced in shared Lambda handler wrappers that validate session state and tenant scope before business logic runs. Public routes are explicitly allowlisted for non-authenticated flows, webhooks, event ingestion, and CORS preflight. External API endpoints use dedicated authentication handlers. Access to Customer Data is scoped to the authenticated tenant or organization context.

4.4 Least Privilege. Internal systems follow the principle of least privilege. IAM roles are scoped to the minimum resources required where the framework permits precise scoping. Some SST/CDK-generated roles use broader managed or inline policies for bindings and runtime operation; these cases are reviewed, resource-scoped where possible, and tracked as explicit exceptions.

4.5 Employee Access Controls. Employee access to internal systems is managed through Active Directory with SSO and mandatory MFA. Role-based access control (RBAC) ensures that access to Customer Data is limited to authorized personnel on a need-to-know basis. Access rights are reviewed periodically.

5. Logging, Monitoring, and Audit

5.1 Centralized Logging. HTTP API access logging and WebSocket access logging are enabled with structured JSON fields and written to Amazon CloudWatch Logs with one (1) week retention. Those access log groups are encrypted with a customer-managed AWS KMS key. Application logs are centralized in Amazon CloudWatch log groups encrypted with a customer-managed AWS KMS key and retained for ten (10) years. Separate audit and telemetry log groups are also encrypted with a customer-managed AWS KMS key and retained for ten (10) years. The Aurora PostgreSQL engine log export group is retained for one (1) week.

5.2 What Is Logged and What Is Not. ProcessMind logs HTTP API and WebSocket access events, including request time, request identifiers, route or path, response status, latency, source IP, and user agent. ProcessMind also logs authentication events, asynchronous failure paths, and supporting Lambda application activity to centralized CloudWatch log groups. VPC flow logs are enabled. ProcessMind does not currently enable CloudFront standard access logging on the website, frontend SPA, or public resources distributions.

5.3 Monitoring and Alerting. CloudWatch alarms and dashboards monitor system health, dead-letter queues, and security-relevant failures. Asynchronous processing failures route to encrypted dead-letter queues (fourteen (14) day retention; two (2) days for the thumbnail and search-index queues), and DLQ alarms trigger SNS notifications for investigation. In addition, ProcessMind uses Sentry for real-time frontend error tracking, performance monitoring, and session replay. Session replays are recorded only for sessions in which an error occurs, and text, form inputs and media are masked or blocked in replays. Sentry data is ingested in the EU (Frankfurt) and is limited to ProcessMind Usage Data (browser errors, performance traces, device metadata and masked replay recordings). Sentry is listed in the sub-processor list.

5.4 Log Protection. Logs are stored in dedicated, access-controlled CloudWatch log groups and encrypted at rest. Production and development logs are separated by environment and account boundaries.

6. Automated Control Validation and Vulnerability Management

6.1 What ProcessMind Does. ProcessMind runs cdk-nag as part of its infrastructure synthesis and deployment workflow using multiple industry rule packs (including AWS Solutions, NIST 800-53 and PCI DSS). Per-stack reports are generated and reviewed as part of infrastructure change management. Findings are triaged as fixed, accepted risk or planned improvement.

6.2 How Exceptions Are Managed. Suppressions are recorded in a central registry where the framework allows, scoped to the affected stacks, and require written justification; where a stack contains an inline suppression, it is documented alongside that stack. When a finding is remediated, the corresponding suppression is updated or removed. ProcessMind does not treat suppression as a blanket opt-out from review.

6.3 What ProcessMind Does Not Currently Do. ProcessMind tracks and reviews material infrastructure-control exceptions. The main ones are:

  • application Lambdas are not placed inside the VPC by default; they reach Aurora through the RDS Data API over TLS with IAM and Secrets Manager authentication
  • the WebSocket API and static distributions are not behind AWS WAF (WebSocket connections use short-lived HMAC tokens; payment-related geo restrictions are enforced in the payment system), and static distributions do not have CloudFront standard access logging
  • database recovery relies on Aurora automated backups and point-in-time recovery rather than a separate AWS Backup plan or Aurora Enhanced Monitoring
  • there is no cross-region S3 replication or S3 Object Lock for mutable buckets
  • some AWS/CDK/SST-managed supporting resources use AWS-managed encryption or broader generated IAM policies where the service does not expose a customer-controlled alternative

The complete suppression registry is maintained alongside the infrastructure code and is available on request. Use of cdk-nag rule packs is engineering control validation, not an external certification, audit opinion, or legal attestation of HIPAA, NIST, or PCI DSS compliance.

6.4 Dependency Management. Software dependencies are monitored continuously for known vulnerabilities. Critical and high-severity vulnerabilities are patched with a target of seven (7) days. Dependencies are updated on a regular cycle.

6.5 Secure Software Development Lifecycle (SDLC). ProcessMind follows a defense-in-depth approach to software development. Every change to production must pass through multiple independent automated validation layers before deployment:

  • Static analysis and type safety: TypeScript strict mode and ESLint enforce type correctness, null safety, and security-relevant coding patterns at compile time.
  • AI-assisted code review: AI-assisted analysis provides an additional review perspective on pull requests to identify security risks, logic errors, and convention deviations, supplementing automated testing.
  • Unit and integration tests: a comprehensive Vitest test suite validates business logic, data access patterns, API behavior, and error handling against live AWS resources in the development environment.
  • End-to-end tests: Playwright-based browser tests verify critical user workflows including authentication, data upload, process modeling, simulation, and multi-tenant isolation.
  • Infrastructure compliance scanning: cdk-nag validates infrastructure-as-code against multiple compliance frameworks on every change.
  • Dependency vulnerability scanning: automated dependency audits block known critical and high-severity vulnerabilities from reaching production.

Human review is focused on architecture, security boundaries, and design-level decisions rather than line-level code inspection. Where structural, security-sensitive, or infrastructure changes are involved, explicit human sign-off is required in addition to automated validation.

All validation layers are enforced through CI as required merge gates for changes to the main branch. Emergency production fixes may bypass the CI gate but must be followed up with a full pipeline run and post-incident review within twenty-four (24) hours.

7. Backup and Disaster Recovery

7.1 Automated Backups. Amazon Aurora performs continuous, automated backups with a retention period of seven (7) days. Backups are encrypted using the same customer-managed KMS keys as the source databases.

7.2 Point-in-Time Recovery. Aurora supports point-in-time recovery to any second within the backup retention window, enabling rapid restoration in case of data corruption or accidental deletion.

7.3 S3 Durability and Versioning. File uploads and operational artifacts are stored in Amazon S3, which provides 99.999999999% (11 nines) durability. Versioning is enabled on the uploads bucket and resource buckets to support recovery and rollbacks. Website and frontend deployment buckets are reproducible build artifacts and are not treated as a backup system. ProcessMind does not currently enable cross-region S3 replication.

7.4 Business Continuity. Disaster recovery procedures are documented and tested periodically. A summary is available in the Disaster Recovery, Business Continuity & Incident Response document. The architecture relies on AWS managed services within the eu-central-1 region, which AWS operates across multiple Availability Zones; the Aurora cluster currently runs a single writer instance, so database recovery relies on automated backups and point-in-time recovery rather than an in-region standby. Aurora backups, S3 durability, dead-letter queues, and rebuild-from-source static assets are part of the recovery strategy.

8. Incident Response

8.1 Incident Notification. In the event of a Security Incident (as defined in the DPA), ProcessMind will notify affected customers without undue delay, and where feasible, within seventy-two (72) hours of becoming aware of the incident.

8.2 Incident Handling. ProcessMind maintains documented incident response procedures covering identification, containment, eradication, recovery, and post-incident review. A summary is available in the Disaster Recovery, Business Continuity & Incident Response document. Lessons learned from incidents are incorporated into security controls and processes.

8.3 Communication. Incident notifications include the nature and scope of the incident, data categories affected, measures taken to contain the incident, and recommended actions for the customer.

9. Organizational Measures

9.1. Information Security Management. ProcessMind maintains an information security management system aligned with ISO 27001 principles. ProcessMind has selected its certification path for ISO 27001 certification and SOC 2 Type II attestation; the formal certification process has not started yet.

9.2 Security Awareness. All personnel with access to Customer Data receive security awareness training. Security best practices are embedded in onboarding, development workflows, and operational procedures.

9.3 Vendor and Sub-processor Management. Sub-processors are contractually bound to data protection standards equivalent to those described in this document. ProcessMind maintains a public sub-processor list and provides at least thirty (30) days’ notice before engaging a new sub-processor. Sub-processors are reviewed annually for compliance.

9.4 Confidentiality. All personnel authorized to process Customer Data are bound by written confidentiality obligations.

10. Compliance and Certifications

Framework / Standard Status
GDPR (EU General Data Protection Regulation) Compliant
EU Data Residency (Frankfurt, Germany) Enforced
AWS Infrastructure Certifications (ISO 27001, SOC 2, PCI DSS) Inherited via AWS
ISO 27001 (ProcessMind) Planned — certification path selected; formal process not yet started
SOC 2 Type II (ProcessMind) Planned — certification path selected; formal process not yet started
Automated infrastructure control validation (cdk-nag across AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless) Implemented as engineering control validation, not a certification
Standard Contractual Clauses (SCCs) for international transfers Implemented (see DPA)
Data Processing Addendum (DPA) Publicly available

Use of cdk-nag rule packs does not mean ProcessMind is formally certified or independently audited against HIPAA, NIST, or PCI DSS. Those rule packs are used as engineering guardrails to validate infrastructure design and to track gaps explicitly.

For questions regarding security, compliance, or to request documentation such as audit reports or completed security questionnaires, contact support@processmind.com.