Technical and Organizational Measures (TOM)

← Back to PII Anonymizer Download TOM as PDF

pursuant to Art. 32 GDPR for the PII Anonymization Service

Last updated: 23.03.2026 · Version 1.0

Overview

This document describes the technical and organizational measures (TOM) pursuant to Art. 32 GDPR that the PII anonymization service by Schiller - Organisation. Digital. Michael Schiller has implemented to ensure a level of protection appropriate to the risk.

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

1.1 Physical Access Control

Protection against unauthorized access to data processing facilities

  • ✓ Servers in a professional data center in Germany (Hetzner, Nuremberg)
  • ✓ Physical access protection by the data center operator (ISO 27001 certified)
  • ✓ No physical access by Processor employees required (fully remotely managed)

1.2 System Access Control

Protection against unauthorized use of data processing systems

  • ✓ SSH access exclusively via key-based authentication (ED25519)
  • ✓ No root access, only dedicated user accounts
  • ✓ Anubis bot protection for all public endpoints
  • ✓ Rate limiting: 60 requests/minute per IP address
  • ✓ Fail2Ban for SSH brute force protection

1.3 Data Access Control

Protection against unauthorized reading, copying, modification, or removal

  • ✓ API endpoints are publicly accessible (no authentication required) – this is intentional as no personal data is permanently stored
  • ✓ Mapping tables are session-isolated (UUID) and only accessible with the correct session ID
  • ✓ No administration interface for PII data
  • ✓ No ability to retrospectively view processed texts

1.4 Separation Control

Separate processing for different purposes

  • ✓ Each anonymization session receives its own UUID
  • ✓ Session data is completely isolated from each other
  • ✓ No shared use of mapping tables between sessions
  • ✓ Production and staging environments physically separated (separate containers, separate databases)

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

2.1 Transfer Control

Protection during data transmission

  • ✓ TLS 1.3 encryption for all API communication (HTTPS)
  • ✓ Caddy reverse proxy with automatic certificate renewal (Let's Encrypt)
  • ✓ No unencrypted transmission channels
  • ✓ No data transfer to third countries
  • ✓ No sub-processors

2.2 Input Control

Traceability of data processing

  • ✓ No logging of transmitted texts or PII content (Privacy by Design)
  • ✓ Only technical metadata is logged: timestamp, IP address, number of detected entities, processing duration
  • ✓ Mapping tables are automatically deleted after maximum 1 hour

3. Availability and Resilience (Art. 32(1)(b) GDPR)

3.1 Availability Control

Protection against destruction or loss

  • ✓ Automatic container restarts on failures (Kamal/Docker)
  • ✓ Monitoring with Grafana dashboard
  • ✓ Daily backups of system configuration
  • ✓ No permanent storage of personal data → no data loss possible
  • ✓ In case of system failure, only temporary mapping tables are lost (max. 1h of data)

4. Recoverability (Art. 32(1)(c) GDPR)

Since no personal data is permanently stored, recovery is limited to system availability:

  • ✓ Container-based deployment architecture (Kamal) enables rapid recovery
  • ✓ Automatic health checks and restart mechanisms
  • ✓ Disaster recovery through image-based deployments: complete re-provisioning in under 10 minutes

5. Regular Review Procedures (Art. 32(1)(d) GDPR)

5.1 Data Protection Management

  • ✓ Regular review of technical measures
  • ✓ Automated security tests (Brakeman, Bundler-Audit) in the CI/CD pipeline
  • ✓ Dependency scanning via Dependabot
  • ✓ Code reviews before every deployment

5.2 Privacy by Design & Default

  • ✓ Original texts are processed exclusively in RAM – no storage on disk
  • ✓ Mapping tables with automatic TTL (max. 1 hour)
  • ✓ No content logs – no transmitted texts are logged
  • ✓ Session isolation via UUIDs – no cross-session access possible
  • ✓ 5 parallel detection methods for maximum coverage with minimal data retention

6. Detection Systems

The PII anonymization service employs 5 parallel detection methods:

Pattern Detection – Regex-based detection of structured data (email, phone, IBAN, credit cards, EU-VAT)

SpaCy NER – AI-based Named Entity Recognition (local, no cloud service)

Address Detection – Specialized address detection for 30+ countries

Crypto Wallet Detection – 12 cryptocurrencies (Bitcoin, Ethereum, Litecoin, Ripple etc.) via pattern matching

Abbreviation Detection – Detection of company/department abbreviations (enabled by default, ~665 whitelist entries)

All detection systems run locally on own servers in Germany. No data is transmitted to external services.

7. Infrastructure Overview

Server

  • Hetzner Cloud, Nuremberg, Germany
  • Ubuntu Linux (hardened)
  • Kamal (Docker-based)

Services

  • Rails 8 (Ruby 3.4) – API and web interface
  • SpaCy NER Service – Local AI container
  • Crypto & EU-ID Pattern Matching – Integrated in Pattern Detector
  • Caddy – Reverse proxy with TLS 1.3
  • Redis – Session cache with TTL

8. Contact

For questions about the technical and organizational measures:

Michael Schiller (Managing Director)

Schiller - Organisation. Digital. Michael Schiller

info@schiller-partners.de

Download TOM as PDF