Technical and Organisational Measures

Last updated: April 21, 2026

This document describes the technical and organisational measures ("TOMs") implemented by FEELTECH to protect personal data processed through the RDAP API service, in accordance with Article 32 of the General Data Protection Regulation (GDPR). It is maintained as Annex 1 to our Data Processing Agreement and complements our Privacy Policy.

1. Scope

These measures apply to the production infrastructure operated by FEELTECH to deliver the RDAP API service, including web and API endpoints, the application database, and related backup and monitoring systems. The list of subprocessors involved in processing personal data is published in our Privacy Policy, §6.

2. Hosting and Data Location

  • Production systems are hosted by Hetzner Online GmbH in Nuremberg, Germany, within the European Union.
  • Hetzner operates ISO 27001-certified data centres. Physical access control, environmental controls, secure hardware decommissioning, and destruction of storage media are performed by Hetzner under its certified processes.
  • All live production data is stored in the European Union.
  • OS-level disk encryption is not applied to the live production volume. Confidentiality at rest is ensured through (i) Hetzner's physical and operational security controls, (ii) the host firewall configuration described in §5, and (iii) application-level encryption of all off-site backups described in §6.

3. Access Management

  • The service is operated by a single natural person, Nicolas Boutet-Mangon, acting as Gérant of FEELTECH. No employees, contractors, or third parties have access to the production environment or to customer personal data.
  • Administrative access to the production server is performed via SSH on a non-default port, using public-key authentication only. Password authentication is disabled and direct root password login is prohibited.
  • Two-factor authentication (2FA) is enabled on all operator accounts for critical services: domain registrar, hosting provider (Hetzner), DNS and CDN (Cloudflare), payment processor (Stripe), backup storage (Backblaze), transactional email (Mailgun), and source code hosting (GitHub).
  • The application database (MariaDB) is bound to the loopback interface and is not reachable from the internet. Database credentials are scoped per role: the application user is limited to the application schema; the backup user is restricted to SELECT and LOCK TABLES privileges.
  • Operational secrets (API tokens, backup encryption key, database passwords) are stored in a private infrastructure-as-code repository and encrypted at rest using Ansible Vault. Access to the decryption key is limited to the operator.

4. Encryption

  • In transit. Connections between end-users and the RDAP API service are encrypted with TLS 1.2 or higher, terminated at the Cloudflare edge. The host firewall at the origin server only accepts inbound HTTP(S) traffic from Cloudflare IP ranges; direct origin access is blocked.
  • Backups. Database backups are encrypted with AES-256-CBC using OpenSSL before being uploaded to off-site storage. The encryption key is held by the operator and is not shared with the backup storage provider.
  • Passwords. Customer passwords are hashed using bcrypt. Passwords are never stored in plain text and are not logged.
  • API credentials. Personal access tokens used to authenticate API requests are stored hashed; only a short display prefix is retained in clear text for identification in the customer dashboard.

5. Network and Application Security

  • Edge protection. Inbound traffic passes through Cloudflare, which provides reverse proxy, TLS termination, DDoS mitigation, and Web Application Firewall filtering.
  • Host firewall. The production server runs a default-deny firewall (UFW). Only SSH and HTTP(S) from Cloudflare IP ranges are permitted. All other inbound ports are closed.
  • Intrusion prevention. Fail2ban is configured to automatically ban source IP addresses that trigger repeated SSH authentication failures or excessive rate-limit violations at the web tier.
  • Rate limiting. nginx enforces per-IP request rate limits for the web interface and the API. Authenticated API requests are further constrained by per-plan quotas and per-minute rate limits at the application layer.
  • HTTP security headers. The application sets X-Frame-Options, X-Content-Type-Options, and Referrer-Policy on all responses. Cross-Site Request Forgery (CSRF) protection is enforced on state-changing requests.
  • Session management. Authentication uses session cookies with the HttpOnly and Secure flags. Session identifiers are rotated on login.
  • Patch management. Operating system security updates are applied automatically via unattended-upgrades. Application and framework dependencies are updated on a regular cadence.

