Trust at ProcessEngineer.io
We sell to chemical-plant operators, refiners, and engineering houses where supply-chain security is regulated. This page documents how we handle your data, how we align with NIS2, and what we will share on request. Last reviewed 2026-05-05.
NIS2 alignment
We are not directly in NIS2 scope as a small Dutch BV, but most of our customers are. Article 21's supply-chain security clause makes our control set part of yours. Below is how we map to each of the ten minimum measures. We claim alignment, not certification.
- Article 21(2)(a)Risk analysis and information security policy
- We maintain a written information security policy reviewed at least annually. Risk assessments cover data flows, third parties, and deployment topology per engagement.
- Article 21(2)(b)Incident handling
- Documented playbook covering detection, triage, containment, and customer notification. Our commitment to customers in NIS2 scope: 24-hour early-warning notification and 72-hour incident notification, aligned with NIS2 reporting timelines.
- Article 21(2)(c)Business continuity and crisis management
- Backup and recovery procedures for each customer environment, validated on a defined cadence per engagement. Crisis communication contacts named at kickoff.
- Article 21(2)(d)Supply chain security
- Subprocessor list is published below and updated when changes occur. We assess each subprocessor's security posture before adoption and re-evaluate at least annually.
- Article 21(2)(e)Secure development, acquisition, and maintenance
- Secure SDLC with code review on every change, dependency scanning, vulnerability disclosure channel (info@processengineer.io), and a documented patching cadence for production systems.
- Article 21(2)(f)Effectiveness assessment
- Internal review of control effectiveness on a defined cadence. Independent penetration test scoping is in progress; cadence and scope will be added here once the first engagement is complete.
- Article 21(2)(g)Cyber hygiene and training
- All personnel complete onboarding training covering phishing, credential hygiene, and incident reporting. Refresher training annually.
- Article 21(2)(h)Cryptography and encryption
- TLS 1.2 or higher for data in transit. Encryption at rest for stored customer data using provider-managed keys (default) or customer-managed keys (on request, on-prem deployments).
- Article 21(2)(i)Access control and asset management
- Least-privilege access, named accounts, no shared credentials, MFA on all administrative interfaces. Customer environments are isolated per tenant; no shared production data planes.
- Article 21(2)(j)Multi-factor authentication and secured communications
- MFA enforced on all internal accounts and customer-facing administrative endpoints. Customer communications routed through encrypted channels.
Data residency and deployment topology
Default deployment for SaaS customers is EU-hosted (Netherlands or Frankfurt regions, depending on provider). For customers with stricter requirements, we deploy on-premise or inside the customer's own private cloud account; in those cases, no production data leaves the customer environment.
The deployment architecture is scoped during discovery so it matches your actual compliance posture. We do not promise an architecture before we know which regulatory regimes apply to your data.
Subprocessors
These are the third parties that may process customer data on our behalf. Marketing site analytics and error tracking are not in this list because they do not touch customer data. We notify customers in advance of any change to this list.
| Subprocessor | Purpose | Region |
|---|---|---|
| Vercel | Application hosting and request routing for the marketing site and product surfaces. | EU |
| Supabase | Database and private file storage for customer uploads and processed outputs. | EU |
| Mistral | LLM inference for document understanding and generation. | EU |
Data retention
- Customer-uploaded source documents (P&IDs, historian extracts)
- Deleted immediately after processing. No source file is stored unless explicitly requested otherwise.
- Processed outputs (HAZID and HAZOP worksheets, P&ID findings, RFQ datasheets, stream lists, Luma reports)
- Retained while the engagement is active. Returned and deleted on engagement close.
- Operational logs (access, audit, error)
- Retained 12 months for incident investigation, then purged.
- Customer-trained models or fine-tunes
- Not applicable. We do not fine-tune on customer data by default. RAG indexes are scoped per customer environment and deleted with the engagement.
Incident response timeline
We commit to a 24-hour early-warning notification and a 72-hour incident notification to affected customers, aligned with NIS2 reporting timelines. The early warning describes what we know and what we are investigating; the 72-hour notification adds impact assessment and remediation status.
Final incident reports are delivered within one month and include root cause, scope, customer impact, and corrective actions taken.
Documents available on request
These documents are released under NDA to qualified procurement contacts.
- Sample DPA (data processing agreement)
- Sample mutual NDA
- Subprocessor change-notification policy
- Most recent penetration test executive summary, once available
Request via info@processengineer.io.
Procurement and security questions
For procurement questionnaires, DPA review, or security-architecture questions, write to info@processengineer.io. Responses target two business days.