Technical and Organizational Measures (TOM)

1. Confidentiality (Art. 32(1)(b) GDPR)

1.1 Physical access control

The Provider does not operate its own data center. Processing takes place exclusively at certified cloud operators (Vercel – application compute in the Frankfurt am Main region, delivery via a global CDN; Supabase – eu-central-1, Frankfurt am Main), which ensure physical access security through ISO 27001 / SOC 2 certified data centers. The workplaces of SSIG-IT GmbH are protected by building and room access controls.

1.2 System access control

Authentication takes place exclusively via Microsoft Entra (MSAL); the Provider stores no passwords of its own. Access tokens are verified server-side for their RS256 signature and validated against a fixed allowlist of client identifiers and the permission scope “access_as_user”. Administrative access exists only for persons from the SSIG-IT GmbH tenant registered by object ID (oid). Enforcement of multi-factor authentication is handled by the policies (Conditional Access) of the respective Microsoft Entra tenant and lies within its responsibility; multi-factor authentication is enabled for SSIG-IT GmbH’s own tenant.

1.3 Data access control

Row-level security without any permissive policy is enabled on all database tables – access is possible exclusively via the server-side service role. The service role key technically never reaches the browser’s client bundle. Write operations of the customer portal are validated against the respective target tenant identifier; the client receives no database key. Every administrative write mutation is recorded in an audit log.

1.4 Separation control

Tenant separation via the tenant identifier on every record; separate authentication instances for customer portal, administration, and trial; strictly separated development and production environments with their own databases.

1.5 Pseudonymization and data minimization

Presence, profile, photo, and name data from Microsoft Graph are never stored server-side but are processed exclusively transiently in the browser. Onboarding binding attempts store a SHA-256 hash instead of the raw tenant identifier; usage telemetry consists exclusively of aggregated counters without personal reference; the consent proof relies on a server-side secret.

2. Integrity (Art. 32(1)(b) GDPR)

2.1 Transfer control

All data transmission takes place exclusively TLS-encrypted (HTTPS). Security headers are set per path; embedding in a frame is permitted only for the app path. Card payment data are processed exclusively by the payment service provider (Stripe, PCI DSS) and do not reach the Provider’s systems.

2.2 Input control

Traceability via the administration audit log (retention two years). Payment events are permanently recorded as a signature-verified raw record before they are processed; the processing paths are idempotent (protection against duplicate processing).

3. Availability and resilience (Art. 32(1)(b), (c) GDPR)

3.1 Availability

Operation on highly available, managed infrastructure. Application compute and database: Frankfurt am Main; CDN and static delivery via the global Vercel network. Protection against overload and abuse through rate limiting and bot checks. Transactional emails run through a fault-tolerant queue with retry, error detection, and operational alerting.

3.2 Rapid recoverability

Database backup and restore are handled via the managed backups of the database operator (regular, at least daily backups; point-in-time recovery where enabled for the project). The application code is versioned and can be deployed reproducibly.

4. Procedures for regular review (Art. 32(1)(d); Art. 25 GDPR)

4.1 Data protection management

An external data protection officer has been appointed (Datenschutz & Informationssicherheit Alb e.K.). This TOM and the record of processing activities are updated as the occasion arises.

4.2 Incident response and reporting chain

Operations are monitored via an ops panel (backlog, error queues, cron heartbeats, configuration readiness). Critical error events trigger exactly one alert to an operations address. In the event of a personal data breach, the Provider as processor informs the controller without undue delay (Art. 33(2) GDPR).

4.3 Engagement control

Sub-processors are engaged exclusively on the basis of contracts pursuant to Art. 28 GDPR; EU regions are preferred (Frankfurt am Main or EU). For providers with a third-country connection, an adequacy decision (in particular the EU-US Data Privacy Framework) or EU standard contractual clauses together with supplementary measures apply.

4.4 Data protection by design and by default (Art. 25 GDPR)

License and permission checks follow the fail-closed principle; presence data are processed only in the browser; Microsoft Graph access is limited to what is necessary (read-only access to user and presence data); deletion takes place automatically after defined periods (section 4.5).

4.5 Deletion concept (automated)

Deletion or anonymization takes place automatically after the following periods:

• Sales inquiry (open): deletion after 180 days.
• Sales inquiry (rejected): deletion after 30 days.
• Sales inquiry (converted): anonymization after 180 days (audit trail remains).
• Email queue (sent): deletion after 30 days.
• Email log: deletion after 90 days.
• Payment processing event data (processed): deletion after 90 days.
• Administration audit log: deletion after two years (730 days).
• Orphaned trial records: deletion upon expiry of the activation token.
• Record of the conclusion of the DPA: integrity-protected retention; automated deletion at the end of the sixth full calendar year after the definitive end of the contract (retention analogous to Section 257 of the German Commercial Code (HGB) / Section 147 of the German Fiscal Code (AO)), unless a legal hold exists.

Records with errors are deleted only after their resolution plus the respective period.