Records of Processing Activities (Art. 30 GDPR)

This document is published in several languages. In the event of any discrepancy between the language versions, the Polish version is binding.

Version 1.2 · Last updated: 29 October 2026

1. How to read this record

This is the record of processing activities under Art. 30 GDPR for formexposed. It is not a privacy policy and it is not marketing. Its job is to show a supervisory authority, a Customer auditing us as a processor, or the next person who has to answer a question what is actually processed, where it is held, who receives it and how long it stays. We publish it because a service that checks and monitors forms should itself be open to checking.

Three rules governed how it was written.

1. Measured, not intended. A statement about data fields, retention periods, recipients or safeguards appears only where the program code, the database schema or a measurement supports it. What is planned is called “planned”. What is switched off by default is called “off by default”. Where we cannot prove something, we say so.
2. Retention is stated twice. Once for each processing activity and once in section 6 as the overall picture: which nightly run deletes which data, and which data it does not reach. A record that claims a retention period which applies to only part of the data is worse than one that names the open point.
3. Open points are stated in the text, not in a footnote. Section 8.1 lists measures that have not yet been implemented, section 10 the open points with the planned measures. A record is a working tool, not a certificate.

Data fields instead of table names. For each processing activity we list the stored data as plain-language fields. The name of the database table follows in brackets so that an auditor can find the place, for example “login attempts (login_attempts)”. The field lists were derived from the database schema, not from memory.

Retention periods as placeholders. Where a retention period can be set in the administration area, it appears here exactly as the nightly run reads it: the number you see comes from the same setting that governs deletion. Retention periods fixed in the program are given as numbers.

Basis of measurement. Schema, code and settings were measured on 11 October 2026 on the development system, which matches the production system in code and schema. We do not give row counts from the development system; they contain test data and say nothing about live operation.

Deliberately omitted. This record does not name host names, internal network addresses, ports, user names or software versions of our servers. Such details help an attacker and no data subject. For the same reason, we describe open points in securing our own servers only in general terms (section 8.1): we name the risk, not the route to it. We provide the details to a supervisory authority on request.

Legal nature. This record is the documentation we maintain under Art. 30 GDPR for the supervisory authority; it is published voluntarily. It does not form part of any contract and does not constitute any representation, guarantee or agreement on quality vis-à-vis Customers or third parties. What we owe Customers is governed by the Terms of Service, the Data Processing Agreement and its annexes; with regard to these obligations, they take precedence over this record. The record describes the position as at the date of this version. Classifications such as “open point” or “assessment” reflect our own view and do not anticipate any legal evaluation by a supervisory authority or a court; measures described as “planned” are intentions without a committed date.

2. The legal entity and why this record has two halves

Field	Entry
Legal entity	LW IT Solutions Company Lukas Wójcik, sole proprietorship registered in the Polish business register (CEIDG); owner Lukas Wójcik
Address	al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland
Tax identifiers	NIP 7252266190, VAT ID PL7252266190
Contact	contact@lukaswojcik.com; the support window (question mark in the navigation); the contact page
Service	formexposed: checking, monitoring and securing contact forms on websites (app at formexposed.com, landing page at form.exposed)
Representative under Art. 27 GDPR	Not applicable. The legal entity is established in the Union (Poland).
Data protection officer	Not designated. The assessment under Art. 37 is in section 9.
Competent supervisory authority	Prezes Urzędu Ochrony Danych Osobowych (UODO, the Polish data protection authority), ul. Moniuszki 1A, 00-014 Warszawa
Hosting	Our own servers in Poland: one web server with the application and database, and one scan server with a local language model on the same internal network. No third-party data centre or cloud provider.

formexposed plays different roles towards different groups of people. Mixing them up produces a record that is right for none of them.

• Controller (Part B, Art. 30(1)). We are ourselves the controller for the data of our own Customers and their team members (account, login, billing, support, logs), for visitors to our own website, for checks without an account (free check, header tool, study, prospect check) and for abuse prevention.
• Processor (Part A, Art. 30(2)). For personal data of third parties that a Customer brings into the service or that arise when we perform a service for the Customer, we act on the Customer’s behalf: copies of real form e-mails in the delivery check, subscribers to the Customer’s client portal, recipients of the Customer’s alerts, people who happen to be visible on the Customer’s checked pages, the credentials of the Customer’s test account, and the form code the Customer pastes in. The basis is the Data Processing Agreement, which is concluded with every Customer at registration.
• Only on the Customer’s side. Some functions of the WordPress plugin and the TYPO3 extension process data exclusively on the Customer’s website, without the data ever reaching us (quarantine, safety net, arithmetic puzzle, retention settings, local counters, recorder). They are not processing by us and therefore appear in neither part. We nevertheless describe them at the end of Part A so that the boundary is visible.

The separation is built into the code, not just into the text: from a real form e-mail, the delivery check writes only the time, the assignment and the authentication result into the database; the screenshots of the browser checks mask input fields; test account credentials are encrypted in such a way that the web server can no longer read them. The details are given in the entries.

Sections 6 to 11 apply to both halves: retention, automated decisions, technical and organisational measures, data protection officer, open points and the upkeep of this record.

Scope. This document is the part of the record that concerns the formexposed service. Processing by the same legal entity for other services is recorded in their own records; general accounting and business administration outside the service are not covered by this part.

3. Part A – Art. 30(2): processing on behalf of Customers

A.0 Parties involved

Field	Entry
Processor	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland; contact@lukaswojcik.com
Controllers	The Customers of formexposed: businesses and agencies that hold domains in their account and use functions in which third-party data arises. With agencies, the agency’s own client may additionally be the controller; the agency then acts as processor towards that client and we act as a further processor.
List of controllers	Part of this record, kept in electronic form (Art. 30(3) GDPR) in the system of the service and not reproduced in this public version, because it contains personal data of Customers and would be out of date with every new Customer: the owner of each workspace with name, e-mail address and company from the customer account (address and VAT ID only at Stripe) (users, workspaces, workspace_users), plus the domains of the workspace (domains). We provide it to a supervisory authority as an extract on request.
Representatives and data protection officers of the controllers	There is no dedicated field for this in the system. If a Customer has designated a representative under Art. 27 GDPR or a data protection officer, it can notify us of them; we keep the notification together with the list of controllers.
Representative of the processor	Not applicable (established in Poland).
Data protection officer	Not designated (section 9).
Instructions	The instruction follows from the Data Processing Agreement and from the settings the Customer makes: the Customer switches on the delivery check, sets up alert targets, stores a test account and sets up a client portal. Without that action, the processing in question does not take place.
Technical and organisational measures	Section 8 and the page Technical and Organisational Measures apply to every processing activity in Part A. Special measures are stated in the relevant entry.

A.1 Delivery check – control copy of form e-mails

Field	Entry
Purpose	Checking whether the e-mail from the Customer’s contact form is actually sent and how it is authenticated (SPF, DKIM, DMARC, alignment). After an accepted active test submission, its copy must arrive in the control mailbox within an adjustable waiting time (currently 3 hours); otherwise the alert “Test e-mail not received” is raised. The headers are also used to derive the authenticity of the form e-mail, the e-mail service used and the sending address for the blocklist check.
Precondition	Paid plan, verified domain, switched on by the Customer. The Customer enters their own control address with an identifier (of the form “delivery+identifier@…”) as a blind copy in their form’s notification. Without a configured control mailbox the function is not available.
Categories of data subjects	Visitors to the Customer’s website who submit the Customer’s form; people whose data a visitor writes into the message; the Customer’s staff who appear as recipients in the headers.
Categories of personal data	In the control mailbox (at the mail service provider): the complete copy of every form e-mail, including real enquiries with name, e-mail address, telephone number and free text, until deletion. Read by the retrieval: the headers and at most the first 8 KB of the body. In the database: time of receipt, assignment to the domain and, where applicable, to the test run (delivery_log); the latest authentication result per domain with SPF, DKIM and DMARC result, alignment, sender domain, signing domains and the address of the sending mail server (authentication field of the domain in domains). Content, subject and the visitor’s sender address are not written to the database.
Note on the sender domain	If a form enters the visitor’s address as the sender (a misconfiguration that the check is designed to uncover), the authentication result contains the domain of that address, not the address itself. Where a visitor uses a personal domain, this too can be personal data. It is overwritten on the next receipt.
Source	The form on the Customer’s website, via the blind copy entered by the Customer.
Legal basis (determined by the controller)	Determined by the Customer. Our suggested text for the Customer’s privacy policy bases the copy on Art. 6(1)(f) GDPR (legitimate interest in reliably receiving enquiries). The Customer informs their visitors about this data flow; the Data Processing Agreement obliges them to do so.
Recipients	The mail service provider that runs the control mailbox (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA). The copy goes directly there: it only arrives if the MX records of our domain point to this mailbox (the pre-launch checklist checks this); via a forwarding it does not reach the mailbox. On the domain page the Customer sees only time, assignment and authentication result. If the authentication result deteriorates, the alert to the Customer and to the channels they have chosen names the sender domain if it does not belong to the website (A.3, 4.1).
Third country	Depends on the mail service provider; see section 4. The contract with the intended provider and the transfer basis are not yet documented.
Retention	After successful processing, the e-mail is marked for deletion and removed from the mailbox in the same run, even if it cannot be assigned to any domain. Retrieval runs with the status run every five minutes while monitoring is switched on in the administration area (srv/cron_status.php, cfg/zustellung_lib.php). If retrieval or deletion fails, the e-mail remains in the mailbox until the next successful run. The same retrieval deletes the assignments in delivery_log after 180 days. The authentication result lives as long as the domain.
What the evidence proves	Only the receipt, in the control mailbox, of the copy assigned to the specific test run. It proves neither receipt by the actual recipient nor an entry in the CRM. Native confirmation from HubSpot is not offered.
TOMs	Section 8. In particular: content is evaluated only in memory; no storage of body, subject or full sender addresses; deletion regardless of whether assignment succeeded.

The delivery check is the only function through which real messages from our Customers’ visitors reach us. That is why it is processing on behalf of the Customer rather than a service under our own responsibility, and that is why the time spent in the mailbox is the real measure of risk: normally minutes; if retrieval is disrupted, until it runs again. Copies should not contain special categories of personal data; we cannot technically prevent that, because what a visitor writes is up to the visitor.

A.2 Client portal and monthly report to subscribers

Field	Entry
Purpose	An agency (Business plan) shows its clients the state of their domains under its own brand (portal at a random address, optionally with a password, optionally under a subdomain of the agency’s own). The client can order a monthly report by e-mail there. The report is sent in the agency’s name.
Categories of data subjects	The agency’s clients and their staff who order the report; people who open the portal.
Categories of personal data	Subscriber: e-mail address, language, confirmation identifier, time of the order and IP address at the time of the order, time of confirmation (double opt-in), time of unsubscribing, last month sent (client_subscribers). Portal: name, selection of domains, random identifier, password only as a hash, person who created it, time, revocation (client_portals). Visits to the portal appear in the page view log (B.2).
Source	Entered by the subscribers themselves in the portal.
Legal basis (determined by the controller)	The subscriber’s consent, obtained through a double opt-in procedure; the controller is the agency. We do not write to anyone who has not signed up and confirmed themselves.
Recipients	The agency (sees its subscribers); the mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for the confirmation e-mail and the report.
Third country	Via the mail service provider; see section 4.
Retention	Nightly deletion run (cfg/fristen_lib.php, part “portal subscribers”): orders never confirmed after 30 days; unsubscribed subscribers three years after unsubscribing, as proof of the earlier consent. Confirmed subscribers who have not unsubscribed remain as long as the agency’s workspace exists. A revoked portal is only blocked, not deleted; its subscribers no longer receive reports, but their data remain (section 10). Portals and subscribers go immediately with the workspace (fe_arbeitsbereich_daten_loeschen()). Sent reports stay in the outbox for 30 days (B.25).
TOMs	Section 8. In particular: portal password only as a hash, guessing attempts limited (ten per portal and IP address, 50 per portal in 15 minutes); one-click unsubscribe in every e-mail; the portal shows only status and key figures, no individual findings with evidence.

A.3 The Customer’s alert recipients, acknowledgers and assignees

