DPA — SECURITY MEASURES

Annex 2 to the Data Processing Agreement · Effective September 24, 2026 · Version 1.0

This document describes the technical and organizational measures that protect data entrusted to Offerandum. It is part of the Data Processing Agreement and covers confidentiality, integrity, availability and recovery of data.

ORGANIZATION OF DATA PROTECTION

1. Damian Krychowski, who runs the Offerandum service, is responsible for the organization of data protection. Security matters and breaches can be reported to contact@offerandum.com.
2. We choose measures according to the kind of data, the scope of the service, the likelihood and impact of threats and the state of the art. The assessment also covers accidental disclosure, alteration, deletion and loss of availability.
3. We keep records of access, of handling requests, of breaches and of security reviews. Permissions are granted only to the extent needed for a task, and everyone with access is bound by confidentiality.
4. The forms are meant for ordinary contact and quote data. They are not for collecting passwords, payment card data, identity documents or special categories of data. The set of fields is limited to what handling an enquiry needs.

AUTHENTICATION AND ACCESS CONTROL

1. Access to the panel requires authentication with a one-time code or link from an e-mail message, with a passkey (WebAuthn) or with Google. Codes and links are valid for 15 minutes; we store their hashes and check single use atomically, and a code is accepted only from the browser that asked for it and after at most five attempts. A passkey is bound to the service's domain, requires user verification on the device, and the server stores only the public key and checks a single-use challenge and the signature counter. Sessions are verified on the server, have a limited lifetime and inactivity limit, and are revoked on sign-out, account block or loss of permissions. The session identifier travels in an HttpOnly, Secure cookie, and requests are protected against CSRF.
2. The operator confirms access with a code from an authenticator app or a one-time recovery code. Only a device-bound (not synced) passkey with user verification replaces it; Google sign-in, an e-mail code and a synced passkey do not. Recovery codes are stored as hashes. Changing the configuration ends existing sessions.
3. Every request for a resource is checked against the user's permissions and company membership. Customer data is logically separated; sharing infrastructure never lets a user of one company read the data of another.
4. Users of a company's panel have access to that company's data within the function granted to them. The Customer is responsible for naming authorized people and for asking us to remove their access.
5. Administrative access to the infrastructure, the code repository and e-mail is protected by multi-factor authentication. Operator access to companies' data is protected additionally and recorded with the real person and the actions performed.
6. Technical support uses customer data only to the extent needed, in connection with a request, an instruction or a documented security need. We do not routinely browse the content of enquiries without a reason related to the service.

DATA IN TRANSIT AND AT REST

1. Communication with the service is protected by HTTPS. Access to private data and documents requires a permission check; files of enquiries are not exposed in any public directory.
2. The full content of an enquiry, the record of form events, its saved state and the PDF documents are stored as files in private Cloudflare R2 storage. The list data of enquiries, including contacts, statuses and notes, is stored in a Cloudflare D1 database. The backend reads this data to serve the panel, prepare PDFs and send messages.
3. Access to the service's secrets is restricted. Secrets are not placed in code, public repositories or application logs.
4. An e-mail and its attached PDF are readable by the recipient. Protecting the copy in the company's mailbox and any further forwarding of documents is the responsibility of the company as controller.

APPLICATION AND INFRASTRUCTURE SECURITY

1. Form code runs in an isolated environment with restricted permissions. We apply a content security policy and control the communication between the form's environment and the application.
2. The backend checks permissions and the scope and format of input data. Request limits and anti-abuse mechanisms protect sign-in, the receipt of enquiries and the sending of messages.
3. Development and production environments are separated. Ordinary testing uses fictitious data. Exceptional diagnostics with real data requires a limited scope, a documented need and deletion of the copy afterwards.
4. Updates and changes are reviewed in proportion to their risk. Changes to access, export, deletion and data handling mechanisms are also checked for the isolation between companies.
5. Devices used for administration are protected by disk encryption, screen lock, access control and updates. Access to working copies is restricted, and copies are deleted once their purpose is served.

LOGS AND ANOMALY DETECTION

We log the events needed to protect the service, for diagnostics and for accountability. The scope of logs is limited; they contain no authentication tokens and no full content of enquiries. Diagnostic data and access to it are subject to defined retention periods and permission checks.

We monitor the failures of important tasks, in particular sending, deletion and backups. Failed operations are retried or escalated for investigation. The record of service usage is separate from the record of operator access.

BACKUPS AND RECOVERY

1. Backups cover the data and files needed to restore the service, and the configuration and secrets can be recovered securely. Restoring the database alone does not replace the protection of documents and files.
2. Backups are made at least once a day and rotated within no more than 30 days. They are separated from live operations and available only to the people responsible for recovery.
3. We test recovery at least once a quarter and after any significant change to the backup mechanism. The test covers the completeness of data and files, the isolation between companies and the reapplication of deletion instructions.
4. Before a restored service is made available, we apply earlier deletion instructions so that data already deleted does not return to use.

RETENTION, EXPORT AND DELETION

Data is kept as the Customer instructs and as the DPA describes. An enquiry is kept for as long as the Customer keeps it; the Customer can delete it in the panel or instruct its deletion at any time.

Export covers the entrusted data together with the documents and the information needed to read them. Deletion covers active data, related files and tasks. We do not treat removing an entry from the panel as the end of deleting all of its copies.

After a verified deletion instruction, active data is deleted within 7 calendar days, or sooner where the matter requires it. The remaining isolated backups expire within a further 30 days. After the service ends, data stays available for export for 30 days and is then deleted; the details of return and of ending the cooperation are in the DPA.

Deletion operations are monitored and retried on error. We record their completion and the latest date on which backups expire. Keeping specific data because of a legal obligation requires stating the basis, the scope and the period.

RIGHTS OF INDIVIDUALS AND BREACHES

1. We help the Customer find, provide, correct, restrict or delete data according to a verified instruction. Identity verification is proportionate to the nature of the matter.
2. After becoming aware of a breach of entrusted data, we inform the Customer without undue delay and no later than 24 hours. The first notification may be supplemented as the facts are established.
3. We preserve evidence, limit the consequences, document the actions taken and cooperate in establishing the scope of the event. The decision to notify a supervisory authority and the individuals is taken by the Customer as controller, with Offerandum's support.
4. The Customer keeps its incident contact details up to date. The detailed scope of assistance, notifications and deadlines is set out in the DPA.

SUBPROCESSORS, REVIEWS AND AUDITS

Subprocessors and data location rules are described in Annex 1. We assess providers with regard to the scope of their processing, their contractual terms and any transfers outside the EEA.

Security measures are reviewed at least once a quarter and after any significant change or incident. Review results and remedial actions are documented. A change may not unilaterally lower the agreed level of protection.

We provide the Customer with the information and evidence needed to verify our obligations and support audits under the DPA, protecting secrets and the data of other customers. Certificates of infrastructure providers are not certificates of Offerandum.