Technical and Organisational Measures (TOM)

pursuant to Art. 32 GDPR — Annex 2 to the Data Processing Agreement

roleALPHA GmbH, Aschergasse 34, 1130 Vienna

Language note: This is a translation for information purposes. In the event of any discrepancy, the German version prevails.

Version applicable at the time. This document is published at
https://rolealpha.com/en/legal/security-measures and is updated as the product evolves; the
level of protection is not reduced in doing so (section 4 of the DPA). Such an update is not an
amendment to the contract.

0. Scope and delimitation

This document describes the measures implemented by roleALPHA GmbH for the security of processing under Art. 32 GDPR. It is Annex 2 to the Data Processing Agreement.

roleALPHA operates the Core in all models; the Customer decides where the Data Nodes run. The measures of the application software (sections 1 to 7) are the responsibility of roleALPHA in every model, as are the operation and protection of the Core. Operation, physical security, network, disk encryption and backups of the Data Nodes rest with roleALPHA in M1, with the Customer in M2 and with its third-party host in M3. In M2 and M3 roleALPHA supplies the software with the protective functions described here; securing its operating environment is for the Customer. Section 8 summarises the split in tabular form.

1. Access and permissions

Physical access. Operation takes place in the data centre of a professional provider with the physical protection customary in the industry (access control, video surveillance, uninterruptible power supply, fire protection, air conditioning): netcup GmbH, Emmy-Noether-Strasse 10, 76131 Karlsruhe, Germany; data centre location Vienna, Austria. Certifications of the host: ⟨TODO: e.g. ISO/IEC 27001 — to be added with evidence⟩. roleALPHA does not operate its own server rooms. Access to business premises is limited to authorised persons; mobile devices are encrypted and screen-locked.

Authentication. Users sign in with a one-time code sent to their sign-in address, with a passkey, or through the Customer's identity provider. New accounts receive no password; no user names or initial passwords are generated, displayed or sent. The server accepts password sign-in solely from platform administrators of roleALPHA GmbH for platform administration; for the Customer's accounts this route has been closed since October 2026 — enforced on the server, independently of the user interface. Passwords are stored solely as a bcrypt hash with salt, never in clear text and without recoverability. If an account belongs to several tenants, a tenant administrator can change neither its sign-in address nor its sign-in methods; deactivation only takes effect in their own tenant, and a deactivated membership cannot be continued by renewing a running session either. Every session records its sign-in method; switching to another tenant — including via the central sign-in domain — succeeds without signing in again only if that tenant permits the method, and a sign-in through a tenant's identity provider applies to that tenant alone. Optionally a time-based one-time password (TOTP) is added, whose secret is stored encrypted. Phishing-resistant are passkeys under FIDO2/WebAuthn: the private key does not leave the device, only the public key is stored; the credential is cryptographically bound to the origin and is not even offered by the device on look-alike sites. User verification on the device is required (userVerification: required); a signature counter detects cloned keys, and biometric features are checked exclusively by the device. Alternatively the Customer's identity provider is connected via OpenID Connect; authentication then takes place at the Customer.

Sessions and tokens. Access tokens are stateless, signed JWTs (RS256) with limited validity and are renewed through a separate procedure. They are signed with the private key of the respective tenant and verified only against the corresponding public key set (JWKS) — a token of another tenant is rejected. External applications are connected exclusively via OAuth 2.1 with PKCE; the access granted is bound to one person, one tenant and one target address. The tokens issued carry their own use marker and are rejected on the application's sign-in paths; they cannot replace a browser session. Refresh tokens are rotated; re-presenting a spent token is treated as theft and revokes the entire chain; only hash values are stored. Revocation takes effect immediately, including on running connections.

Abuse prevention. Sign-in attempts are limited to 10 per 15 minutes per IP address, requests in general to 100 per 60 seconds, AI endpoints to 60 per 60 seconds; from 60 requests per minute a progressive delay applies in addition.