Field	Entry
Purpose	Notifications about faults and changes to the targets the Customer sets up for a domain: e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram. Per target immediately, or collected daily or weekly, plus targets for escalations only. Every problem notification becomes an incident, which the recipient can acknowledge via a link. For monitored forms, the Customer can specify a responsible person and a due date.
Categories of data subjects	Staff and service providers of the Customer whom the Customer enters as an alert target or names as assignees; people who acknowledge an incident. Team members with their own account also appear in Part B.
Categories of personal data	Alert target: channel, target address (e-mail address, webhook or chat address, Telegram chat ID), selected events, delivery mode, signing secret for webhooks, last delivery and last error (alerts). Delivery log: target, events, status, error, time (alert_log). Digest queue: notification lines and link until delivery (alert_queue). Incident: title, notification lines, link, acknowledgement identifier, time and name or e-mail address of the acknowledging person as entered in the form, otherwise the address of the logged-in member (alert_incidents). Escalation delivery attempts per incident and target: number of attempts (at most five), times of the last and the next attempt and of success, reference to the e-mail in the outbox, error (table alert_escalation_deliveries). Assignment: account of the responsible person and due date (in monitored_forms).
Content of the notifications	Domain, event, a short explanation and a link to the domain page. No content of visitor messages.
Source	Entered by the Customer; the acknowledging person enters their name themselves; the Telegram chat ID is created when the recipient presses “Start” in the bot (B.32).
Legal basis (determined by the controller)	Determined by the Customer; as a rule the organisation of the Customer’s own operations (Art. 6(1)(b) or (f) GDPR in relation to the Customer’s staff and service providers).
Recipients	The operators of the chosen channels; see 4.1. E-mail alerts via the mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Third country	Depending on the chosen channel; several providers are based in the USA, Telegram outside the EU without an adequacy decision. See 4.1.
Retention	Delivery log after 90 days (nightly, fe_alert_log_aufraeumen() from srv/cron_status.php). Digest notifications 30 days after delivery (cfg/kanal_lib.php, on every digest delivery). Incidents while unresolved; resolved ones 180 days after resolution (cfg/vorfall_lib.php, escalation run), together with their escalation delivery attempts. Alert targets and assignments until deleted by the Customer or together with the domain.
TOMs	Section 8. In particular: webhooks signed with a separate secret per target; acknowledgement only after a click (POST), so that link previews in chat programs do not trigger anything; alerts during a maintenance window are only logged, not sent.

A.4 People incidentally visible on checked Customer pages and in screenshots

Field	Entry
Purpose	Checking the domains in the Customer’s account (scan, monitoring, active check) reads the Customer’s public pages and takes screenshots of forms. What the page itself displays may concern people who have nothing to do with the check. These data arise incidentally; they are not the purpose of the check.
Categories of data subjects	People whose name, photo or contact details appear on the checked page (contact person next to the form, team photos on the home page, imprint details).
Categories of personal data	Screenshots: the visible area of the home page, every visible form as a crop, and the image of the follow-up page after an active test submission; stored as files outside the web directory, with only the reference in the database (scan_screenshots). Form structure: page address, selector, field names, field types, field labels, required and visibility flags, labels of submit buttons (forms, field “field map”); no field values. The scanner reads the beginning of hidden fields (up to 24 characters) and data attributes (up to 60 characters) only during the check, in order to recognise timestamps and tokens; only the result is stored. Findings with evidence (findings), summary with page titles (scans). For eligible checks in paid accounts, a local model generates a prioritised action plan from selected findings and scan metadata; its text, language, status and timestamp are stored in the scan summary. If an e-mail address appears in the form as the recipient, only its domain is stored, never the address.
Source	The public pages of the Customer’s domain, retrieved by the scanner.
Legal basis (determined by the controller)	Determined by the Customer for the content of the Customer’s own website. For us, the processing is part of the commissioned check.
Recipients	The Customer; with agencies, their client via the portal or a white-label report; anyone who receives a report link (reports at random addresses, not in search engines). Where the form type is unclear, a local language model on our own server receives the form structure with page title, page address and the visible text of the form (up to 400 characters) for classification; it does not receive images. For eligible paid checks, the local model also receives the hostname, overall result and score, CMS, relevant form type and page address, any identified plugin and selected failed or unclear findings to produce an action plan. The request is temporarily held in the internal job queue and deleted after collection or by scheduled cleanup of entries more than one hour old.
Third country	None.
Retention	Check results for a domain for at most 13 months; the last completed check per domain remains (nightly deletion run, part “old check results”). Forms, findings, image references and the image files go with the check result. With the domain, these data go immediately (deletion chain in B.15; exceptions in section 6.4).
Limits of masking	The screenshots of the full check mask nothing: they show what the page shows to every visitor. Form fields are empty when retrieved, because the scanner enters nothing; pre-filled values would be visible. No screenshots are taken behind a login (A.5). The images of the browser checks mask input fields (A.6).
TOMs	Section 8. In particular: images can be retrieved only via the report, and someone else’s image identifier returns “not found”; reports with noindex; every check runs in its own isolated container.

The same data arise in checks without an account (free check, study, prospect check). There, there is no Customer on whose behalf we act; these cases therefore appear in Part B (B.5, B.7, B.8).

A.5 Test account credentials for the scan behind the login

Field	Entry
Purpose	Reading forms that appear only after logging in (customer area, members’ area). The scanner logs in with a test account that the Customer has created on their own website and reads the specified pages. Apart from the login form it submits nothing, carries out no active test there, takes no screenshots and does not visit logout, deletion or cancellation addresses. If the login form has a CAPTCHA, it stops; CAPTCHAs are not bypassed.
Precondition	Verified domain, paid plan, owner or admin role, express confirmation that the account is a test account. At most five pages, all on the same domain.
Categories of data subjects	The person in whose name the test account is held (ideally nobody; the Customer should use a functional account); people whose data appear on the pages behind the login.
Categories of personal data	User name and password of the test account, encrypted only; a hint for the user name (first character and length); login address, list of pages, names of the login fields, success indicator, person who created it, times, last result as a short code (domain_logins). For a running job, a copy of the ciphertext (field “login package” in scan_jobs). From the pages behind the login: form structure as in A.4, without screenshots and without cookies.
Source	Entered by the Customer in the account.
Legal basis (determined by the controller)	Determined by the Customer. The Customer warrants that they are entitled to use the test account.
Recipients	None. Neither the Customer nor support nor the programming interface can read out the credentials; the interface shows only the hint for the user name.
Third country	None.
Protection of the credentials	User name and password are encrypted immediately on storage with the scan server’s public key (X25519, HKDF-SHA256, AES-256-GCM; the domain is bound as associated data, so a ciphertext cannot be attached to a different domain). Only the scan server has the private key. Web server, database and backups contain only ciphertext; we cannot decrypt it there either. The scan server decrypts only for the run, passes the credentials into the isolated check container only via standard input, deletes the copy in the job immediately and writes it into no result, log or error text. On the way to the Customer’s website they are protected only by that website’s encryption; the limits of this transport are set out in section 10.
Retention	Stored credentials until deleted by the Customer. On deletion, the ciphertext is overwritten with random data of the same length and the row is deleted; waiting jobs are cleared (fe_login_loeschen()). With the domain, the row goes via a foreign key. The scan server clears copies in jobs after the run; anything left over (job aborted, scan server down) is cleared by the status run after one hour at the latest (fe_login_aufraeumen(), part “login_jobs”). Database backups contain the ciphertext until the backup expires after 14 days.
TOMs	Section 8. In particular: asymmetric encryption with separate keys; blocklist for logout and deletion paths; no screenshots behind the login; function only for paid plans and verified domains; every change in the activity log (without credentials).

We have deliberately not built any way to store credentials for the Customer’s server, CMS administration area or hosting accounts. The test account is a visitor account on the Customer’s website, not access to the Customer’s system.

A.6 Configured form journeys, browser checks and independent probe

Field	Entry
Purpose	A monitored form is run through in a real browser (Chromium, WebKit or both) up to the point just before submission: load the page, perform preceding clicks (at most five, never on an input field or a submit button), fill fields with recognisably synthetic values (such as an address under the reserved ending .invalid), advance multi-step forms. The browser check submits nothing; submission is technically blocked in the browser. In addition, timing measurements and visual comparisons of the form.
Categories of data subjects	As A.4 (people visible on the form page); the Customer’s staff entered as assignees (A.3).
Categories of personal data	Configuration: form address, selectors, entry address, click steps, browser choice, label, criticality, assignment, due date (monitored_forms). Results per run: state, technical failure reason, sanitised error messages, network and timing measurements, an image of the form as a JPEG of at most 32 KB with masked input fields (form_browser_runs). Observations per check (form_observations), time series (form_performance). Jobs with a target list (fields “targets” and “result” in scan_jobs).
Test access	If the Customer has stored a test account (A.5), the full check also uses it for configured form journeys. According to the measured code, the stand-alone browser checks between two full checks work without a test account.
Independent probe	A second check point at a different location is envisaged, which would cross-check before an alert. It would receive the domain, the sanitised configuration and the job identifier, no visitor input and no credentials. It is currently not set up (off by default). Without the probe there is no evidence from a second location; an alert is then based on our own measurement.
Source	Configured by the Customer; results from retrieving the Customer’s page.
Legal basis (determined by the controller)	Determined by the Customer for the content of the Customer’s website and for the responsibilities of the Customer’s staff.
Recipients	The Customer; where a probe is set up, its operator (currently nobody).
Third country	None.
Retention	Results of browser runs, completed browser jobs and time series after 13 months (nightly deletion run, parts “browser_runs”, “browser_jobs”, “form_performance”). Configurations until the domain is deleted (individually they can be changed or switched off, not deleted); with the domain they go, together with runs, observations and time series, via foreign keys.
What the measurement proves	Times and states from our check browser. They do not measure what real visitors experience and prove neither completion rates nor lost enquiries.
TOMs	Section 8. In particular: submission technically prevented; only addresses on the same domain; masked images; isolated check container.

A.7 “Fix it for me” – pasted form code

Field	Entry
Purpose	The Customer pastes in the code of their form; a language model on our own hardware builds in the protection module. What comes back is the modified file, a patch, the result of a syntax check and an indication of whether the check call has actually been built in. Without pasted code, the service delivers a ready-made module with the field names from the last scan.
Categories of data subjects	People whose data happen to be in the pasted code (such as a recipient address, names in comments, credentials for a mail server).
Categories of personal data	The pasted code, at most 30,000 characters. In the database only an entry in the activity log (action “fix_ai” with workspace and time), which counts towards the daily limit of currently ten calls per workspace.
Source	Pasted in by the Customer.
Legal basis	Performance of the contract with the Customer (Art. 6(1)(b) GDPR) for the code itself; for third-party data contained in it by chance, the Customer determines the basis.
Recipients	None. The language model runs on our own scan server on the internal network; no external AI service, not even as a fallback.
Third country	None.
Retention	The code is not stored. A temporary file is created for the syntax check and deleted immediately afterwards. The entry in the activity log is deleted after 365 days.
Note to the Customer	Code containing passwords, API keys or personal data should be cleaned before it is pasted in. We do not check the content.
TOMs	Section 8. In particular: only owners and admins on paid plans; the pasted code is passed to the model marked as data and is never executed; no upload to third-party servers.

A.8 White-label brand and the agency’s contact persons

Field	Entry
Purpose	An agency’s (Business plan) reports, short reports, evidence logs and client portal appear under its brand, on request under a subdomain of the agency’s own.
Categories of data subjects	Contact persons at the agency whose name or contact details appear in the contact line.
Categories of personal data	Company name, website, contact line, note to the client, accent colour, appearance, logo file, switch for the reference to formexposed, own domain with verification identifier and verification status (workspace_branding).
Source	Entered by the agency.
Legal basis	Performance of the contract with the agency (Art. 6(1)(b) GDPR). Where the contact line names agency staff, the agency determines the basis.
Recipients	Anyone to whom the agency gives a report, short report or portal link.
Third country	None.
Retention	Until changed by the agency; brand and logo file go with the workspace (fe_arbeitsbereich_daten_loeschen()). An own domain whose DNS verification fails for seven days is switched off. The own domain is off by default.
TOMs	Section 8.

A.9 Counts, status indicators and field errors from the plugin and extension

Field	Entry
Purpose	Once a day, the WordPress plugin and the TYPO3 extension report figures about the forms on the connected website: blocked submissions per reason, submissions, sent and failed e-mails, status indicators of the form settings, stored enquiries per source and retention period. Optional, off by default: form events and field error categories per field position. These figures produce “Protection in numbers”, the monthly report, the silence alert and notices about risky settings.
Classification	The figures are designed so that they describe no person. We list them in Part A because they arise from events on the Customer’s website triggered by the Customer’s visitors; in our view they are personal data at most in borderline cases (a website with very few submissions on a given day). The transmission itself (keys, versions, host) is in Part B (B.20).
Categories of data subjects	Visitors to the Customer’s website who submit a form.
Categories of personal data	Daily figures per host: blocked in total and per reason, submissions, e-mails sent and failed, error category of e-mail sending (only one of four categories, never the error text, because it can contain recipient addresses), reCAPTCHA response counts, deleted and released enquiries (plugin_stats). Status: versions from a fixed list of form, CAPTCHA and mail plugins, setting indicators as numbers, retention periods (plugin_health). Change notifications: name and version of an updated plugin (plugin_changes). Optional: counters per form and day with error categories per field position (form_metrics). Never: input, field names, passwords, files, e-mail addresses, names, IP addresses or persistent identifiers of visitors.
Source	The plugin on the Customer’s website, via a programming interface using the website’s connection secret.
Legal basis (determined by the controller)	Determined by the Customer; the Customer decides whether to activate the optional counts and how to inform their visitors.
Recipients	The Customer. Domains from links in blocked messages go into swarm protection (B.21).
Third country	None.
Retention	Daily figures, change notifications and form counters after 13 months (nightly deletion run, parts “plugin_stats” and “form_metrics”). Status indicators are overwritten with every report. All plugin data for a host go as soon as no domain in the system refers to that host any longer (immediately on deletion of the last domain; legacy data nightly, part “orphan_hosts”).
What the figures prove	What the plugin counted. They prove neither completion rates nor lost enquiries.
TOMs	Section 8. In particular: acceptance only with the website’s bound key pair; only known keys and numbers are accepted, everything else is discarded; days outside a 14-day window are rejected.

