# Privacy > How Safematix handles website enquiries, retention, security, and your data-protection rights. Last updated: 27 October 2026 ## Controller Controller: Robert Ressl Safematix, sole proprietorship under Swiss law, Wollerau, Schwyz, Switzerland; hello@safematix.com. ## Data and purpose When you submit the contact form, Safematix processes your name, work email, optional company, selected service, message, language, and the time you confirm the privacy notice. These details are used only to answer your enquiry, prepare a possible engagement, and protect the form from abuse. Public website pages use Umami analytics through analytics.ressl.it. The getinfo and recorder.js scripts load from that host on public pages; login, customer and administration portal pages exclude these scripts and do not load Umami analytics, session replay or heatmaps. Umami processes page URL, page title, referrer, hostname, screen dimensions, browser language, timestamps, and technical identifiers. The recorder also samples session-replay and heatmap data such as DOM snapshots, clicks, scrolling, viewport metrics, and interaction timing. Its current configuration enables replay and heatmap at a 15% sample rate each, with moderate input masking; the five-minute maximum duration applies to replay. Safematix does not use a third-party form processor; the contact form remains self-owned. Analytics is separate from enquiry handling and is used to understand and improve website usage. ## Processing and retention Contact-form submissions are encrypted in transit, queued in Safematix’s PostgreSQL 18.6 database, and sent to the Safematix mailbox. The contact-email queue row is deleted after successful email delivery; failed deliveries remain queued for retry. This queue deletion does not delete persistent portal records. Mailbox retention is limited to handling the enquiry, any resulting engagement, and applicable legal obligations. Standard host logs may process technical connection data. The contact-form rate limiter keeps only keyed, process-local hashes of client IP addresses and attempt timestamps. Its configured window, which defaults to one hour, determines which attempts count; cleanup runs during later checks and periodic maintenance, not at an exact erasure deadline when the window expires. Analytics event and replay storage locations and retention periods are determined by the analytics operator and are being documented; they are separate from Safematix’s outbox and mailbox retention. Portal authentication uses a separate configured rate-limit window and distinct client-IP and submitted-email buckets. After the client-IP check, self-registration uses a keyed hash of the normalized submitted email address; password recovery uses a keyed hash of the trimmed, lowercased submitted email address, including addresses with no matching account. The limiter holds these hashes and attempt timestamps only in process memory; it does not write plaintext limiter identifiers or limiter hashes to the database. Expired authentication-limiter entries are pruned on subsequent limiter checks and may remain in memory until a later check or process exit. A rate-limit window is not an exact erasure deadline or a deletion schedule for persistent portal records. ## Authenticated customer and administration portal The portal supports customer self-registration and administrator invitations. It processes your submitted organization name and account email, organization membership, registration origin, system role, assigned customer access role, language and status, password hash, and activation, password-reset and session records to authenticate users, control access and administer engagements. Self-registration creates a separate organization for an eligible new address; a matching name or email domain never joins an existing organization. The generic registration response does not confirm account existence or email delivery. A single-use activation email lets you confirm mailbox access and set your own password; mailbox confirmation does not verify the organization. The portal uses two first-party cookies: a login-session cookie and a CSRF-protection cookie. In production both are Secure and SameSite=Strict; the login-session cookie is HttpOnly, while the application can read the CSRF cookie. Administrators manage localized customer-role names and descriptions, read-only and capability policies, individual offering and canonical service-package grants, shared data-package grants, and customer role assignments with their automatic or explicit origin. These records determine available portal sections and deliveries together with current organization verification. Role assignment does not confer administrator access or business verification. Effective access is recalculated for protected requests; read-only access excludes operational mutations, and sensitive services retain ownership and exact signed-scope requirements. Portal records include organization identity and registry details, submitted verification evidence, registered domains, IP addresses or networks, target environments and ownership statements, review decisions and reviewer details, and service/package orders with their selected targets, notes and status. These records support manual identity and ownership review, order handling and the approval conditions for sensitive work and private downloads. The portal stores immutable contract and service-level agreement (SLA) versions and records the signer name, account, UTC signing time and signature audit ID. Published contracts and SLAs remain scoped to the account’s own organization. The document SHA-256 identifies the exact Markdown bytes. For order-bound service authorizations, the exact order and immutable snapshot of target identifiers, types, values and environments are stored separately with their own scope SHA-256. The signing record and downloadable receipt link the document hash and the separate scope hash to that order and target snapshot where applicable. The receipt records the portal signing confirmation; it does not claim external or notarized signature certification. Private uploaded deployment images and curated data packages, their descriptions and delivery notes, byte size, SHA-256, kind and publication/retirement information support controlled delivery. Data packages are global shared files or bundles available to explicitly granted roles, including active accounts in unverified organizations; they are not a channel for one customer’s confidential contracts or records. Deployment-image delivery remains separately gated by current organization verification and the sensitive-order approval chain. Audit records associate account actions, including self-registration, role/grant changes and assignment, contract signing, review decisions and contract/deployment/data-package downloads, with record identifiers, UTC times and relevant event metadata. Private files are stored separately from public website files. Portal records are separate from outgoing-email queues and are not deleted when an invitation or other email is delivered. Session/token expiry or revocation ends their use for access; account deactivation and artifact retirement also restrict access rather than erase the stored records. The portal currently has no automatic purge of persistent portal records. Contract snapshots are immutable and audit records are append-only; routine audit updates, deletion and truncation are blocked. The retention schedule and handling of correction/deletion requests for these records, including linked immutable records, remain to be determined before production use; the contact-mailbox or application-log periods do not establish their retention periods. ## Recipients and international processing Safematix does not sell data or share it for advertising. The analytics operator at analytics.ressl.it receives the usage and interaction data described above when public website pages load, not from login, customer or administration portal pages. The server and email infrastructure operators that run safematix.com and the mailbox process the data to provide those services. This operation can involve processing outside Switzerland or your country of residence. Calendly, LinkedIn, ressl.ch, GitHub, Hugging Face, and credential-link destinations have their own privacy policies. Connections to them occur only when you follow a link; Umami connections occur when public website pages load, not when login, customer or administration portal pages load. ## Your rights and contact You may request access, correction, deletion, restriction, objection, and—where applicable—data portability through hello@safematix.com. These rights apply under the Swiss Federal Act on Data Protection (FADP) and, where applicable, the GDPR. You may also complain to the competent data-protection authority. ## Security and data minimization TLS is used in production, and access to backend systems is restricted to operation. On public website pages, the recorder’s current configuration masks input values, but page content and interaction metadata can still be captured; the portal excludes the recorder. Do not send passwords, secrets, personal data about others, or sensitive exploit details through the initial form.