Permissions. Access control is role-based in the Module:Action scheme and is evaluated centrally at one checkpoint in the code; roles can be defined per tenant. Every domain object additionally carries a visibility classification, filtered server-side and authoritatively via the Core, not in the client. Platform administration, tenant administration and domain roles are separated; a special role for visibility review receives no access to administration functions. Services receive only the access required for their task, and service-to-service calls are authorised via a separate internal secret. Depending on the Customer's configuration, changes may take effect only after approval. Platform administration is a separate application with its own sign-in and its own token; access to operating systems runs exclusively via key procedures whose secrets are stored encrypted and managed write-only. Within roleALPHA, permissions are granted on a documented basis, reviewed regularly and withdrawn immediately on departure; elevated rights are granted under the four-eyes principle.

2. Tenant separation and access protection

Tenant separation is a load-bearing design principle. Every record is assigned to a tenant, and all queries are restricted to the tenant of the signed-in user. Added to this is data sovereignty per Data Node: each Data Node manages only its own tables, the Core queries domain data only through its interface, and conversely Data Nodes do not access Core tables. Both are secured by automated architecture tests in the development process. The separation also works cryptographically, because access tokens are signed per tenant (section 1). Separate databases are possible per deployment and are used for customer domains and in M2 and M3. Test and production environments are separated; no production data of customers are used in test environments. On the shared site rA Cloud (DPA Annex 1.2), Data Nodes of several Customers run side by side. There a Data Node is not bound to a single realm: it determines the realm per request from the key identifier of the access token and verifies the signature against the public key of that realm — like the additional Core nodes (cells). Tenant separation remains the same as on any other site: every query is restricted to the tenant of the token, and a token without a valid signature is rejected.

Pseudonymisation. For interaction signals, actors are stored solely as SHA-256(tenant identifier + ":" + external user identifier) — no clear name, no individual events, only aggregated weights per actor pair and time window, maximum retention 90 days. A mapping to a person occurs only where the Customer expressly sets it up. In the usage statistics, tenant, realm and person identifiers leave the browser exclusively as a salted SHA-256 hash; the statistics are cookieless and respect "Do Not Track".

Data protection by design and by default (Art. 25 GDPR). AI functions cannot be used without configuration, and the release of data is fail-closed by default. Interaction signals are off by default and are technically limited to pseudonymous, aggregated metadata with an enforced maximum retention. The Core holds no domain content, only metadata. The application sets no cookies and embeds no third-party tracking. The Customer can shorten the retention periods for logs, drafts, chat histories and attachments itself. The suitability check of a process log evaluates the sample submitted exclusively in memory; four personal process types (application, health, disciplinary, whistleblowing and complaints) are technically blocked as a source and cannot be deselected. Export and deletion are product functions, not special services.

3. Encryption

External connections run exclusively over TLS 1.2 and 1.3 with strong cipher suites; unencrypted calls are redirected, and certificates are issued and renewed automatically. Service-to-service communication takes place within protected network segments; externally reachable endpoints are available only over TLS.

Secrets in the database are stored with AES-256-GCM envelope encryption: API access keys for AI providers, credentials of connectors and signal sources, TOTP secrets, SSH credentials of deployment targets and the credentials of e-mail dispatch — of the platform and of individual tenants' own dispatch paths. The master key is supplied through a separate environment variable and is not part of the database; a documented procedure exists for rotating the encryption keys. Each tenant has an RSA key pair; private keys are stored encrypted, public keys are served through a JWKS endpoint. Work devices are fully disk-encrypted. Encryption of the storage media at the host level: ⟨TODO: to be confirmed by the host⟩.

4. Availability and recovery

The databases are backed up regularly; cycle: ⟨TODO: backup cycle in production⟩. Backups are deleted or overwritten at the latest 90 days after the data concerned have been deleted from the active systems (section 7 of the DPA). In addition there is an application-side backup and restore procedure per tenant across all Data Nodes, with checksum verification of the restored data volumes. The file produced is stored encrypted (AES-256-GCM with an integrity seal); the key is generated afresh for each operation and held exclusively in memory — it is not derived, not stored and not output. A file left behind after a crash is therefore no longer readable and is removed at the next start; after download the file is deleted immediately. Restores are actually performed regularly as part of the automated test runs, not merely planned.