A.10 Boundary: what stays only on the Customer’s website

The following functions of the WordPress plugin and the TYPO3 extension process data exclusively on the Customer’s server. They do not reach us, and we have no access to them. The website operator alone is responsible; the operator decides on activation, retention periods and how to inform their visitors. For this purpose the plugin suggests paragraphs for the operator’s privacy policy.

Function	What is processed locally	Retention on the Customer’s side
Quarantine	Stopped submissions with reason, releasable by e-mail to the website’s address	14 days
Safety net	Submissions whose form e-mail failed, for resending (on by default)	30 days
Arithmetic puzzle instead of reCAPTCHA	Arithmetic task in the visitor’s browser, no third-party service (off by default)	–
Retention settings	Deletion of stored enquiries in form plugins after the period chosen by the operator (off by default)	as configured
Rate limiting	a short-lived identifier derived from the IP address, not transmitted to us	short-lived
Local daily counters	Counter values before transmission	at most 14 days
Recorder for administrators	technical selectors and navigation steps in the session storage of a logged-in administrator’s browser; input is not read. Only the selected configuration is transmitted (then A.6)	at most 15 minutes
Visitor help	can be activated separately; stores no drafts and does not resend automatically	–
Observation of new spam rules	additional hits are counted locally, without automatic activation	seven days

A.11 Form protection (formconfirmed)

Field	Entry
Purpose	Assessment of submissions via forms on Customers’ websites in order to recognise automated submissions: issuing and verifying tasks (proof of work), single-use check tokens, time taken to fill in the form, trap field, repeated requests; at the Customer’s request, assessment of the message text by a language model. Only for Customers who switch on the form protection.
Categories of data subjects	Visitors to Customers’ websites who open a page with a protected form or submit it.
Categories of personal data	IP address (stored only shortened and hashed with a key that changes daily), address and domain of the page, times and time taken to fill in the form, trap field filled yes/no, browser identifier in the web server log; only with the content check switched on, the message text (in memory only).
Source	The visitor’s browser (task, check token); the Customer’s server (verification request, text where applicable).
Recipients	The Customer (score, action, reasons). No others; no sub-processors for this processing.
Third country	None.
Retention	Hashed identifier 1 hour; used check tokens 11 minutes at most; check results without IP address and without text 30 days; daily figures 400 days; web server log 14 days; text not stored.
TOMs	Section 8; in addition shortening and hashing with a daily key, signed tasks, single use, language model on our own hardware without logging the text.

4. Part A – recipients, sub-processors and third-country transfers

The following table lists the recipients that we ourselves engage and that may receive data from Part A. The authoritative, continuously updated list is the page Sub-processors; if it differs from this table, that is a finding, not a formatting issue.

Recipient	What it receives	Third country	Basis	Status
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Control mailbox of the delivery check (A.1); sending of alert e-mails (A.3), confirmations and reports to portal subscribers (A.2)	Place of processing still to be verified; see the page “Sub-processors”	Data Processing Agreement; transfer basis still to be verified	Open. The relevant contract, the actual places of processing and the transfer basis are not yet documented. This record confirms neither a certification nor a concluded contract.
Namecheap, Inc. (registrar, DNS; e-mail forwarding until the mailbox is set up)	Until the mailbox is set up, general incoming mail to addresses on our domain; not the copies from the delivery check, which only arrive with MX records pointing directly to the mailbox (A.1)	USA	to be verified: certification under the EU-US Data Privacy Framework or standard contractual clauses	In use; basis open.
Our own scan server with a local language model	Form structure for classification and selected findings with scan metadata for action plans in paid accounts (A.4), pasted code (A.7), decrypted test access only during the run (A.5)	–	Operated by us, not a third party	In use.
Independent probe at a second location	Domain, sanitised configuration, job identifier (A.6)	depending on location	to be determined before commissioning	Not set up.

Hosting: no third party. Application, database, screenshots and backups are held on our own servers in Poland. If we move to a data centre or cloud provider, this paragraph must be rewritten.

4.1 Alert channels chosen by the Customer

In addition to the recipients we engage, there are channels that the Customer chooses for their alerts (A.3). Our server triggers the transmission; the Customer determines the target and the provider. Choosing a channel does not relieve us of our own obligations as processor. Role, contract and the safeguards required for third countries must be determined for each provider; for the chat services this has not yet been completed (open question for the legal review).

Channel	What is sent	Provider’s seat
E-mail	Domain, event, explanation, link; to the address entered	via Namecheap, Inc. (Private Email), Phoenix, Arizona, USA
Webhook to a freely chosen address	Event as JSON (domain, events, lines, link, timestamp), signed with the target’s secret	determined by the Customer
Slack, Discord, Microsoft Teams, Google Chat	the same notification as a chat message to the webhook address entered	predominantly USA
Telegram	target chosen by the Customer; we send the message via our bot to the linked chat ID	outside the EU, no adequacy decision; transfer basis is an open question for the legal review

In no case is the content of a visitor message sent. The notifications carry domain, event and link.

5. Part B – Art. 30(1): processing under our own responsibility

Controller for everything in this part: LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, contact@lukaswojcik.com. No representative required (established in the Union). No data protection officer designated (section 9). Technical and organisational measures: section 8 and the page Technical and Organisational Measures. How data subjects exercise their rights is described on the page Access, Erasure and Your Other Rights; account holders can download their data themselves as a file (Settings).

Where we rely on legitimate interests (Art. 6(1)(f) GDPR), we name the interest and the reason why a less intrusive means is not sufficient. The balancing is our assessment; it is part of the legal review.

B.1 Visitors to our website – web server logs

Field	Entry
Purpose	Operation and security of the website and the app: delivery, troubleshooting, detecting attacks and overload.
Categories of data subjects	Everyone who opens a page of formexposed.com or form.exposed, including visitors to Customer pages whose browser loads our badge image (B.18), recipients who open a report or acknowledgement link, and websites whose plugin calls our interface.
Categories of personal data	Full IP address, time, requested address, status code, bytes transferred, referring page (referrer), browser identifier (user agent).
Where stored	Access logs of the upstream proxy and of the web server as files on the web server, not in the database.
Source	The browser or program making the request.
Legal basis	Art. 6(1)(f) GDPR. Interest: secure and uninterrupted operation. Balancing: without the full address, repeated requests from the same sender cannot be linked and attacks cannot be repelled; a truncated address does not support this distinction. The logs are not combined with other data and are deleted after a short period.
Recipients	None.
Third country	None.
Retention	14 days: daily rotation with 14 generations, then overwritten (system log rotation service, not the application’s nightly deletion run).
TOMs	Section 8.

B.2 Application page view log

Field	Entry
Purpose	Security and abuse detection (who requests what and how often), traceability of account access, simple usage statistics without an analytics service.
Categories of data subjects	All visitors to the website and users of the app on genuine page views (no background requests, no form submissions).
Categories of personal data	Full IP address, the country derived from it on writing (local geo database, no query to a third party), account ID for logged-in users, requested address and referring page (access tokens in them, such as those of report or portal links, masked), browser identifier and the device type, operating system and browser derived from it, language, time (access_logs). During “View as Customer” (B.14) no account ID is set, so that support’s page views do not appear in the Customer’s log.
Source	The browser’s request.
Legal basis	Art. 6(1)(f) GDPR. Interest: abuse prevention and traceability. Balancing: as B.1; the retention period is longer because abuse patterns become visible over weeks. Whether the IP address should be truncated or the retention period shortened is an open question for the legal review.
Recipients	None. Account holders receive their own page views in the data export.
Third country	None.
Retention	60 days (nightly between 03:00 and 03:05, srv/cron_status.php, setting “page view log”).
TOMs	Section 8. The IP address is taken from a forwarded header only if the request comes from our own upstream proxy, and then only the entry appended by that proxy; otherwise anyone could state their origin at will.

B.3 Cookies and storage in the browser

Field	Entry
Purpose	Technically necessary storage: session, protection against cross-site request forgery (CSRF), counting the limits for checks without an account, login, staying logged in on request, light or dark display.
Categories of data subjects	Visitors and users of formexposed.com.
Categories of personal data	Session cookie bpid (session identifier; ends when the browser is closed; HttpOnly, SameSite=Lax, Secure over HTTPS). Cookie bp_remember only after choosing “Keep me signed in” (selector and verifier; 30 days). Local storage bp_theme (light, dark or system). In the administration area, additionally local display settings of the operators. For the limits, a hash is formed from the session identifier; the identifier itself is not stored.
Not set	No analytics, advertising or tracking cookies. The partner programme (B.33) works without a cookie. The badge image on Customer pages sets no cookie (B.18). reCAPTCHA may set cookies from Google when a protected form is submitted (B.23).
Legal basis	Access to the terminal device: strictly necessary for the service requested by the user (§ 25(2) no. 2 TDDDG, the German Telecommunications Digital Services Data Protection Act; Art. 399(3) PKE, the Polish Electronic Communications Law (Prawo komunikacji elektronicznej)). Processing: Art. 6(1)(b) GDPR (account) and (f) (security, limits).
Recipients	None.
Third country	None.
Retention	Session; 30 days for the remember token. The nightly run deletes expired remember tokens in the database (remember_tokens); on logout, password change and revocation of a device, immediately.
TOMs	Section 8.

B.4 Free check without an account – acceptance, limits and abuse monitoring

Field	Entry
Purpose	Anyone can have a domain checked without an account. So that the input field does not become a weapon against third-party websites, tiered limits apply: one anonymous check per domain in seven days (after that, the same report), limits per IP address and per session in 24 hours, a daily limit for the whole system, a block on very young domains, blocklist and opt-out, public addresses only. Conspicuous patterns are recorded and reported to the operator. The limits per IP address, per session and for the whole system, each counted separately, also apply to the check from the plugin without an account (a plugin with a bound key pair counts per website instead of per address) and to the opt-out (B.30); the free header tool (B.9) has its own limits per IP address and day and for the whole system.
Categories of data subjects	People who trigger a check, a header tool request or an opt-out; servers on which a plugin is installed.
Categories of personal data	Log of every request: source (check, plugin, header tool, opt-out), full IP address, hash of the session identifier, checked host, country from the IP address, accepted or rejected with reason, time (check_throttle). Anomalies: type (IP address, session, country, system), key (for type “IP” the full IP address), pattern, severity, short description, times of detection and resolution, person resolving (abuse_flags). Job: host, mode, trust level and a truncated session hash as requester identifier (scan_jobs). Report: random identifier, host, language, expiry, first view, number of views (reports). Cached domain age from the registry lookup (domain_age_cache).
Source	The person’s input; their request; registry lookup (RDAP) for the domain age.
Legal basis	Performance of the requested check: Art. 6(1)(b) GDPR (use of the free check under the Terms of Service); in the alternative, (f). Limits and monitoring: Art. 6(1)(f). Interest: preventing the service from being used as a tool against third-party websites or as a spam cannon. Balancing: without linking to the address and the session, the limits could not be enforced; the seven-day period is as short as the longest limit counted from it.
Recipients	Google (reCAPTCHA on submission, B.23). For the domain age, the scanner queries the RDAP redirection service rdap.org, which forwards to the responsible registry; only the domain name is transmitted. When an anomaly occurs, the operator receives a signal via Telegram without any variable (no host, no address). The report can be seen by whoever has its random link.
Third country	USA via reCAPTCHA (B.23).
Retention	Request log 7 days (nightly, srv/cron_status.php). Resolved anomalies 90 days after resolution; unresolved ones remain until someone resolves them (section 10). Anonymous reports expire after 30 days; the nightly run then deletes report, job, check result, forms, findings and images (fe_reports_aufraeumen()). An administrator can manually release entries for an address; this deletes its log for the last 24 hours.
TOMs	Section 8. Emergency stop for all anonymous checks in the administration area; back-pressure that accepts no new free checks when there is a backlog.

B.5 Crawler check of third-party websites

