Technical and Organisational Measures (TOMs)

Servers, database and file storage are in the EU. One service is based in the USA and receives only the data for its function:

• Application servers and PostgreSQL database: Hetzner Online GmbH, data centre Falkenstein/Nuremberg, Germany
• Storage of uploaded evidence documents: AWS S3, EU region
• In the USA: Resend, which sends our emails. The transfer is based on the EU standard contractual clauses (Art. 46 GDPR).

• Transport encryption: TLS for all connections to the platform (HTTPS)
• Encryption at rest: AWS S3 server-side encryption (AES256, set explicitly on every upload, including archived invoices). The application does not additionally encrypt the PostgreSQL database.
• Credentials and API keys are managed via server environment variables, not stored in source or databases

Measures ensuring confidentiality:

• Physical access control: data centres of the hosting providers (Hetzner, AWS) hold ISO 27001 certifications
• Personnel measures: access to production systems and personal data is limited to a small, named group bound by confidentiality. Access follows the principle of least privilege and is revoked when a role ends.
• Authentication: sign-in by email and password or through Google OAuth 2.0. Passwords are stored only as a bcrypt hash at cost factor 12, never in clear text. Password registrations confirm the email address once through a one-time code. Sign-in attempts are limited to 10 in 15 minutes per email address and application instance; every attempt counts. Sessions end after eight hours. The platform offers no second factor on the password path. Users who sign in with Google rely on the MFA of their own Google account.
• Role-based permissions: admin, reviewer, legal reviewer, member; enforced in the application layer via tRPC middleware
• Multi-tenant isolation in the application: every data-bearing query filters on the company ID from the authenticated user's session. There is no additional separation in the database (row level security).
• Passwords are never stored in clear text. Every sign-in is compared against a bcrypt hash, including when no account exists for the address supplied, so that response time cannot reveal who is registered.

• Input control: every change a signed-in user makes through the platform's API is logged with user ID, action, entity type, timestamp, IP address, user agent and the input values (sensitive fields removed). Only selected operations also store the previous value.
• Audit trail checksum: every audit row gets a SHA-256 checksum over its contents when it is written. A tool that recomputes these checksums later does not exist yet.
• Transfer control: data transmission only via TLS; all authenticated endpoints require a valid session
• Evidence documents: storage location and metadata are written on upload; an optional client-supplied SHA-256 hash can be stored alongside the file
• Sign-off mechanism: at the moment of approval, the requirement state is snapshotted into a sign-off history table whose entries form a SHA-256 chain (each entry's checksum covers the previous one) - tampering with the history is detectable end-to-end

• Database backups are set up by the operator in the hosting environment. They are not part of the source code. We share the current configuration on request.
• Storage of evidence documents in AWS S3 with the object durability guarantees provided by AWS
• Rate limiting (counted in the database, so it holds across restarts and every application instance; IP addresses and email addresses are stored only as a hash) on login attempts, public endpoints (applicability check, supplier portal), and resource-heavy authenticated endpoints (PDF exports, certificate generation)
• Uploaded files are limited to 50 MB per file
• Availability display: nisd2.eu/status checks database reachability at most every 30 seconds and shows the result publicly. We do not run continuous monitoring with automated alerting.

• These TOMs are reviewed when triggered by an event and at least once per year
• Dependency updates: Dependabot proposes new versions of the npm packages and GitHub Actions as pull requests every week
• Reporting obligations: personal data breaches will be reported to the competent supervisory authority within 72 hours per Art. 33 GDPR
• Development practice: code changes go through pull requests; TypeScript strict-mode type checks are enforced; targeted automated tests cover security-critical logic (e.g. applicability classification)

All sub-processors are bound by Art. 28 GDPR contracts. The full list is in the DPA document.

See full sub-processor list (DPA)

Questions about these TOMs or our data processing should be sent to:

contact@nisd2.eu