The services are monitored with health checks and alerting; operational metrics are collected. An additional watchdog at operating system level outside the container failure domain detects hung or failed services and restarts them; this measure presupposes that the operating system level of the Data Node is delivered along with it. If the Data Node is delivered into a container orchestration operated by the Customer, it does not apply and is replaced by that orchestration's restart and health mechanisms, for which the Customer is responsible. Against overload there are rate limiting, progressive delay, request size limits (50 MB at the reverse proxy, 25 MB in the application) and timeouts on outgoing calls. All services set security headers (among others against clickjacking, MIME sniffing and referrer leakage). Infrastructure services such as the database and the message bus are not reachable from outside; only the reverse proxy is publicly exposed. For malfunctions there is a defined process of reporting, prioritisation, remediation and feedback to affected customers, together with documented recovery procedures that are regularly exercised by the automated restore checks.

5. Integrity and logging

Input control. Creation, modification and deletion of objects are logged with the acting person, timestamp, object, action and — for changes — the changed field values; authorised users of the Customer can inspect the logs. Retention is 365 days by default and configurable per tenant; it is enforced by automated deletion runs whose execution is itself logged. Operational logs are collected centrally in structured form with severity levels and retained for 30 days. Program errors are collected by a self-operated error tracker (GlitchTip) — open source, in its own network with its own database and its own database role, without the involvement of a service provider; retention 30 days, fixed platform-wide.

Changes by roleALPHA on the Customer's behalf. When authorised staff of roleALPHA change configurations in the Customer's tenant on the Customer's instruction (Data Nodes, AI settings, company and billing data), the platform requires a reason (5 to 500 characters) at one central checkpoint and rejects the change without it. Reason, acting person and operation are recorded in the tenant's audit trail and are visible to the Customer. A tenant administrator of the Customer cannot pose as roleALPHA: the note is only set for accounts with the platform administrator role. An automated test ensures that every affected write path passes this checkpoint and logs the reason.

Transfer control. The release for AI services is fail-closed by default: without an express release per data area by the Customer, the AI receives no access to entity and vector data, and an empty release list means no access. The check is performed centrally at one point in the code and is secured by automated tests. Provider and model are configured per tenant; the Customer can supply its own provider access, so that no contractual relationship exists between roleALPHA and the provider. Service-to-service calls are authorised via an internal secret known only server-side; the origin check (CORS) is derived dynamically from the configuration and not opened wholesale. Credentials of external data sources are stored encrypted, and connections are established only with the access supplied by the Customer. Exports are possible only for authorised users and are logged.

roleALPHA does not fetch linked documents itself — no server-side intermediate retrieval, no caching, no external viewer service; only the http and https protocols are linked, other address types are rendered as text. The preview runs in a sandboxed frame (sandbox) and only with the rights the source system grants the user. Screenshots and page exports of the feedback function are shown to the user for review and editing before sending; the target repository is not publicly accessible. Browser error reports do not go directly to the error tracker but through our own server; there one checkpoint redacts before forwarding: form contents, the text of clicked elements, query parts of addresses, request bodies, cookies and headers do not leave, and values matching secret patterns are masked. A report that cannot be parsed is rejected, not passed through; session replay and per-user performance measurement are not enabled. roleALPHA operates no storage media of its own in production; their disposal is for the host under its certified procedures.

6. Deletion

Deletions are logged; deleting without a trace in the audit trail is not provided for. The retention periods for logs, drafts, chat histories and attachments are configurable per tenant and can be shortened by the Customer; they are enforced by automated deletion runs. After the end of the contract the periods in section 7 of the DPA apply: deletion from the active systems within 30 days, backups at the latest after 90 days, and no ongoing access to the backups in the meantime. Deletions already carried out are applied again after a restore before the data are used productively. An automated test ensures that every new tenant-related table is included in backup, restore and deletion; tables deliberately retained must be identified with reasons. In M2 and M3 the Customer is responsible for deletion on its own infrastructure; roleALPHA assists it.