Field	Entry
Purpose	Security check of public contact forms: safeguards against spam and abuse, data protection and accessibility features, embedded third-party scripts, behaviour after rejection in the cookie banner, mobile display. Applies to checks without an account (B.4), to domains in an account that are not yet verified, and as the basis for the study (B.7) and the prospect check (B.8). For verified domains in an account we act on the Customer’s behalf (A.4).
Crawler behaviour	Its own identifier with a reference to the crawler page; reads robots.txt before the check and stops if a disallow rule covers the home page (likewise if robots.txt cannot be reached or there is a server error); disallow rules for individual sub-paths are not observed separately. Form pulse, proof retrieval, header tool and the search for exposed files do not read robots.txt. At most eight public pages per check, plus up to three pages with a click on “Reject” in the cookie banner, up to three pages in phone view, active probes for verified domains and up to five pages behind a login (A.5); the pages are loaded one after the other, not in parallel; public addresses only, no internal networks, redirects are checked again; blocklist and opt-out are checked before acceptance and a second time in the scanner. Passive: without proof of control, nothing is submitted for Customers (exception: internal checks of our own test and demo domains, B.6).
Categories of data subjects	Operators of the checked websites (where they are natural persons, such as sole traders); people who happen to be visible on the checked pages.
Categories of personal data	As A.4: page addresses and titles, form structure (field names, types and labels, no field values), safeguards, third-party scripts (addresses; account IDs of pixels and recording tools are replaced before storage), cookie banner behaviour, screenshots (visible area of the home page, forms). If a recipient address appears in the form, only its domain (scans, forms, findings, scan_screenshots).
Source	Publicly accessible pages.
Legal basis	Art. 6(1)(f) GDPR. Interest: carrying out the requested security check; alerting website operators to weaknesses that may harm their visitors. Balancing: only what every visitor sees is read, to a small extent and without submitting anything; the operator can permanently exclude their domain at any time without proof. Information under Art. 14 GDPR is provided via the crawler page, the opt-out and the Privacy Policy; whether this is sufficient under Art. 14(5)(b) is an open question for the legal review.
Recipients	Whoever triggers the report and anyone to whom they give the random link; the local language model on our own server where the form type is unclear (form structure, page title and address, visible text of the form). Vulnerability warnings from plugin versions never appear in anonymous reports.
Third country	None.
Retention	Anonymous: 30 days (B.4). Prospect check: 90 days (B.8). Study: until publication (B.7). Domain in an account: at most 13 months, the last check remains; immediately with the domain. Internal checks by the operator without a domain and without a report (such as those created from the command line): no retention period (section 10). Temporary files on the scan server are deleted after every run.
TOMs	Section 8. In particular: separate check container with dropped privileges, read-only file system, memory limit and its own network; double target check.

B.6 Active test submissions

Field	Entry
Purpose	Checking whether a contact form accepts a submission without protection, whether CAPTCHA, trap (honeypot), token, e-mail address validation and rate limiting take effect on the server side, and whether headers can be injected.
Precondition	For Customers, only for domains for which proof of control has been provided (DNS record, meta tag, file or connected plugin); in addition, the operator uses an internal command-line tool to create checks with the level “verified” for our own test and demo domains. Only with the global switch on, only for a form reliably classified as a general contact form. Never for orders, bookings, registrations, newsletters, payments, file uploads, mandatory fields with real personal data, or domains of public authorities, healthcare or educational institutions.
Categories of data subjects	The Customer’s staff who receive the form e-mails.
Categories of personal data	The test submission contains no personal data: sender “FormExposed Security Scanner”, our own sender address or an address under .invalid, a labelled subject line and a text in the language of the page with a reference to the crawler page and opt-out and the check number. Stored by us: the page’s response, findings, an image of the follow-up page (as A.4).
Scope	At most five submissions per check (setting, default 5); recurring at the check frequency of the plan, daily in the highest plan.
Source	The Customer’s instruction.
Legal basis	Performance of the contract with the Customer (Art. 6(1)(b) GDPR); the submissions go to the Customer’s own form. For the recipients at the Customer’s end: the Customer’s organisation.
Recipients	The Customer (their form e-mail).
Third country	None through us.
Retention	Results as A.4.
TOMs	Section 8. Header injection is only detected, never carried out with a real recipient; the e-mail address validation uses only a domain that cannot exist.

B.7 Study “Form security index”

Field	Entry
Purpose	Statistics on the protection of contact forms in a country or sector. Only totals are published, without names of websites; segments only from 20 pages with a form.
Categories of data subjects	Operators of the websites on the list; incidentally visible people.
Categories of personal data	As B.5, passive only. In addition the list: host, segment, status, job (study_domains); study with title, country, result totals (studies).
Source	A list of public websites compiled by the operator; the pages themselves.
Legal basis	Art. 6(1)(f) GDPR. Interest: statistical statements on the state of form security. Balancing: passive, throttled (few jobs per run), blocklist and opt-out apply, publication only as totals, raw data are deleted.
Recipients	The public, totals only.
Third country	None.
Retention	Raw data (check results, forms, findings, images, jobs) are deleted on publication (fe_studie_veroeffentlichen()). The list of hosts with segment remains afterwards; there is no retention period for it or for studies that are never published (section 10). The operator decides which lists are checked and whether studies are published.
TOMs	Section 8.

B.8 Prospect check (acquisition mode for agencies)

Field	Entry
Purpose	An agency (Business plan) passively checks a prospect’s website and receives a short report under its brand and the passive report. We do not contact anyone; the agency passes on the link itself.
Categories of data subjects	Operator of the checked website; incidentally visible people; agency staff who trigger the check.
Categories of personal data	As B.5, passive only. In addition: workspace, person triggering the check, host, random identifier of the report, time (prospect_checks).
Source	The agency’s input; public pages.
Legal basis	Art. 6(1)(f) GDPR (our interest in providing the service and the agency’s interest in a well-founded approach). The roles of the agency and us and the agency’s obligations when passing on the report are open questions for the legal review: if the agency sends the report by e-mail unsolicited or makes a phone call, that is direct marketing requiring consent under Art. 398 PKE and § 7(2) UWG (the German Act against Unfair Competition), even between businesses. That is the agency’s responsibility; the Terms of Service oblige it accordingly.
Recipients	The agency and anyone to whom it gives the link.
Third country	None.
Retention	Report and check result expire after 90 days and are then deleted by the nightly run (fe_reports_aufraeumen()); the check entry is deleted after 90 days in the daily swarm run from 04:00 (srv/cron_status.php). With the workspace, immediately.
TOMs	Section 8. Monthly quota (setting, default 30); the same page within seven days returns the same report; opt-out applies.

B.9 Header tool without an account

Field	Entry
Purpose	Free grade (A+ to F) for the security headers of a domain’s home page. Two requests, no browser, no form, no submission.
Categories of data subjects	People who use the tool; operators of the checked domain.
Categories of personal data	Request log as B.4 (source “headers”, IP address, session hash, host). Result: host, grade, points, evaluated headers (header_checks).
Legal basis	Art. 6(1)(f) GDPR, as B.4 and B.5.
Recipients	Google (reCAPTCHA, B.23).
Third country	USA via reCAPTCHA.
Retention	Request log 7 days; results after currently 90 days (nightly deletion run, part “header_checks”, setting “headers_keep_days”). For domains in an account, the grade is redetermined daily and stored with the domain.
TOMs	Section 8. Limits per IP address and day; opt-out applies.

B.10 Customer accounts

Field	Entry
Purpose	Operating customer accounts, workspaces and plans.
Categories of data subjects	Customers (businesses) and their team members with their own account.
Categories of personal data	E-mail address and normalised form, password only as a hash, first name (mandatory), surname and company (where provided); the application does not store address and VAT ID, they are only provided at Stripe (B.26); status, language, display mode, currency, plan and billing status, Stripe customer and subscription ID, end of the billing period, cancellation at the end of the period, confirmation and reset identifiers with expiry, new e-mail address until confirmed, time of registration, last login and last IP address, time all sessions were revoked, two-factor data (B.11), monthly report on/off, time of the reminder e-mail, unlocks via codes, referral code and referral (users). Workspaces with name, times, status (workspaces); membership with role and date joined (workspace_users).
Source	Registration and settings by the person; billing status from Stripe.
Legal basis	Art. 6(1)(b) GDPR (contract). Last IP address: (f) (account security).
Recipients	Stripe (B.26); mail service provider for account e-mails (B.25). Members of the same workspace see the name, e-mail address and role of the other members.
Third country	Via Stripe and the mail service provider.
Retention	Until deleted by the account holder. On deletion, the holder’s own workspaces that nobody else uses go with all domains and their data; workspaces with further members pass to another member, first to administrators, and among them to the longest-standing. Memberships, remember tokens, devices, API keys, open Telegram codes, feedback on reports (B.35) and the account row are deleted; a running paid subscription is first ended immediately at Stripe, without a refund (www/ajax.php, fe_konto_reste_loeschen()). A cancellation in the billing area, by contrast, takes effect at the end of the period; after that, the account continues on the free plan. What remains is set out in section 6.4. Accounts never confirmed and never logged into are deleted after 30 days, unless another member is attached to their workspace (nightly deletion run, part “pending_accounts”). There is no deletion of inactive accounts. If the contract for the account ends in another way, for example by our termination, we delete the account no later than 30 days after the end of the contract; this is currently done manually (committed to in the Data Processing Agreement).
TOMs	Section 8.

B.11 Login, devices, second factor and activity log

Field	Entry
Purpose	Protecting accounts: limiting login and other password attempts, displaying and revoking logged-in devices, two-factor login, traceability of changes.
Categories of data subjects	Account holders and team members; people who attempt a login, a registration or the password of a client portal.
Categories of personal data	Login attempts: IP address, e-mail address entered, success, time (login_attempts). Devices: hash of the session identifier (never the identifier itself), link to the remember token, IP address, browser identifier and the browser, operating system and device type derived from it, times of login, last activity and revocation, and for “View as Customer” the support person’s identifier (login_sessions). Remember tokens for “Keep me signed in”: selector, verifier, expiry (remember_tokens). Two-factor: secret encrypted, time of activation, last time step used, recovery codes only as a hash (in users). Activity log: account, workspace, action, target, details, IP address, country, time (audit_logs). Attempt counters for login, the second factor, password confirmation, password reset, registration and passwords of client portals: an HMAC key derived from the purpose and the account ID (for an unknown address or for a reset, the lower-cased e-mail address), the IP address, account and IP address together, or the portal ID (also together with the IP address), number of attempts, expiry; e-mail and IP addresses are not stored there in clear text (table auth_attempt_buckets).
Legal basis	Art. 6(1)(b) GDPR in conjunction with Art. 32 (device list, second factor) and (f) (login attempts, activity log). Interest: protecting accounts against takeover, documenting changes (Art. 5(2)). Balancing: a truncated address does not answer the question “was that me?”; the activity log must outlast a dispute that arises only months later.
Recipients	None. The account holder sees their devices and receives login attempts, devices and activities in the data export; during a “View as Customer” session, neither the IP address nor the browser of the support person appears there.
Third country	None.
Retention	Login attempts 7 days; after a successful login, the failed attempts from the same address are deleted immediately. Attempt counters at the end of their time window (currently 15 minutes, one hour for password reset and registration); expired ones are deleted by the next access and by the nightly run. Devices 90 days after last use or after revocation (nightly deletion run, part “sessions”), immediately with the account. Remember tokens expire after 30 days. Activity log 365 days (nightly); when an account is deleted, its entries remain until the end of the retention period (section 6.4).
TOMs	Section 8.

B.12 Proof of contract conclusion

Field	Entry
Purpose	Proving which version of the Terms of Service, the Data Processing Agreement and the Privacy Policy a Customer accepted or took note of at registration, and that the Customer uses the service for their business.
Categories of data subjects	Customers.
Categories of personal data	Per document: account, document, version (hash of the displayed text), occasion, IP address, browser identifier, time (legal_consents). The displayed version itself with full text, language, title and address, once per version (legal_versions; contains no personal data).
Legal basis	Art. 6(1)(b) and (f) GDPR (proof of contract conclusion, defence against claims).
Recipients	None. The account holder receives their records in the data export.
Third country	None.
Retention	As long as the account exists; after the account is deleted, four years from the consent, then deleted nightly (srv/cron_status.php). Rationale in the code: three-year limitation period from the end of the year, rounded up. Whether Polish law suggests a different period is part of the legal review.
TOMs	Section 8. If any of the three documents is missing, registration is closed.

B.13 Team invitations

Field	Entry
Purpose	Inviting further people into a workspace.
Categories of data subjects	Invitees.
Categories of personal data	E-mail address, role, invitation identifier, inviting person, expiry, time of acceptance (workspace_invites); the invitation e-mail in the outbox (B.25).
Source	Entered by the inviting member.
Legal basis	Art. 6(1)(b) GDPR in relation to the Customer; towards the invited person (f) (the Customer’s interest in involving their team).
Recipients	Mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Third country	Via the mail service provider.
Retention	An invitation is valid for 14 days and only as long as the inviting person is owner or admin of the workspace. Invitations not accepted after expiry, accepted ones 30 days after acceptance (nightly, srv/cron_status.php and part “invites” in cfg/fristen_lib.php). With the workspace, immediately.
TOMs	Section 8.

B.14 “View as Customer” by support

