Security overview

Overview

REALTY.TM GROUP sp. z o.o. (KRS 0001219891), registered at ul. Bpa Albina Małysiaka 26/15, 30-389 Kraków, Poland, develops and operates clausebench (https://clausebench.com).

clausebench is a workspace for outsourced DPOs and privacy consultants and for companies doing their own privacy work. It conducts a structured interview per client, drafts the documents their regulatory regimes require from the confirmed answers, answers security questionnaires from those documents, and publishes a trust page. clausebench prepares documentation and does not provide legal services.

clausebench serves business customers across the EU/EEA, the United Kingdom, the United States and Canada. Because those customers use clausebench to manage personal data belonging to their own clients and employees, protecting that data is central to how the product is built and operated. The sections below describe the controls in place and, where a control is planned but not yet in place, say so plainly.

Infrastructure

Hosting

clausebench runs in containers managed by REALTY.TM GROUP on a rented server located in Frankfurt, Germany (fra1). The database and file storage are provided by Supabase (Supabase Pte. Ltd., Singapore).

Encryption in transit

All data in transit is encrypted.

Encryption at rest

All data at rest is encrypted.

Environments

Two environments exist: development and tests run against a local database; production runs against the cloud project. There is no separate staging environment. The test suite is configured to refuse to run against any database that is not local, preventing test runs from touching production data.

Backups

Backups are taken daily, weekly and monthly and are retained for 90 days, stored in the same region as the database (Frankfurt). A restore has been tested; the maximum data loss in a recovery scenario is one day. Only technical support can initiate a restore, and service is restored within one day by the support team. A standby copy of the data and the code is maintained. The application is rebuilt from the repository by the deploy pipeline and started on the server with Docker Compose; the server's environment file is kept separate from the deploy so a redeploy cannot overwrite it.

A full disaster-recovery test — covering containers, data and a functional check of the service — is planned monthly. It has not been carried out yet; no date has been set for the first test.

Security practices

Access control

Every path into production data through clausebench requires a second factor: each admin screen, each staff endpoint and each staff action refuses a session that has not passed one. A second factor on the infrastructure accounts — the database provider, the server provider and the code host — is being switched on and is not yet in place for everyone.

Access to production is granted by the CTO, and each grant is recorded as a Jira task. Devices used to reach production must be enrolled in an access-control tool; a device that is not enrolled is not used for this work, regardless of whether it belongs to the company or to the individual.

Audit logging

The following events are logged:

• Every action taken by staff in the internal admin: who acted, in which staff role, on what, from which address and with which browser.
• Every support session into a client's workspace: which firm, which member of staff, when it started and ended, and the screens opened. Support access is read-only and is granted by the firm itself.
• Every successful sign-in to a workspace: the account, the firm and the method used.
• Every change to a client's facts, documents and vendors inside a workspace: who changed what, and when.

All staff are informed that access to production and to the admin is logged — who, when, from where, and every screen opened in a support session — and that those logs are used for security and incident investigation.

Application logs are retained for 90 days. Product events, which carry no personal data, are retained for 25 months (30 days for the demo workspace).

Password and credential policy

Every account uses its own password, generated and stored in a password manager. A second factor is required wherever a service offers one. On infrastructure accounts, MFA is being rolled out and is not yet in place for everyone.

Offboarding

Offboarding is owned by the CTO and recorded in the Jira task that originally granted access. On a person's last day: accounts are closed and blocked across GitHub, Supabase, DigitalOcean, Resend, Stripe, Anthropic, Jira and Confluence; SSH keys, API tokens and staff admin access are revoked; any shared secret the person could read is rotated; devices are removed from the access-control tool; and the Jira task is closed with each step confirmed.

Code review and development practices

Code is reviewed before it is merged to production.

Vendor governance

New vendors are approved by the CTO before engagement. The CTO checks: the contracting legal entity and its country; a signed data processing agreement; the mechanism covering any transfer out of the EEA or the UK; the vendor's sub-processor list and change notification process; where data will be stored; and the vendor's security documentation. The approval is recorded as a Jira task.

Vendors are reviewed annually by the CTO or the CEO; the outcome of each review is recorded in writing and kept in Confluence. Thirty days' notice is given before a new or replacement sub-processor is engaged, by email to everyone subscribed to notices.

Sub-processors

The following sub-processors are currently engaged:

Vendor	Legal entity	Country	Purpose
Supabase	Supabase Pte. Ltd.	Singapore	Database, authentication and file storage
Resend	Plus Five Five, Inc.	United States	Transactional email
Stripe	Stripe Payments Europe, Limited	Ireland	Payments and invoicing
Anthropic	Anthropic Ireland, Limited	Ireland	Drafting documents, interview replies and questionnaire answers

Penetration testing and certifications

clausebench does not currently hold SOC 2 or ISO 27001 certification and has not yet had an external penetration test. Penetration testing is planned on a monthly basis; no date has been set for the first test.

Incident response

Security incidents are reported to [email protected], which is monitored on working days and reaches the incident officer directly. The CTO deputises for the incident officer.

Upon receipt, the officer acknowledges within one working day and opens a record. Containment takes priority — revoking credentials, disabling accounts or taking an affected service offline. The assessment determines whether personal data was involved, whose, and in what volume. Where clausebench acts as processor, affected controller customers are notified without undue delay. Incident records and data subject request logs are retained for five years. A post-incident review is held immediately after an incident is closed, with the CTO, the CEO and the relevant team lead.

Policy review

Security and privacy policies are reviewed every quarter. When a policy changes, every user is notified in the product automatically when the change goes live, and the revised policy is published on the website with the date it changed.

Data subject requests

Requests from data subjects arrive at [email protected] and are handled by the CTO, who responds within one month. When a restriction request is accepted, the data is marked with a flag that stops it being processed. The lead supervisory authority for the operator's establishment is the Urząd Ochrony Danych Osobowych (Personal Data Protection Office), https://uodo.gov.pl/.