7. Organisation and effectiveness review

Commitment and responsibility. All employees and contractors are committed in writing to confidentiality and to compliance with data protection; the commitment survives the end of the engagement. A data protection officer is appointed (contact see Privacy Policy, section 1). Employees receive regular instruction on data protection and information security. The record of processing activities is maintained under Art. 30(1) and (2) GDPR. Development, operations and platform administration are separated by role. Remote maintenance is purpose-bound, logged and uses encrypted credentials; in M2 and M3 only with access supplied by the Customer.

Procedure for personal data breaches. A documented process with assessment, notification to the Customer within 48 hours, notification to the supervisory authority within 72 hours (in so far as roleALPHA is the controller), documentation and follow-up.

Control of processors. Subprocessors are selected only after a review of their suitability and protective measures; a contract under Art. 28 GDPR with substantially the same obligations is concluded with each. Where a third country is involved, a permissible transfer mechanism is ensured (adequacy decision or standard contractual clauses) together with an assessment of the transfer circumstances. The list of subprocessors is maintained and versioned; changes are notified to customers with 14 days' prior notice, within which they may object. There are reviews as circumstances require and a right of termination in the event of breaches.

Effectiveness review. Every change to the software passes through a staged, mandatory review procedure: before every commit to version control, static type checking as well as unit and component tests; before every release to production, a full test run including integration and end-to-end interface tests against a real database and a real message bus; continuously in the build environment, linting, tests and build verification of all packages. Architecture tests automatically enforce the data sovereignty of the Data Nodes, the completeness of the deletion and restore paths and the wiring of security switches — a violation aborts the run. Dependencies are checked for known vulnerabilities with a defined remediation process; changes to security-relevant paths undergo a security-focused code review. Every change passes a code review, and releases are made exclusively from the build environment, not manually. This catalogue of measures is reviewed at least annually and as circumstances require in the event of material changes.

8. Responsibility matrix per operating model

The matrix applies per Data Node: which model applies follows from the site the Customer has chosen for that Data Node in the platform. A Customer may mix models.

Area of measures	M1	M2	M3
Authentication, permissions, tenant separation (software)	roleALPHA	roleALPHA	roleALPHA
Encryption of secrets in the application	roleALPHA	roleALPHA	roleALPHA
Logging and audit trail (function)	roleALPHA	roleALPHA	roleALPHA
TLS termination of the Core	roleALPHA	roleALPHA	roleALPHA
TLS termination of the Data Nodes	roleALPHA	Customer	Customer's third-party host
Physical and network security of the Data Nodes	roleALPHA	Customer	Customer's third-party host
Disk encryption of the Data Nodes	roleALPHA (via host)	Customer	Customer's third-party host
Backups and restoration of the domain content	roleALPHA	Customer	Customer
Applying updates to the Data Nodes	roleALPHA	Customer (with support from roleALPHA)	Customer
Monitoring the availability of the Data Nodes	roleALPHA	Customer	Customer

Effect of the delivery form (M2, M3). How the last two rows are met in practice additionally depends on the form in which the Data Node is delivered. If the provider delivers the operating system level as well (server or container package), it brings tools that apply updates automatically and additionally monitor operation; the Customer then supplies the infrastructure. If, on the other hand, the Data Node is delivered into a container orchestration operated by the Customer, those tools do not exist: applying updates and monitoring availability then rest entirely with the Customer. The provider indicates the expected version and makes it available for retrieval; it does not apply it.

9. Details still to be completed

The following points are to be completed before release to customers; they depend on the production environment and cannot be derived from the software:

⟨TODO: certifications of the host (e.g. ISO/IEC 27001) and evidence⟩
⟨TODO: confirmation of disk encryption by the host⟩
⟨TODO: backup cycle in production⟩
⟨TODO: recovery time and recovery point objectives (RTO/RPO), if promised⟩
⟨TODO: name and contact of the data protection officer⟩

Deutsche Fassung (maßgeblich): Technisch-organisatorische Maßnahmen