Field	Entry
Purpose	A super admin sees the application as a Customer sees it, in order to resolve a support question (“the button is missing for me”).
Categories of data subjects	The Customer concerned; the super admin.
Categories of personal data	Everything the Customer sees in the application. Logged: a separate device row with the super admin’s identifier (login_sessions), start and end in the activity log (audit_logs).
Legal basis	Art. 6(1)(b) GDPR (support as part of the service), alternatively (f).
Limits	At most one hour, then complete logout. Ending the view also logs the super admin out completely, including the session they came from; they return to the administration area only by logging in again with password and second factor. Ends immediately if the super admin is downgraded or blocked. Everything that changes the Customer’s account is blocked: password, e-mail address, second factor, devices, subscription, export, deletion, transfer. The administration area is closed during the session. The Customer sees the access in their device list and in the data export as support access.
Recipients	None.
Third country	None.
Retention	Device row 90 days, activity log 365 days.
TOMs	Section 8.

B.15 Domains, proof of control and monitoring

Field	Entry
Purpose	The core service for Customers: holding domains in the account, providing proof of control, checking regularly and detecting changes. This includes the form pulse (a light request without a browser every 10 to 30 minutes depending on the plan), the daily mail DNS and certificate watch, the domain expiry date, blocklists, exposed files, versions visible from outside, script inventory, visual changes to the form, outages of CAPTCHA and mail providers, and the vulnerability watch for form plugins.
Categories of data subjects	Customers and their team members; operators of the domains, where they are natural persons.
Categories of personal data	Domain with host, public identifier, note, customer label, type and identifier of proof, check frequency, monitoring on/off, maintenance windows, enquiry value, identifiers for badge, delivery check and deploy hook, plugin key, states and latest results of the watches (DNS, certificate, authenticity of the form e-mail, blocklists, exposed files, headers, versions) (domains). Pulse per form page (form_pulse). Vulnerabilities from plugin versions (vuln_hits). Script inventory with address, hash, size, approval with approving person and reason (script_inventory, script_changes). Checks as A.4. For exposed files, path, severity and type are stored, never the content.
Requests to third parties	DNS queries (SPF, DMARC, MX, proof record). Registry lookup via RDAP according to the IANA directory: domain name only. DNS blocklists (SpamCop, PSBL, Mailspike, SURBL; Spamhaus only with stored access credentials, currently not): IP addresses of the web and mail server and the domain name, no visitor data. Google Web Risk only if set up (currently not): the address of the home page. Timestamping authority: only a hash value (B.19). WPVulnerability: only the identifier of a plugin or theme, or the WordPress version; we carry out the comparison with the installed plugin version ourselves. Status pages of Cloudflare, hCaptcha, Google Cloud, SendGrid, Mailgun and Brevo: nothing is transmitted except the request itself.
Source	Customer; requests to the Customer’s page; public directories.
Legal basis	Art. 6(1)(b) GDPR.
Recipients	The services named receive no personal data of our Customers, insofar as a business’s domain names and server addresses are not personal data; for sole traders, the domain name can be personal data. Members of the workspace see the domain.
Third country	The requests may reach services in third countries (such as registry lookups, blocklists). Only what is stated in the row “Requests to third parties” is transmitted.
Retention	Until the domain is deleted. fe_domain_loeschen() then immediately deletes check results, forms, findings, images, reports, jobs, alert targets and alert log, incidents, Telegram codes, deliveries, pulse, vulnerabilities and proofs; via foreign keys, monitored forms, browser runs, test account and form counters; the host’s plugin data if no other domain refers to it. Also deleted are the domain’s script inventory and script changes; they have no retention period of their own (section 6.4). Check results at most 13 months, the last one remains.
TOMs	Section 8. Watches for exposed files and versions only for verified domains, at most one request per path, only the first 8 KB; probing third-party paths unasked would be an attack tool.

B.16 Alerts, incidents and escalation towards the account holder

Field	Entry
Purpose	Informing the Customer about faults and changes, observing maintenance windows, acknowledging and escalating incidents. Where the targets are third parties, we act on the Customer’s behalf (A.3); where it is the account holder themselves, it is set out here.
Categories of data subjects	Account holders and team members as recipients.
Categories of personal data	As A.3. Notifications appear in the account holder’s language.
Legal basis	Art. 6(1)(b) GDPR.
Recipients	Mail service provider; chosen chat services (4.1).
Third country	Depending on the channel (4.1).
Retention	As A.3: delivery log 90 days, digest notifications 30 days after delivery, incidents until resolution and then 180 days. Alert targets with the domain.
TOMs	Section 8.

B.17 Monthly report to accounts

Field	Entry
Purpose	On the 1st of each month from 08:00 (catch-up until the 3rd), one e-mail per account covering all its domains: level, score and change, alerts, blocked bots, e-mail sending, comparison value.
Categories of data subjects	Active account holders with the monthly report switched on.
Categories of personal data	E-mail address, language, key figures of the domains.
Legal basis	Art. 6(1)(b) GDPR (part of the service). Can be unsubscribed in the settings; can be switched off centrally.
Recipients	Mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Third country	Via the mail service provider.
Retention	No separate storage; the e-mail stays in the outbox for 30 days (B.25).
TOMs	Section 8.

B.18 Badge and public confirmation page

Field	Entry
Purpose	A Customer can embed a badge image on their website and link it to a public confirmation page. The badge shows “Protected” only if the domain is verified, monitoring is running and the last completed check is at most 45 days old and resulted in “Protected” or “Partially protected”; otherwise it neutrally shows “Contact form check”. The confirmation page states the level and date, no individual findings.
Categories of data subjects	Visitors to the Customer’s website whose browser loads the image; visitors to the confirmation page.
Categories of personal data	When the image is loaded: IP address, time, requested address, referring page and browser identifier in the web server log (B.1). The image address starts no session, sets no cookie and does not write to the page view log. The confirmation page is a normal page (B.2, B.3).
Legal basis	Art. 6(1)(f) GDPR. Interest: delivering the image and keeping operations secure. Whether the Customer and we are joint controllers for the transmission of the visitor’s IP address, within the meaning of the case law on embedded third-party content, and whether an arrangement under Art. 26 is required, is an open question for the legal review. The Customer receives suggested text for their privacy policy.
Recipients	None.
Third country	None.
Retention	14 days (web server log). The image is cached for one hour. When the badge is switched off, the identifier ceases to be valid.
TOMs	Section 8.

B.19 Evidence log and timestamp

Field	Entry
Purpose	One log per domain and month (paid plans): what was checked, with what result, what was reported and what changed, as evidence for accountability, insurers or supplier audits. Each version receives a check number; a public page confirms domain, period and key figures, no details. Since 7 October 2026, a timestamping authority under RFC 3161 has confirmed the time.
Categories of data subjects	Customers; indirectly, people who may be named in the log as approvers or acknowledgers.
Categories of personal data	Domain, month, check number, content hash (SHA-512), summary and data of the log, timestamp response, timestamping authority and time, failed attempts (proof_docs).
Legal basis	Art. 6(1)(b) GDPR.
Recipients	The timestamping authority (default Certum, fallback DigiCert) receives only the hash of the log, not its content. Public: key figures via the confirmation page. The Customer and anyone to whom the Customer gives the log or check number.
Third country	No transfer of personal data: a hash allows no inference about the content. The fallback authority is based in the USA.
Retention	Until the domain is deleted (fe_domain_loeschen()). The timestamp is not a qualified timestamp under eIDAS.
TOMs	Section 8.

B.20 Plugin and extension: check, connection and transmission

Field	Entry
Purpose	The WordPress plugin and the TYPO3 extension can request a check (even without an account), connect to an account (installation counts as proof of control with one click in the account), unlock protection functions, report figures daily (A.9), and report e-mail errors and maintenance mode immediately.
Categories of data subjects	Customers; operators of websites who use the plugin without an account.
Categories of personal data	Per host: plugin and CMS version, number of checks, last report identifier, hash of the connection secret, first and last contact (plugin_sites). One-time connection codes as a hash with expiry (plugin_connect_tokens). An agency’s rollout codes as a hash with prefix, label, uses, creating person (workspace_connect_codes). Request log with the IP address of the calling server (B.4). The plugin key is publicly visible in the website’s head; it is a hash of the secret, and the secret itself is stored only as a hash and never returned.
Legal basis	Art. 6(1)(b) GDPR (account); without an account (f) (requested check, abuse prevention).
Recipients	None.
Third country	None.
Retention	A host’s data go as soon as no domain refers to it any longer; the row of a plugin without an account only after 90 days without contact (nightly deletion run, part “orphan_hosts”). One-time codes one day after expiry. Rollout codes with the workspace.
TOMs	Section 8. Since 27 September 2026 the server accepts only key pairs that are bound to the website; older, unbound connection secrets were deleted.

B.21 Swarm protection

Field	Entry
Purpose	Shared spam defence: connected websites report the domains of links in messages that their protection layer has stopped. A domain that appears on at least three websites with at least five hits within seven days is put on a list that goes back to all connected websites; their protection layer moves messages with such links into quarantine, never into oblivion.
Categories of data subjects	Holders of the reported link domains, where they are natural persons (such as the operator of a spam site under their own name). Not the senders and recipients of the messages: addresses, texts and names are not reported.
Categories of personal data	Signals: type, domain, reporting host, day, hits (swarm_signals). List: type, domain, number of websites and hits, times (swarm_list). Large services, our Customers’ domains and exceptions set by the operator are never listed.
IP networks	Sharing of IP networks (/24, /48) has been prepared. It is switched off and the plugin reports none; it will be switched on only after a legal review, because IP addresses are personal data.
Legal basis	Art. 6(1)(f) GDPR. Interest: protecting all Customers’ forms against waves of spam. Balancing: domains only, minimum thresholds against poisoning, no loss of messages, removal possible at any time.
Recipients	All connected websites (the list of domains).
Third country	Depending on the location of the connected websites; the list may also reach websites outside the EEA. It constitutes personal data only in borderline cases (domains of natural persons). The transfer basis under Chapter V GDPR for these cases has yet to be determined (open question for the legal review).
Retention	Signals 30 days (daily swarm run from 04:00, cfg/swarm_lib.php). The list is recalculated daily; whatever no longer reaches the threshold drops out.
TOMs	Section 8.

B.22 API keys, programming interface and MCP server

Field	Entry
Purpose	Access by the Customer’s own tools (REST API, Zapier, Make, MCP server for AI assistants) to the Customer’s domains, checks and incidents.
Categories of data subjects	Customers who create keys.
Categories of personal data	Key only as a hash, prefix, label, times of creation, last use and revocation (api_keys). Calls per minute (api_usage).
Legal basis	Art. 6(1)(b) GDPR.
Recipients	The tool that the Customer equips with the key; the Customer determines it.
Third country	Depending on the Customer’s tool.
Retention	Keys until revoked, immediately with the account; keys without an account (legacy data) nightly. Call counters after one day (occasionally cleaned up on a call).
TOMs	Section 8.

B.23 reCAPTCHA and our own form protection

Field	Entry
Purpose	Defence against automated access to our own forms: free check, header tool, opt-out, login, registration, forgotten and reset password, support and contact. In addition, our own protection without third parties: trap (hidden field), signed timing check and CSRF token. Since 29 October 2026 also our form protection formconfirmed (proof of work and single-use check token) for the free check, registration, login and “forgotten password”.
Categories of data subjects	People who submit these forms.
Categories of personal data	At Google: IP address, browser and device data, behavioural data, Google cookies. With us: Google’s assessment (score and action) only at the moment of the check, without storage, not even when a submission is rejected. With our own form protection: IP address (stored only shortened and hashed), page, times, trap field filled yes/no; no content.
Timing	Google’s script loads only when a protected form is submitted, not when the page is opened. Our own form protection fetches its task when the page is opened and computes as soon as the form is used. On the development system reCAPTCHA is switched off.
Legal basis	Art. 6(1)(f) GDPR. Interest: protection against bots, especially for the free check, which could otherwise be used against third-party websites. Whether access to the terminal device requires consent under § 25 TDDDG or Art. 399 PKE, even though the script loads only on submission, is an open question for the legal review. Our own form protection sets no cookies, stores nothing in the browser and creates no fingerprint; it is intended to replace reCAPTCHA in the long term.
Recipients	Google Ireland Limited; Google LLC. None for our own form protection.
Third country	USA (reCAPTCHA only). Basis: certification under the EU-US Data Privacy Framework or standard contractual clauses; to be documented in detail.
Retention	reCAPTCHA: no storage with us; at Google according to its rules. Own form protection: hashed identifier 1 hour, used check tokens 11 minutes at most, check results without IP address 30 days.
Outage	If Google does not respond within three seconds or responds unusably, the submission is rejected; so are an empty token and a response for an action other than the form’s. The check is skipped only when reCAPTCHA is switched off. With our own form protection, a submission without a valid check token is rejected; if the service was not reachable for the task, it is allowed.
TOMs	Section 8.

B.24 Support and contact form

