Technical and Organisational Measures
This document describes the technical and organisational measures under Article 32 GDPR with which we operate the Eigentum² platform. They apply to processing on behalf of our customers under the Data Processing Agreement and to our own processing under the Privacy Policy. The providers whose infrastructure we use are named in the "Recipients and Subprocessors" register.
1. Encryption and Pseudonymisation (Article 32(1)(a) GDPR)
- All connections to the platform and between its services are encrypted with state-of-the-art TLS. Browsers are instructed to access the platform over encrypted connections only.
- The database, file storage and backups are encrypted at rest by the infrastructure providers.
- Passwords are stored only as salted hashes using a state-of-the-art algorithm.
- Two-factor authentication secrets and recovery codes are stored encrypted; identifiers from confirmation and reset links are stored only as hashes.
- Operational logs mask or pseudonymise email addresses and other contact and device data.
2. Confidentiality (Article 32(1)(b) GDPR)
Physical access control
- We operate no data centre of our own. The application and the database run in data centres of our hosting providers in the EU (Frankfurt), whose physical security is evidenced by ISO 27001 and SOC 2 Type II certifications. The register states the location and safeguard of every recipient, including the file storage.
System access control
- Sign-in with email address and password, possible only after the email address is confirmed, or with a Google account.
- Optional two-factor authentication with time-based one-time codes and single-use recovery codes; it also applies to sign-in with Google.
- Sessions are held in secured cookies, expire automatically and can be revoked by the user individually or all at once. Resetting the password ends all sessions.
- Sign-in, registration, password reset and the functions available without sign-in are limited against automated mass requests.
Data access control
- Role-based permission model with fine-grained permissions, enforced server-side on every operation. Roles receive only the permissions they need.
- The customer manages the roles and permissions of its own organisation.
- Access to production systems is limited to the persons who need it to operate the platform; they are bound to confidentiality and trained in data protection.
Separation control
- Each organisation's data is logically separated; every query is restricted server-side to the organisation of the requesting user.
- Production, test and development environments are separate and use their own databases. Non-production environments contain no production data and are not publicly accessible.
3. Integrity (Article 32(1)(b) GDPR)
Transfer control
- Documents and images are delivered only after a server-side permission check, through time-limited signed access; stored objects are not publicly readable.
- Uploaded files are limited by size and file type and stored in an area assigned to the user.
- Security headers, including a Content Security Policy, restrict which content the browser may load and embed.
- Incoming notifications from service providers and scheduled tasks are checked for authenticity before they are processed.
Input control
- Changes to records of evidential relevance and legally relevant declarations are logged with time and acting person. The change and access logs are protected against later modification.
- Write operations by platform staff and read access to borrower data are logged.
- All input is validated server-side against defined schemas; non-conforming data is rejected before it is stored.
4. Availability and Resilience (Article 32(1)(b) GDPR)
- Operation on managed, scaling infrastructure in certified data centres.
- Automatic database backups by the database provider.
- Recurring background tasks are monitored; failures are reported daily and dealt with.
5. Restoration (Article 32(1)(c) GDPR)
- The database can be restored to an earlier point in time.
- The application, the database schema and the deployment processes are version-controlled and deployed automatically, so the application can be rebuilt reproducibly.
- Deleted records remain restorable for 90 days; their permanent erasure is governed by Section 6.
6. Deletion and Retention
- Deleted records are withdrawn from use immediately and permanently erased automatically once the periods expire, including the associated files. The periods are set out in § 13 of the Data Processing Agreement; for our own processing, in the Privacy Policy.
- Personal details in records of proof, such as IP addresses, are removed or truncated after fixed periods or together with the account.
- A retention hold for an individual organisation is possible only where Union or Member State law requires storage.
7. Handling of Security Incidents
- Personal data breaches are assessed, contained and documented (Article 33(5) GDPR).
- Customers are informed under § 11 of the Data Processing Agreement without undue delay and in any event within 48 hours.
8. Regular Testing, Assessment and Evaluation (Article 32(1)(d) GDPR)
- Every change to the application passes automated checks before deployment, including tests of the permission checks; the production environment is updated only after the checks have passed in the test environment.
- These measures are reviewed on material changes to the platform and at least annually.
- Sub-processors are checked before engagement and regularly afterwards for their guarantees and the basis of transfers outside the EEA. A contract under Article 28(4) GDPR is in place with each of them.
- Data protection by default (Article 25(2) GDPR): statistics and advertising are off without consent; their scope and placement are described in the Privacy Policy.
Changes to these measures are governed by § 7(3) of the Data Processing Agreement. We provide earlier versions on request in text form.
The effective date of this version is displayed above this document.