6. Backup and Business Continuity

  • The application database is backed up every 6 hours.
  • Each backup is compressed, encrypted with AES-256-CBC (see §4), and uploaded off-site to Backblaze B2 (US-West region) in a dedicated bucket.
  • Backups are retained for 30 days and automatically deleted thereafter by a lifecycle policy.
  • Backup freshness is monitored continuously. An alert is triggered to the operator if a scheduled backup cycle is missed.
  • A documented and scripted restore procedure is maintained. It covers download of the latest encrypted backup, decryption, import into a clean database, and integrity verification. The procedure was last exercised end-to-end on April 21, 2026.
  • Recovery objectives. Target Recovery Point Objective (RPO): 6 hours. Target Recovery Time Objective (RTO): best-effort within 4 hours for a full single-region restore. These targets are operational objectives, not contractual commitments, unless explicitly agreed in a separate Service Level Agreement.

7. Logging and Monitoring

  • Application events are logged to a daily-rotated log channel. Web server access and error logs are rotated and retained on the production host according to standard logrotate policies.
  • A log-watchdog agent runs on the production server and, every minute, scans application log files and the system journal for configured error patterns. Matches trigger an alert to the operator through an instant-messaging channel.
  • The same agent also monitors disk usage, backup freshness, and outbound IP pool integrity, and alerts when any of these leaves the configured operating range.
  • Logs do not include customer passwords or API token secrets. The categories of data contained in request logs are described in our Privacy Policy, §3.

8. Vendor and Subprocessor Management

  • FEELTECH selects subprocessors on the basis of their ability to provide appropriate technical and organisational safeguards, including GDPR-compliant data processing terms and, where applicable, Standard Contractual Clauses for international transfers.
  • The current list of subprocessors is published in our Privacy Policy, §6, and is kept up to date.
  • Registered users are notified in advance of any material change to the subprocessor list so that objections can be raised before the change takes effect.

9. Incident Response and Breach Notification

  • Security incidents and suspected personal data breaches may be reported at any time to [email protected].
  • Upon becoming aware of a personal data breach, FEELTECH will notify the competent supervisory authority (in France, the CNIL) within 72 hours, in accordance with GDPR Article 33, and will inform affected users without undue delay when required under GDPR Article 34.
  • Each incident is documented with scope, impacted data subjects, timeline, remediation actions, and lessons learned. Affected customers receive a post-incident summary.

10. Organisational Measures

  • Processing operations are carried out by a single natural person, the Gérant of FEELTECH, who is bound by confidentiality obligations as company director under French company law.
  • No personal data processed through the service is disclosed to any third party, except to the subprocessors listed in our Privacy Policy, §6, or where required by a legally binding request from a competent authority.
  • Source code is maintained in a private repository with access restricted to the operator and protected by 2FA.
  • Our processing activities do not meet the criteria of GDPR Article 37 for the mandatory designation of a Data Protection Officer. All privacy and security requests are handled directly by the operator.
  • Operational continuity. A documented continuity runbook defines the procedure to be followed if the operator becomes unavailable for an extended period. A designated emergency contact holds, via a secured emergency-access mechanism, the credentials required to wind down the service in an orderly manner. The committed wind-down window is a minimum of 30 days, during which customers retain API access and may export their data. Active subscriptions are refunded pro-rata, customer personal data is deleted at the end of the wind-down, and accounting records are retained for the period required by French commercial law. The runbook is reviewed annually.

11. Review and Updates

These measures are reviewed periodically and updated when the underlying infrastructure, processing activities, or applicable regulations change. The date of the last update is shown at the top of this page. Registered users are notified of material changes via email and through our public changelog.

12. Contact

For security-related reports or questions, contact [email protected]. For all other matters, contact [email protected].