Field	Entry
Purpose	Receiving and answering enquiries via the support window and the contact page. Both use the same route and the same table.
Categories of data subjects	Enquirers, logged in or not.
Categories of personal data	Account (if logged in; the account’s address then applies, not the one entered), e-mail address, reason from a fixed list, text up to 4,000 characters, status, full IP address, country, browser identifier, referring page (own paths only), language, times of receipt and reply (support_requests); entry in the activity log (without text); acknowledgement of receipt to the enquirer in the outbox (B.25), with the text up to 2,000 characters only for logged-in senders, without the text for requests made without logging in.
Legal basis	Art. 6(1)(b) GDPR where the enquiry concerns a contract; otherwise (f). Full IP address: (f) (limit of three enquiries per hour and address, abuse prevention).
Recipients	Mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for acknowledgement and reply. Telegram receives a fixed signal without any variable (“there is a new support request”) and thus no personal data.
Third country	Via the mail service provider.
Retention	24 months (nightly deletion run, part “support”); manually earlier. When an account is deleted, enquiries remain until the end of the retention period (section 6.4).
TOMs	Section 8. reCAPTCHA, our own form protection, rate limiting.

B.25 Sending e-mail (outbox)

Field	Entry
Purpose	Transactional e-mails: confirmation of registration and of new e-mail addresses, password reset, invitations, alerts, monthly reports, portal confirmations and reports, support acknowledgements and replies, reminders about the trial period and setup, operational notifications to the operators. No advertising, no e-mails to people who have not signed up themselves or been entered as recipients by the Customer.
Categories of data subjects	Recipients of these e-mails.
Categories of personal data	Recipient address, subject, complete content, reply-to address, purpose, sending route, status, error, attempts, times (mail_outbox). The content may include confirmation and reset links with valid identifiers.
Legal basis	Art. 6(1)(b) GDPR; for operational notifications (f).
Recipients	Namecheap, Inc. (Private Email), Phoenix, Arizona, USA (sending); the account holder sees their sent e-mails in the data export (without content).
Third country	Depending on the mail service provider’s place of processing; contract and transfer basis are still to be documented (section 4).
Retention	30 days (nightly, srv/cron_status.php). This period is deliberately the shortest of the logs: a long sending log would be a collection of valid keys. The status run checks every five minutes whether a retry is due.
Status	E-mail sending must be set up before launch. Until the mail service provider, with its seat and basis, has been settled, the legal texts show a marker.
TOMs	Section 8. Failed e-mails are retried at increasing intervals and abandoned after a maximum number of attempts.

B.26 Payments and billing

Field	Entry
Purpose	Concluding and managing subscriptions (monthly or annually in advance), 14-day trial period without a card with a reminder three days before the end, payment by invoice for annual subscriptions (off by default), unlocks via hoster and partner codes without payment, invoicing, retention for tax purposes.
Categories of data subjects	Customers.
Categories of personal data	At Stripe: e-mail address, name, billing address, VAT ID, payment data, invoices; as metadata our account ID and the plan. With us: Stripe customer and subscription ID, plan, status, end of period, cancellation at the end of the period (users); received Stripe events only with identifier, type, status and times, without content (stripe_events); redemptions of hoster codes with account, campaign and expiry (bundle_redemptions). Card data never reach us.
Source	The Customer in Stripe’s checkout; events from Stripe.
Legal basis	Art. 6(1)(b) GDPR; for retention for tax purposes (c).
Recipients	Stripe Payments Europe Limited (Ireland); Stripe, Inc. (USA). For parts of payment processing, Stripe acts under its own responsibility; the precise allocation of roles is part of the legal review.
Third country	USA via Stripe, Inc.; basis: Data Privacy Framework or standard contractual clauses under Stripe’s terms.
Retention	Billing fields with the account; a running subscription is ended before the account is deleted. Invoices and billing records under Polish tax law for five years from the end of the year in which the tax payment deadline expired; they are held at Stripe and can be retrieved in Stripe’s customer portal. Stripe events and code redemptions have no retention period (section 6.4).
TOMs	Section 8. Stripe events accepted only with a valid signature; each event is processed once.

B.27 Backups

Field	Entry
Purpose	Recovery after an error: wrongful deletion, damaged migration.
Categories of data subjects	Everyone whose data are in the database.
Categories of personal data	Complete, compressed dump of the application database. Screenshots and logo files are held outside the database and are not part of this backup. Test account credentials are contained in it only as ciphertext (A.5).
Procedure	Nightly at 03:00, after the deletion run, so that the backup does not take along what the retention periods have just deleted. The dump is kept only once its content has been checked (exit code, number of tables, final line). On Sundays, a restore test loads the latest backup into a throwaway database and compares it table by table. If anything fails, there is a signal and an e-mail to the operators.
Legal basis	Art. 6(1)(f) GDPR in conjunction with Art. 32(1)(c).
Recipients	None.
Third country	None.
Retention	14 days; older dumps are removed only after a successful new backup (cfg/backup_lib.php). Deletions that take place during this time reach the backup only when it expires; if data are restored from a backup, deletion requests are applied again afterwards.
Location	The backups are currently held at the same location as the database and are not separately encrypted; an encrypted copy at a second location is planned (sections 8.1 and 10).
TOMs	Section 8.

B.28 Error log and error alert

Field	Entry
Purpose	Finding and fixing errors before a Customer reports them. New error types and waves of errors are reported to the operators, plus a daily overview from 08:00.
Categories of data subjects	Users whose request causes an error; indirectly, people whose data appear in an error message.
Categories of personal data	Level, source, message, context as JSON, account ID of the session, time (error_logs). Error types: fingerprint, pattern (from which e-mail addresses, addresses, numbers and identifiers have been removed), one unaltered sample message of up to 2,000 characters, first and last occurrence, count (error_kinds).
Legal basis	Art. 6(1)(f) GDPR (operational security, Art. 32).
Recipients	The operators by e-mail via the mail service provider: for a new error type, source and raw text of the message up to 400 characters (not cleaned), plus the daily overview e-mail; for a wave of errors, only the Telegram signal goes out. Telegram receives only fixed sentences without variables (“A new error type has occurred”, “Many errors in a short time”).
Third country	Via the mail service provider.
Retention	Error log 90 days (nightly). Error types without a retention period (section 10). The error alert is on in the production system and off in the development system.
TOMs	Section 8.

B.29 Operational signals and status monitoring

Field	Entry
Purpose	Noticing outages: every five minutes a check of the components (home page, database, disk space, scanner heartbeat, queue backlog), status page, signal on a fault and on the all-clear, heartbeat to an external monitoring service so that even a complete outage is noticed; backlog in front of the scanner.
Categories of data subjects	None as a rule.
Categories of personal data	None. Daily rows per component with the number of checks and the last error (system_status_logs), scanner heartbeat (scanner_heartbeat), daily key figures without personal reference (daily_stats). The signals to Telegram are fixed sentences without variables; the heartbeat is a request without content.
Legal basis	Not applicable, as there are no personal data; as a precaution Art. 6(1)(f).
Recipients	Telegram (fixed sentences); the external monitoring service (the request only); the operators by e-mail.
Third country	Telegram outside the EU; no personal data are transmitted.
Retention	Status rows 400 days (nightly).
TOMs	Section 8.

B.30 Opt-out – excluding a domain

Field	Entry
Purpose	Anyone can permanently exclude any domain from checks without proof; the block takes effect immediately for all check routes (free check, plugin without an account, study, prospect check, header tool) and also for domains of paying Customers with proof of control; their ongoing monitoring ends with the next scheduled check. It applies to the domain and its www variant, not to other subdomains. It is lifted only by us, on request and with proof. So that abuse (such as a competitor blocking other people’s domains) can be detected and reversed, the block is logged.
Categories of data subjects	People who exclude a domain.
Categories of personal data	Domain, voluntary reason up to 250 characters, source, IP address, country, browser identifier, time; on lifting, time, person lifting the block and reason (blocklist). Request log as B.4.
Legal basis	For the exclusion, Art. 6(1)(f) GDPR. Interest: giving effect, permanently and across all check routes, to the wish that a domain not be checked. Where the excluding person is themselves a data subject, the exclusion at the same time gives effect to their objection under Art. 21 (Art. 6(1)(c)). For address, country and browser identifier, (f) (abuse detection).
Recipients	Google (reCAPTCHA, B.23).
Third country	USA via reCAPTCHA.
Retention	IP address, country and browser identifier after 12 months (nightly deletion run, part “optout_ip”). The exclusion itself remains permanently, so that it takes effect.
TOMs	Section 8. Many blocks from one country within a short time generate an anomaly (B.4).

B.31 Reminder after registration

Field	Entry
Purpose	A single e-mail two to 14 days after registration to confirmed accounts without a confirmed domain: “Add website” or “Confirm domain”. No offer, no price, no upgrade; with the note that it will not be sent again. Weekdays 09:00 to 18:00, at most 50 per run.
Categories of data subjects	New account holders.
Categories of personal data	E-mail address, language, time of sending (field “reminder sent” in users), domain and confirmation status.
Legal basis	Art. 6(1)(b) GDPR (note on setting up one’s own account). Whether the e-mail counts as a communication about the contractual relationship or as commercial information that would require consent (Art. 10 UŚUDE, the Polish Act on Providing Services by Electronic Means (ustawa o świadczeniu usług drogą elektroniczną); Art. 398 PKE; § 7 UWG) is an open question for the legal review; the operator can switch it off centrally.
Recipients	Mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA).
Third country	Via the mail service provider.
Retention	The time lives as long as the account; the e-mail 30 days in the outbox.
TOMs	Section 8. The time is set before sending, so that an abort does not trigger a second e-mail.

B.32 Telegram bot for Customer alerts

Field	Entry
Purpose	A Telegram chat is linked as an alert target: the Customer receives a link to our bot with a one-time code; when the recipient presses “Start”, our server reads the code from the new messages to the bot and stores the chat ID. No open endpoint on our side (webhook) is needed for this.
Categories of data subjects	Customers and the people whose Telegram chat is linked.
Categories of personal data	One-time code, domain, creating account, events, delivery mode, chat ID, times (telegram_links); the chat ID as a target (alerts). Telegram supplies further profile details with the message; only the code and chat ID are evaluated and stored.
Legal basis	Art. 6(1)(b) GDPR; for third parties as recipients, A.3.
Recipients	Telegram.
Third country	Outside the EU, no adequacy decision; the choice is made by the Customer (4.1). Basis and notice are open questions for the legal review.
Retention	A code is valid for 30 minutes; link rows are deleted after one day when a new code is created, open codes with the account and the domain. The chat ID as a target until the alert target or the domain is deleted.
TOMs	Section 8.

B.33 Partner programme and unlock codes

Field	Entry
Purpose	An account can refer new Customers via a referral code and receives a commission on their paid invoices for a limited number of months. The code travels in the address until registration; no cookie is set. Hosters and partners can issue codes that unlock a plan for a period without payment; one week before the end, the Customer receives a reminder.
Status	The partner programme is off by default until the Partner terms are in place.
Categories of data subjects	Partners and referred Customers.
Categories of personal data	Referral code, referring partner and time of referral (in users); commission with partner, Customer, Stripe invoice ID, amount, currency, commission, status, times (partner_commissions). Unlock with plan, end, source, reminder (in users); campaigns and redemptions (bundle_campaigns, bundle_redemptions).
Legal basis	Art. 6(1)(b) GDPR (partner agreement); for the Customer (f) (settlement of the commission, without passing the Customer’s data to the partner beyond the amount of the commission); tax records (c).
Recipients	The partner sees their commissions.
Third country	None.
Retention	Referral and unlock with the account. Commissions and redemptions have no retention period in the code; as accounting records, commissions are subject to retention for tax purposes (section 6.4).
TOMs	Section 8.

B.34 Vulnerability reporting point

Field	Entry
Purpose	Receiving reports of vulnerabilities in formexposed, under the rules on the Security page and in /.well-known/security.txt.
Categories of data subjects	Reporting persons; people whose data a report contains as evidence.
Categories of personal data	E-mail address, name, content of the report and attachments, as the reporting person sends them. The report reaches us by e-mail to the address stated there; the application does not store it.
Legal basis	Art. 6(1)(f) GDPR (security of the service, Art. 32); where a report contains third-party personal data as evidence, likewise (f), with the aim of closing the vulnerability.
Recipients	Mail service provider and, until the mailbox is set up, the domain forwarding at Namecheap (section 4).
Third country	Via the mail service provider and, until the switchover, the forwarding.
Retention	No retention period has been set or is technically enforced (section 10). The operator has yet to set the period; an obvious approach would be to delete third-party evidence once the vulnerability is closed and to treat the correspondence like support enquiries.
TOMs	Section 8.

B.35 Feedback on a report

Field	Entry
Purpose	Receiving feedback below a report (“Is something wrong in this report?”) to find errors in form detection. The superadmin classifies it (new, confirmed, fixed, rejected) and can download the check data of the report as a test case (forms with fields, reasons and findings, without screenshots and without actively sent texts).
Categories of data subjects	People viewing a report, signed in or not.
Categories of personal data	Category and check from fixed lists, page address up to 500 characters, text up to 1,000 characters, language, time, report identifier, check, host; account identifier if signed in; HMAC-SHA256 of the IP address with a secret key for the limit; status, handler, time handled (report_feedback). Activity log: status changes and downloads of a test case. No e-mail address, no IP address in plain text.
Legal basis	Art. 6(1)(f) GDPR (finding and fixing detection errors; limit against abuse).
Recipients	None.
Third country	None.
Retention	24 months (nightly deletion run, part “report_feedback”); the checksum of the IP address cleared after 2 days (part “report_feedback_ip”); immediately when an account is deleted. Downloaded test cases contain no data about the person reporting.
TOMs	Section 8. Own form protection (trap, signed time, CSRF), at most 5 reports per hour and 20 per day per checksum, 10 per report; readable by superadmins only.

6. Retention – what the nightly deletion run covers and what it does not

There is automatic deletion, and it has a place. A status run (srv/cron_status.php) is started every five minutes via the web server’s crontab, on the production system as on the development system. It checks the components, retrieves the delivery check mail, schedules checks and sends alerts. Once a day, in the window from 03:00 to 03:04, it deletes according to the retention periods and then creates the backup. Since 27 September 2026 it has additionally called the retention run in cfg/fristen_lib.php (fe_fristen_lauf()), whose parts run independently of each other: if one fails, the others continue, and the error is recorded in the error log.

Evidence that the run is running: the backup status of the development system shows a successful backup at 03:00 on 11 October 2026; the backup is created in the same block immediately after deletion. The run writes a log per deleted table only to standard output, which the crontab discards; there is no permanent record of what was deleted when (section 10).

The retention periods that appear as placeholders are set in the administration area under the retention settings. The run reads the same settings; the texts therefore always show the period after which data are actually deleted.

6.1 Covered by the daily run

Data	Retention period and trigger	Place in the code
Page view log (access_logs)	60 days	srv/cron_status.php
Activity log (audit_logs)	365 days	srv/cron_status.php
Error log (error_logs)	90 days	srv/cron_status.php
Outbox (mail_outbox)	30 days	srv/cron_status.php
“Keep me signed in” remember tokens (remember_tokens)	after expiry (30 days)	srv/cron_status.php
Invitations not accepted (workspace_invites)	after expiry (14 days)	srv/cron_status.php
Login attempts (login_attempts); attempt counters (auth_attempt_buckets)	7 days; counters when their time window expires (currently 15 minutes, one hour for password reset and registration), also on the next access	srv/cron_status.php
Request log of checks without an account (check_throttle)	7 days	srv/cron_status.php
One-time codes for connecting the plugin (plugin_connect_tokens)	1 day after expiry	srv/cron_status.php
Resolved anomalies (abuse_flags)	90 days after resolution	srv/cron_status.php
Expired reports together with check result, forms, findings, images and job (only without a domain in an account)	anonymous 30 days, prospects 90 days	fe_reports_aufraeumen()
Alert delivery log (alert_log)	90 days	fe_alert_log_aufraeumen()
Status rows (system_status_logs)	400 days	srv/cron_status.php
Consent records of deleted accounts (legal_consents)	once the account has been deleted and the consent is 4 years old	srv/cron_status.php
Orphans of deleted domains: check results, jobs, alert data, incidents, Telegram codes, deliveries, pulse, vulnerabilities, proofs, script inventory and script changes	immediately at the next run	fe_fristen_lauf(), parts “orphan_scans”, “orphan_rows”
Plugin data of hosts without a domain; plugin row without an account	immediately; row after 90 days without contact	part “orphan_hosts”
Header tool results (header_checks)	currently 90 days	part “header_checks”
Check results for a domain with forms, findings, images, reports, jobs	13 months; the last completed one per domain remains	part “old_scans”
Browser runs, completed browser jobs, time series (form_browser_runs, scan_jobs, form_performance)	13 months	parts “browser_runs”, “browser_jobs”, “form_performance”
Form counters (form_metrics), plugin daily figures and change notifications (plugin_stats, plugin_changes)	13 months	parts “form_metrics”, “plugin_stats”
Logged-in devices (login_sessions)	90 days after last use or revocation	part “sessions”
Accepted invitations	30 days after acceptance	part “invites”
Support requests (support_requests)	24 months	part “support”
Feedback on reports (report_feedback)	24 months; checksum of the IP address 2 days	parts “report_feedback” and “report_feedback_ip”
PDF versions of reports in the cache (var/pdf)	7 days	part “pdf_cache”
IP address, country and browser identifier in the opt-out (blocklist)	12 months; the exclusion remains	part “optout_ip”
Portal subscribers (client_subscribers)	unconfirmed 30 days; unsubscribed 3 years	part “subscribers”
Accounts never confirmed, together with workspace	30 days without login, unless another member is attached	part “pending_accounts”
API keys without an account (legacy data)	immediately	part “api_keys”

6.2 Outside the 03:00 window

Data	Retention period and trigger	Place in the code
Copies in the delivery check’s control mailbox	after processing, every five minutes	fe_zustellung_abholen()
Delivery check assignments (delivery_log)	180 days, on every retrieval	fe_zustellung_abholen()
Test account ciphertext in jobs (scan_jobs)	after the run, at the latest after one hour	scan server; fe_login_aufraeumen()
Incidents (alert_incidents) with their escalation delivery attempts	while unresolved; 180 days after resolution	fe_vorfaelle_aufraeumen() in cfg/vorfall_lib.php
Sent digest notifications (alert_queue)	30 days after delivery	cfg/kanal_lib.php
Swarm signals (swarm_signals)	30 days, daily from 04:00	cfg/swarm_lib.php
Prospect checks (prospect_checks)	90 days, daily from 04:00	srv/cron_status.php
Telegram link codes (telegram_links)	1 day, when a new code is created	cfg/kanal_lib.php
API call counters (api_usage)	1 day, occasionally on a call	cfg/agentur_lib.php
Resolved provider outages (provider_incidents), vulnerability cache (vuln_cache)	90 and 30 days respectively; no personal data	cfg/anbieter_lib.php, cfg/luecken_lib.php
Study raw data	on publication	fe_studie_veroeffentlichen()
Backups	14 days, after a successful new backup	cfg/backup_lib.php
Web server logs	14 days	system log rotation

6.3 On deletion by the Customer

• Deleting a domain (fe_domain_loeschen()): check results with forms, findings and image files, reports, jobs, alert targets, delivery log, digest queue, incidents, Telegram codes, deliveries, pulse, vulnerabilities, evidence logs, the domain from client portals with a fixed selection; via foreign keys, monitored forms with browser runs, observations and time series, test account, form counters; the host’s plugin data if no other domain refers to it. The domain’s script inventory and script changes are also deleted along with it; they have no retention period of their own (sections 6.4 and 10). Data left over without an associated domain from the period before 27 September 2026 are cleared by the nightly run (parts “orphan_scans”, “orphan_rows”).
• Deleting a workspace (fe_arbeitsbereich_daten_loeschen()): in addition, brand including logo, client portals including subscribers, rollout codes, prospect checks; plus invitations and memberships.
• Deleting an account: end a running paid subscription at Stripe immediately, without a refund; transfer or delete the holder’s own workspaces; delete memberships, remember tokens, devices, API keys with counters, open Telegram codes and the account row.
• Deleting a test account (fe_login_loeschen()): overwrite the ciphertext, delete the row, clear waiting jobs.

6.4 What the run does not cover

This list is the more important one. It names data for which there is no automatic retention period or which survive a deletion.

Data	What applies	Assessment
Account data including last IP address (users)	until deleted by the account holder; no deletion of inactive accounts	contract data; a rule for permanently inactive accounts without a subscription is missing
Activity log, page views, error log of a deleted account	remain with account ID and IP address until the end of their retention period	intended (evidence of actions even after termination); the ID no longer points to an account
Support requests of a deleted account	remain for up to 24 months with the old account ID	intended; the ID is not cleared
Consent records of a deleted account	until the consent is 4 years old (counted from the consent, not from the account deletion)	intended (section B.12)
Unresolved anomalies with IP address (abuse_flags)	until someone resolves them	open point (section 10)
Error types with unaltered sample message (error_kinds)	no retention period	open point (section 10)
Script inventory and script changes (script_inventory, script_changes)	no retention period of their own; kept as long as the domain exists and deleted with it	open point (section 10)
Subscribers of revoked client portals	until the workspace is deleted	open point (section 10)
Revoked API keys and rollout codes	until the account or workspace is deleted	hashes, prefix and label only; minor
List of study hosts (study_domains), studies never published	no retention period	open point (section 10)
Internal checks without a domain and without a report (check results, forms, findings, screenshots)	no retention period; no deletion route covers them	open point (section 10)
Commissions, code redemptions, Stripe events	no retention period	accounting relevance; period to be set under tax law
Cached domain age (domain_age_cache)	no retention period	domain name and registration date only
Authentication result of the form e-mail with sender domain	with the domain; overwritten on every receipt	see A.1
Exclusions in the opt-out	permanent	intended; without permanence, no exclusion takes effect
E-mails in the reporting point’s mailbox and in the general mailbox	no technical retention period	open point (section 10)

6.5 Outside the database

• Screenshots are held as files outside the web directory and are deleted with their check result (all deletion routes above also delete the files).
• Brand logo files are deleted when replaced and with the workspace.
• On the scan server, a temporary directory with result and images is created per job; it is deleted after every run, even after an error.
• Backups are held on the web server (B.27).
• Web server logs with the full IP address are kept for 14 days (B.1).

7. Automated decisions, profiling and assessment

formexposed assesses websites, not people. In our assessment, the service makes no decision that produces legal effects concerning a person or similarly significantly affects them (Art. 22(1) GDPR). There are, however, automated assessments and automatic blocks. We list them so that the classification can be checked.

Mechanism	What it does	Whom it affects
Score and verdict of a check	Weighted sum of missing protection layers (CAPTCHA, trap, token, timing check, ineffective CAPTCHA, known exposed configuration), 0 to 100; from this, “Exposed”, “Partially protected” or “Protected”. The website’s verdict follows the worst contact form recognised as such by the rules (not by the language model); without a contact form there is no verdict. The weights can be set in the administration area.	Website operators; for sole traders, indirectly a person. The verdict has no legal consequence; it is a finding with evidence and instructions.
Classification of the form type	Rules first, a local language model only if the rules return “unknown”. Decides whether an active test submission is permitted (only for a contact form reliably recognised by the rules). Forms classified by the language model are never submitted and do not count towards score and verdict.	The Customer and the recipients of their form e-mails; protective effect: when in doubt, nothing is submitted.
Prioritised action plan in paid reports	A local language model summarises selected failed or unclear findings and scan metadata as short numbered steps. Its text is labelled as an AI summary; the individual findings remain authoritative. It changes no scan score, verdict or website configuration.	The Customer or other authorised report reader, who decides which steps to take.
Badge	Shows “Protected” only under fixed conditions (B.18), otherwise neutral.	Customer; no effect on visitors.
Limits and blocks for the free check, header tool and opt-out	Reject requests if limits per address, session, domain or system are reached, if the domain is too young or of unknown age, or if it is on the blocklist.	Requesters; effect: a free service is refused for hours to days. An administrator can release an address; enquiries via the contact page reach a human.
Anomalies	Patterns (many domains from one address, bursts of requests, many rejections, many opt-outs from one country, daily limit reached) are recorded and reported. They do not block by themselves; blocks result from the limits.	Requesters.
Login lock	After currently eight failed logins from one address within 15 minutes, logins from that address are temporarily rejected. In addition, all login attempts, successful ones included, are counted per account and IP address (currently eight), per account across all addresses (considerably more, against distributed guessing) and per IP address (currently 80) within 15 minutes, as are second-factor codes (ten per account within 15 minutes); beyond that, attempts are rejected. Failed attempts from another address therefore no longer lock the owner out of an account. Password confirmations (five per account within 15 minutes), reset e-mails (three per address per hour, with an unchanged response), registrations (ten per IP address per hour) and attempts at the password of a client portal (ten per portal and IP address, 50 per portal within 15 minutes) are limited in the same way.	People logging in, registering or opening a client portal; effect limited in time, password reset remains possible.
reCAPTCHA threshold	Rejects submissions below a Google score; threshold per point of use (currently 0.7 for check and opt-out). Responses for a different action and submissions for which Google does not respond within three seconds are also rejected.	People who submit our forms; effect: a new attempt or the route via the contact page.
Swarm protection	Automatically puts a link domain on a list when minimum thresholds are reached; protection layers of connected websites move messages with such links into quarantine.	Senders of messages to Customer pages. Effect: the message is held back, not deleted, and can be released by the website operator. The decision about the message is made by the operator’s plugin on the operator’s website, not by us.
Comparison values	“Better protected than X % of checked sites”, only from totals of at least 20 hosts.	Website operators; no effect.

The closest thing to Art. 22 is the plugin’s protection layer on Customer pages, which automatically holds back submissions. It is processing by the website operator on the operator’s server (A.10). It deletes nothing but moves messages into quarantine, and the operator can release any message. No profiling of visitors takes place there or with us; there is no visitor identifier that links one message to another.

8. Technical and organisational measures (Art. 32) – general description

This section is the general description under Art. 30(1)(g) and (2)(d) GDPR. The detailed version is on the page Technical and Organisational Measures. Every measure below is evidenced in the code or in the configuration. Measures that have not yet been implemented are in the same section (8.1), so that the description is complete.

Area	Measure in effect
Transport encryption	HTTPS for website, app and interfaces; HSTS; session and remember-token cookies only over HTTPS, HttpOnly, SameSite=Lax.
Access control (authentication)	Passwords only as a hash, new ones with at least ten characters and at most 72 bytes; login lock after repeated failed attempts and attempt limits per account and IP address together, per account and per IP address, so that failed attempts from another address do not lock the owner out; attempt limits also for password confirmations, password reset (with the same response and response time), registrations and portal passwords; two-factor login (TOTP) with encrypted secret, protection against code reuse and hashed recovery codes; new session identifier on every login, identifiers not issued by the server are not accepted; “Keep me signed in” not for super admins, each token valid only once; changing the e-mail address invalidates an open reset link; devices can be revoked individually or all at once; the device list holds only the hash of the session identifier.
Access control (authorisation)	Roles per workspace (owner, admin, reader); permissions are checked against the object, never against an identifier from the form; test account, “Fix it for me” and active checks only for owners and admins; “View as Customer” limited in time and blocked for account-changing actions, ending it logs out completely, return to the administration area only with password and second factor; invitations valid only as long as the inviting person is owner or admin; addresses of webhooks and chat channels shown to readers only shortened to the host; the hostname of a verified domain cannot be changed.
Application security	CSRF tokens; prepared database statements; our own form protection (trap, signed timing check); reCAPTCHA on the public forms; rate limiting for support, checks and interfaces; only one “Fix it for me” call per workspace at a time, so that the quota also holds for simultaneous requests; Content Security Policy with framing protection that allows only scripts carrying the release (nonce) of the respective response to run; IP address from forwarded headers only from our own proxy and only from the entry it appended; access tokens masked in the page view log.
Secrets	API keys, rollout codes, plugin connection secrets, one-time codes and portal passwords only as a hash; test account credentials asymmetrically encrypted, private key only on the scan server; webhooks signed; Stripe events only with a valid signature.
Data minimisation	The delivery check stores no content and no full sender addresses; recipient addresses in forms only as a domain; account IDs in script addresses are replaced; plugin figures only from fixed lists; e-mail sending error texts only as a category; Telegram signals without variables; browser check images with masked input; no screenshots behind a login.
Isolation of the scanner	Every check in its own container: all Linux capabilities dropped, no privilege escalation, read-only file system, memory and process limit, its own network; target check against private and local networks before acceptance and in the scanner, also after redirects; service workers blocked, WebSocket connections closed. Requests by the web server (proof of control, header tool, file search, pulse, RDAP, certificates, webhooks and chat alerts) only on the customary web ports and only to exactly the address checked, webhooks and chat alerts only over HTTPS.
Storage	Screenshots outside the web directory, retrievable only via the report; reports at random addresses with noindex; backup directory readable only by the service.
Availability and recovery	Nightly backup with content check, weekly restore test, alert on failure; component check every five minutes with signal and e-mail; external heartbeat; emergency stop for anonymous checks; back-pressure when there is a backlog.
Traceability	Activity log for logins, changes, deletions, support access and approvals; error log with alert.
Deletion	Retention periods in one place in the code, from the same settings as the texts (section 6); deletion chains for domain, workspace and account, with the exceptions in section 6.4.
Data subject rights	One-click export of all account data as a file, based on an allowlist of fields, without secrets.
Organisation	Administration area only for accounts with super admin rights, blocked during “View as Customer”; development and production systems separated, the development system behind an additional access barrier; transfer of legal texts after approval via a tool that refuses drafts and placeholders.

8.1 Measures not yet implemented

• No encryption of the database at rest (measured on 11 October 2026). The exceptions are the test account credentials and the two-factor secret, which are encrypted at field level.
• Internal connections not encrypted throughout. Connections within our internal network are not encrypted throughout. Test account credentials travel there only as ciphertext.
• No backup at a second location. The backups are currently held at the same location as the database and are not separately encrypted; an encrypted copy at a second location is planned. Until then, they protect against a wrong deletion command, not against the loss of the location.
• Hardening of server administration not complete. The security of the administrative access to our servers does not yet meet the standard we intend for operation; hardening is continuing. We do not publish details, because they would help an attacker; we provide them to a supervisory authority on request.
• No functional read log in the administration area. Write actions are recorded in the activity log; who merely viewed which support request or which report can be determined only from the page view log (60 days).
• No permanent deletion log. What the nightly run has deleted is not recorded (section 6).
• No independent second check point. The probe at a second location is not set up (A.6).

9. Data protection officer – assessment under Art. 37 GDPR

Result: In our assessment there is no obligation to designate one. The assessment is part of the legal review and will be repeated as soon as any of the circumstances listed below changes.

Art. 37(1) requires a designation in three cases.

• Point (a) (public authority or body) does not apply.
• Point (b) (core activities requiring regular and systematic monitoring of data subjects on a large scale): our core activity is the regular, systematic checking of websites and forms, not the observation of people. We create no visitor profiles, use no tracking and link no message to another. The delivery check (A.1) passes real visitor messages through our mailbox, but evaluates only headers and the first 8 KB for assignment and stores no content; it observes delivery routes, not people. Customer accounts and logs are ancillary to the business activity.
• Point (c) (large-scale processing of special categories under Art. 9 or of data relating to criminal offences under Art. 10 as a core activity): not met. Special categories may occur incidentally in copies of form e-mails (A.1), on pages behind a login (A.5) or in pasted code (A.7); incidental capture is not a core activity.

Art. 37(4) allows national law to add further cases. We are having it confirmed by a lawyer whether Polish law requires us to designate one.

Triggers for a new assessment: activation of swarm protection with IP networks; a function that recognises visitors across several messages or websites; storage of content from the delivery check; a Customer whose forms predominantly concern special categories (health, job applications) with the delivery check switched on at large scale; the first employee with access to customer data. A voluntary designation remains possible; Art. 37 to 39 then apply in full.

Separately: whether a data protection impact assessment under Art. 35 is required for individual processing activities is answered by the page Data Protection Impact Assessment. Its threshold assessment concludes that a DPIA is required for swarm protection (B.21) and for studies at the intended scale (B.7) and is carried out by us, and that for the delivery check (A.1) it is required in the typical constellation, as an obligation of the Customer, whom we support in this.

10. Open points and planned measures

The following points are evidenced in the code, the schema or the configuration, not assumed. They describe the position as at the date of this version; the classification is our own and does not anticipate any legal evaluation. They are ordered by their weight for the data subjects, not by how easy they are to fix. The planned measures and their priority are set out in the Data Protection Impact Assessment.

Open point	What is evidenced	Significance
Mail service provider without a documented contract	For Namecheap, Inc. (Private Email), Phoenix, Arizona, USA, the contract, places of processing and transfer basis are not documented. Account e-mails, alerts and the control mailbox with real visitor messages run through this provider.	The relevant provisions are Art. 28(2) and (4) and Chapter V GDPR. Conclusion and documentation are planned before launch.
Bases for chat services and reCAPTCHA open	Alerts to Telegram (no adequacy decision), Slack, Discord, Microsoft Teams and Google Chat; reCAPTCHA without a consent request.	Open questions for the legal review; until then, notice and basis are not final.
Control mailbox may hold messages during disruptions	Deletion takes place after successful processing; if retrieval fails, the copies remain until the next successful run. There is no warning when a backlog builds up in the mailbox over a longer period.	The copies contain real visitor enquiries.
No backup at a second location, no encryption of the database at rest	Section 8.1. An encrypted copy of the backup at a second location is planned.	A single event at the location would affect data and backup at the same time; a stolen storage medium would be readable.
Unresolved anomalies without a retention period	Anomalies with the full IP address as key are deleted only 90 days after resolution; anything never resolved remains.	Relates to the principle of storage limitation (Art. 5(1)(e)); deletion depends on manual resolution. A fixed retention period is planned (measures of the Data Protection Impact Assessment).
Error types with sample message without a retention period	The sample message is stored unaltered up to 2,000 characters; the sanitised pattern removes addresses and numbers, the sample does not.	Error messages can contain e-mail addresses, host names or IP addresses.
Script inventory without its own retention period	Script inventory and script changes are deleted with the domain (FE_DOMAIN_TABELLEN), including when the workspace or account is deleted and in the nightly run for orphans; they have no retention period of their own. They contain script addresses, page addresses and, for approvals, the approving person and a free-text reason.	Relates to the principle of storage limitation (Art. 5(1)(e)); the change log with the approvals keeps growing as long as the domain exists.
Subscribers of revoked portals	A revoked portal is blocked, not deleted; its subscribers remain until the workspace is deleted.	The purpose (sending the report) ceased with the revocation.
Study lists without a retention period	After publication, hosts and segments remain; studies never published also keep their raw data.	The promise “raw data are deleted” applies only to published studies.
Internal checks without a deletion route	Checks with the trust level “internal” that have neither a domain nor a report (studies and checks created by the operator from the command line) are not covered by any deletion route; with them remain forms, findings and screenshots of third-party websites.	Relates to the principle of storage limitation (Art. 5(1)(e)); affects people who know nothing about the check. Assessed as high risk in the Data Protection Impact Assessment.
Proof of control is not renewed	Proof of control is checked once; there is no route in the code by which a domain loses it again.	Active test submissions, file search and the scan behind the login continue after a change of owner or mandate.
Scan behind the login: transport to the Customer’s page	As the login address, http is permitted alongside https, and certificate errors on the Customer’s page do not stop the login.	Test account credentials could be intercepted on the way to the Customer’s page.
Deletion depends on a time window	The daily block runs only if a status run starts between 03:00 and 03:04. If this one run fails (database unreachable, server restarted), that day’s deletion and backup do not happen; there is no catch-up. What was deleted is not permanently logged.	The retention periods are then silently extended by a day. A missed window triggers no alert; only a backup that runs and fails is reported. The setup list in the administration area shows the date of the last successful backup.
Some deletions depend on monitoring	Emptying the delivery check’s control mailbox, deletion of incidents, sent digest notifications, swarm signals and prospect checks, and clearing leftover test account copies in jobs run in the scheduler part of the status run, which works only while monitoring is switched on in the administration area; the delivery check assignments are deleted only while a control mailbox is set up.	If monitoring is switched off centrally or the mailbox is removed, these retention periods stop without anyone noticing.
Reporting point and mailboxes without a retention period	Vulnerability reports and other incoming e-mails are held outside the application; no retention period has been set.	Reports may contain third-party evidence.
Values of hidden fields are read during the check	The scanner reads the value of hidden form fields up to 24 characters and data attributes up to 60 characters in order to recognise timestamps and tokens. Only field name, type, label and the recognition result go into the field map and the findings, not the value.	No storage gap; the value is held only in the working memory of the scan container during the check. A pre-filled value (such as a customer number) is read in the process, but not stored.
Derived sender domain in the authentication result	A.1.	For visitors’ personal domains, personal data originating from a real message.
Hardening of server administration not complete; internal connections not encrypted throughout	Section 8.1. Hardening is continuing; we do not state details publicly.	A security incident at server level would affect application, database and backups at the same time.
Measurement on the development system	Schema, code and settings were measured on the development system.	Code and schema match the production system; settings may differ and must be checked again there before launch.

11. Upkeep of this record

Art. 30 requires the record to be maintained in writing and made available to the supervisory authority on request. That needs someone who is responsible for it and an interval at which it is checked against the system rather than against its previous version.

• Responsibility: Lukas Wójcik, owner. It is reviewed annually and whenever a processing activity changes.
• Events that require an update: a new or changed sub-processor, in particular the choice of the mail service provider; a new table or a new field with personal data; a change to the retention periods or the deletion chains in cfg/fristen_lib.php or srv/cron_status.php; a new alert channel or a new request to a third party; switching on a function that is off by default (swarm protection with IP networks, probe, own domains, partner programme, payment by invoice, Spamhaus or Google Web Risk); a move to other servers.
• Procedure: every statement here comes from code, schema or measurement. A review that only reads the text has reviewed nothing: schema and deletion chains are measured again, placeholders remain placeholders, open points are closed or carried forward with reasons.
• Relationship to other documents: this record does not replace the Privacy Policy, the Data Processing Agreement, the Technical and Organisational Measures or the list of Sub-processors. Where they and this record differ, the difference is a finding.
• Changes to this document are listed on the page Changes to the Contract Documents.