Data Protection Impact Assessment (Art. 35 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.1 · Last updated: 23 October 2026

1. What this is about and what this page is

This page is the data protection impact assessment (DPIA) of formexposed under Art. 35 GDPR. It first answers the preliminary question of whether a DPIA is required at all – for each processing operation separately, not for the service as a whole. Where the answer is yes, it carries out the assessment under Art. 35(7)(a) to (d): a systematic description, necessity and proportionality, the risks to the data subjects and the measures to address them. This is followed by the residual risk, the question of prior consultation under Art. 36 and the rules for review.

Art. 35 does not require a DPIA to be published. We publish it for two reasons. First, Customers who use the delivery check or the scan behind the login need facts that only we know for their own assessment; we owe them these facts as a processor in any case (Art. 28(3)(f) GDPR). Second, our crawler checks websites whose operators do not know us. They should be able to read which risks we see for them and for the people on their pages, and what we do about them.

Legal nature. This DPIA is documentation of the controller under Art. 35 GDPR, which we publish 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. Which services and safeguards 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 page. The page describes the position as at the date of this version. Risk ratings and assessments are 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. For Customers, the page is a basis for their own assessment, not legal advice.

This is the first version of the threshold assessment. It examines, processing operation by processing operation, whether a DPIA is required, and records the result in section 3.5.

Every statement of fact is subject to the same principle as in our other legal documents: measured, not intended. What is evidenced in the code or in the database is stated here with its source reference. What could not be evidenced is marked “not verified”. What is merely planned is called “planned”. We name open points openly, together with the planned measure; a DPIA that lists only strengths does not help the people it concerns.

Terms: an operator is whoever runs a checked website. A Customer has an account with formexposed. A visitor is whoever uses a Customer’s website, for example its contact form. A source reference means a file, function or setting in the source code, measured against the state of the development system on 11 October 2026.

We deliberately draw one line on openness: open points in securing our own servers are described only in general terms (R13). We name the risk and its level, but not the route to a specific vulnerability; we will provide the details to a supervisory authority on request.

2. Roles: who bears the obligation, and for what

Art. 35 places the obligation on the controller. formexposed is the controller for some processing operations, a processor for its Customers for others, and neither for the data that our WordPress plugin and our TYPO3 extension store on a Customer’s website. The answer to almost every question in this document depends on which role the question is asked about. The allocation follows the Privacy Policy and the Data Processing Agreement.

Processing operation	Role of formexposed	Who bears the obligation under Art. 35
Checking third-party websites without instructions from their operator: free check, prospect check for agencies, study	Controller	formexposed
Checking domains in the Customer account: monitoring, active test submissions, browser journeys, exposed files, form pulse	Controller for the Customer’s account and check data; processor for personal data of third parties visible on the Customer’s verified website; as long as a domain is not verified, controller as with the free check	formexposed for its own part; the Customer for third-party data on its website
Scan behind the login with a test account	Processor: the credentials and the content behind the login belong to the Customer’s website	The Customer; formexposed assists
Delivery check with control copy	Processor	The Customer; formexposed assists
Swarm protection: shared list of link domains from blocked spam	Controller: we combine the reports of many websites, compile the list and distribute it	formexposed
Customer accounts, login, logs, support, e-mail sending, payments, records of proof	Controller	formexposed
Client portal and monthly report to an agency’s subscribers	Processor	The agency
Data that the plugin and the extension store on the Customer’s website (quarantine, safety net, stored enquiries)	Neither: the data never leave the website	The operator of the website

This leads to a distinction that we state expressly, because it is often got wrong in both directions. Where formexposed is the controller, we carry out the assessment ourselves and bear its result. Where we are a processor, we cannot carry out the Customer’s assessment in its place, decide the question of necessity for it or consult the supervisory authority under Art. 36 on its behalf. What we can and must do there is supply it with everything it needs: the description under point (a), the measured facts on the risks under point (c) and an honest status list of the measures under point (d). For the delivery check and the scan behind the login, this page is exactly that.

A Customer that adopts the sections on the delivery check unchanged as its own DPIA has not carried one out. Whether the control copy is justified for its forms, whether special categories of personal data are to be expected there and how it informs its visitors are matters only it can decide. Section 11 summarises what needs to be clarified for that purpose.

3. Threshold assessment: is a DPIA required?

3.1 Art. 35(1) and Art. 35(3)

Art. 35(1) requires a DPIA where a type of processing, in particular using new technologies, taking into account the nature, scope, context and purposes of the processing, is likely to result in a high risk to the rights and freedoms of natural persons. Art. 35(3) names three cases in which this is in particular so. None of the three fits formexposed, and this should be reasoned rather than asserted:

• Point (a) – a systematic and extensive evaluation of personal aspects relating to natural persons which is based on automated processing and on which decisions are based that produce legal effects or similarly significantly affect them. We evaluate forms and websites, not personal aspects of people. The service makes no decision with legal effect on any person. The closest thing to it is swarm protection: messages containing a link to a listed domain end up in quarantine on the connected websites. That is an automated consequence for the message, not an extensive evaluation of a person; we deal with it under the criterion “Evaluation or scoring” in section 3.3.
• Point (b) – processing on a large scale of special categories under Art. 9 or of data relating to criminal offences under Art. 10. Not intended and not built. Such data can nevertheless reach us by one route: in the control copy of genuine visitor messages in the delivery check. That depends on the individual case and is not large-scale within the meaning of this provision; it is, however, taken into account in the risk assessment (R1).
• Point (c) – a systematic monitoring of a publicly accessible area on a large scale. This means the physical observation of places, not the retrieval of public web pages. Citing this provision as a hook for a website crawler would be incorrect.

The correct route is therefore Art. 35(1) itself, applied through the nine criteria of the Article 29 Working Party’s Guidelines on Data Protection Impact Assessment (WP248 rev.01, endorsed by the European Data Protection Board), and the list of the Polish supervisory authority under Art. 35(4) (section 3.4).

3.2 The nine criteria of the WP248 guidelines

The guidelines name nine features that indicate a likely high risk. As a rule of thumb, a processing operation meeting two of them will in most cases require a DPIA. A controller may reach a different conclusion in an individual case, but must then give reasons and document them. Conversely, a single criterion can be enough. On this page we use the following short labels:

1. C1 – Evaluation or scoring, including profiling and predicting, for example of performance at work, economic situation, reliability or behaviour.
2. C2 – Automated-decision making with legal or similar significant effect.
3. C3 – Systematic monitoring, i.e. processing used to observe, monitor or control data subjects, including through networks. The guidelines expressly justify this criterion by the fact that data subjects often do not know who is collecting their data and for what purpose.
4. C4 – Sensitive data or data of a highly personal nature: special categories under Art. 9 and 10, but also data whose disclosure significantly affects daily life, including electronic communications whose confidentiality should be protected.
5. C5 – Data processed on a large scale, measured by the number of data subjects, the volume and range of data, the duration and the geographical extent.
6. C6 – Matching or combining datasets originating from different processing operations or from different controllers, in a way that data subjects would not expect.
7. C7 – Data concerning vulnerable data subjects, for example employees, children, patients or other persons in an imbalance of power.
8. C8 – Innovative use or applying new technological or organisational solutions; in supervisory practice, the use of artificial intelligence is regularly treated as falling under this criterion.
9. C9 – Processing that prevents data subjects from exercising a right or using a service or a contract.

We rate each criterion as “met”, “borderline” or “not met” and give reasons for the rating from the code. A borderline case does not count as met in the total, but is named in the result; where several borderline cases point in the same direction, we include the processing operation in the assessment.

3.3 Assessment by processing operation

P1 – Free check without an account (checking any third-party website on request)

Anyone can enter a domain on the home page. The crawler then retrieves at most eight public pages of that website, reads the forms, takes screenshots and produces a report that anyone who knows its random link can see. The operator of the website learns nothing of this unless they notice the crawler’s identifier in their logs.

• C1 – borderline. The report rates the protection of a form with a level (“Exposed”, “Partially protected”, “Protected”) and a score. For a limited company this does not concern a natural person. For sole traders and freelancers, the domain can be attributed to the individual, and the level then says something about the care taken in their professional activity. What is evaluated, however, is a technical set-up, not the behaviour or characteristics of a person. We treat this as borderline.
• C2 – not met. Nothing is decided in relation to the operator. In relation to the person requesting the check, limits per IP address and session apply (cfg/check_lib.php); a rejected check has no significant effect.
• C3 – not met. It is a single retrieval on request, at most once per domain and week (cfg/check_lib.php, setting fc_domain_days = 7). No people are observed. The circumstance that the guidelines cite to justify C3 – the data subjects know nothing of the processing – is, however, present. It is taken into account in the risk assessment (R5).
• C4 – not met. What is stored is the form structure and findings, not entered values (scanner/src/crawl.js stores only the length of a value for visible fields). The scanner reads the beginnings of pre-filled hidden fields (up to 24 characters) and data attributes (up to 60 characters) only during the check, in order to detect tokens and timestamps; they are not stored. Screenshots may incidentally show people and names; the website of a medical practice shows its specialty in the image. These are public professional details, not health data of a specific person.
• C5 – borderline. The daily cap is 200 accepted checks (fc_daily_cap), i.e. arithmetically up to around 73,000 websites a year. Only a few items of personal data arise per website, and the duration is short (30 days). Measured on the development system, there are 2 anonymous checks in the data set. Not met today; borderline given the designed capacity.
• C6 – not met. Besides retrieving the pages, the service queries the age of the domain via the RDAP service rdap.org (only the domain name is transmitted; only the registration date is stored, cached) and resolves DNS. These are technical details about the domain, not a combination of datasets about people.
• C7 – not met.
• C8 – met, in a weak form. An automated browser checks the pages, and a language model on our own server classifies forms that the rules do not recognise (scanner/src/classify.js). The model sees the page title, address, field labels and up to 400 characters of form text. It can never make a form “submittable”.
• C9 – not met.

Interim result P1: one criterion in a weak form (C8), two borderline cases (C1, C5). No obligation under the rule of thumb. Because both borderline cases point in the same direction and the data subjects know nothing of the processing, we include P1 in the assessment.

P2 – Prospect check for agencies

An agency on the Business plan with its own brand set up can have a prospect’s website checked passively. It receives a short finding under its brand and a detailed report, and passes the link on itself (cfg/akquise_lib.php). We do not contact anyone.

• C1 – borderline, stronger than for P1. The short finding is expressly intended as a “door-opener for the first conversation”. The evaluation of the website thus becomes the basis for approaching a person commercially.
• C5 – not met. At most 30 checks per agency and month (prospect_monthly), deleted after 90 days.
• C8 – met, in a weak form (the same technology as P1).
• Other criteria – not met. The finding is presented with the agency’s brand, but not linked to other data about the operator.

Interim result P2: no obligation under the rule of thumb; included for the same reasons as P1 and because the purpose – client acquisition – carries a risk of its own (R6).

P3 – “Form Security Index” study

For a study, a list of websites is checked passively, throttled to at most five open jobs per run of the status process, which runs every five minutes (cfg/studie_lib.php). Only totals are published, and segments only from 20 websites with a form (study_min_segment, cfg/studie_lib.php). The raw data are deleted upon publication (cfg/studie_lib.php).

• C5 – borderline, met for large lists. The size of the list is not limited in the code; the throttling arithmetically allows more than a thousand checks a day. A study of a national market covers thousands of websites, many of them run by sole traders. From such a size onwards, we regard the criterion as met.
• C8 – met, in a weak form.
• C1 – not met. Although the individual website is rated, only the total is published; the rating does not serve to make a statement about the individual operator.
• Other criteria – not met.

Interim result P3: for studies of the designed size, two criteria (C5, C8). The study therefore reaches the threshold; formexposed carries out the assessment as controller. Measured on the development system, no study has been created so far.

P4 – Checking domains in the Customer account

The Customer has the domains in its account checked regularly. Once it has proven that it is entitled to control the domain, active test submissions (at most five per check), the search for exposed files and configured browser journeys are added.

• C3 – not met. The check is scheduled and recurring, but it concerns the Customer’s own website and is carried out at its request, not to observe people.
• C4 – borderline, no. The search for exposed files reads at most the first 8 KB from paths such as /backup.sql or a debug log in order to tell from the content whether the file really is exposed (cfg/dateien_lib.php). Such an extract may contain form entries made by visitors. It is checked only in memory and never stored; what is stored is the path, type and severity.
• C8 – met, in a weak form.
• Other criteria – not met.

Added action-plan stage. Eligible paid reports can contain locally generated advisory text based on selected findings and scan metadata. It is stored with the check and displayed with an AI notice; the individual findings remain authoritative. It does not automatically change websites or make legally or similarly significant decisions about people. The use of a language model alone does not determine whether a separate DPIA is required. Its inputs, recipients, scale and residual risks must be assessed with the underlying check, including possible repetition of personal data from URLs or notes and incorrect recommendations in a report shareable by link. Sections 7 to 9 below include this stage; no completed production measurement, owner approval or new residual-risk rating is asserted by this factual addendum.

Interim result P4: The underlying technical check does not reach the threshold on the facts described above. The added local advisory stage does not by itself establish a separate obligation, but the earlier threshold result is not a substitute for considering its actual input data, scale, recipients and effects. Included because the active test submissions and the file check depend on a proof that is never renewed (R7).

P5 – Scan behind the login

For a verified domain, the Customer can store a test account for its website. The scanner logs in with it and reads the forms on up to five specified pages of the members’ area (cfg/login_lib.php, scanner/src/login.js).

• C4 – borderline. Credentials are not data of a highly personal nature within the meaning of the guidelines, but their misuse opens up the members’ area. Depending on the website, confidential content may sit behind a login, for example in a members’ or patient portal. That depends on the Customer, not on us.
• C8 – not met. Automated logins are common in monitoring services.
• Other criteria – not met.

Interim result P5: no obligation under the rule of thumb. For Customers whose members’ area shows confidential content, this may change; the decision then lies with them. Included because of the security risks (R8).

P6 – Delivery check with control copy

The Customer enters a control address of formexposed as a blind copy in the mail settings of its form. As a result, every form e-mail also goes to our control mailbox – our test message as well as every genuine message from a visitor. An automated retrieval reads the headers and the first 8 KB, assigns the e-mail, evaluates SPF, DKIM and DMARC and deletes it (cfg/zustellung_lib.php).

• C4 – met. What visitors write into a contact form is electronic communication to a business with arbitrary content. On the website of a medical practice, a law firm, a counselling service or a school, data under Art. 9 or about children are to be expected. The guidelines expressly name confidential electronic communications under this criterion.
• C3 – borderline, rather met. Every message is copied according to plan and continuously and evaluated automatically, without the sender noticing. The purpose is to check the mail route, not to observe people. However, the circumstance by which the guidelines justify the criterion – data subjects do not know who receives their data – is fully present as long as the Customer does not inform its visitors.
• C7 – depending on the Customer. Patients, clients of law firms, job applicants, parents and pupils are often in a relationship of dependency towards the recipient of their message.
• C5 – borderline, no. Not large-scale for the individual Customer. At formexposed, the copies of many Customers converge in one mailbox; that increases the weight of a breach, not the number per controller.
• Other criteria – not met. The assignment to domain and test is not a matching of datasets about people; the technology is not new.

Interim result P6: C4 met, C3 borderline and rather met, C7 met for many typical Customers. In the typical constellation, two or more criteria are therefore met. A DPIA is required – as an obligation of the Customer, who is the controller. Sections 6 to 11 provide it with the facts for this.

P7 – Swarm protection

Connected WordPress websites report once a day the domains of links from messages that their protection layer has stopped. A domain that appears on at least three different websites with at least five hits within seven days is put on a shared list; the list is sent back to all connected websites, which then place messages with links to that domain in quarantine (cfg/swarm_lib.php).

• C6 – met. Reports from many mutually independent websites, i.e. from different controllers, are combined and returned to all of them as a shared list.
• C1 – met, insofar as a domain can be attributed to a natural person. The list is a classification as a source of spam. The guidelines name screening against a shared fraud database as an example of this criterion. Most domains on such a list belong to businesses or are throwaway domains; however, an individual’s domain may end up on it, rightly or through deliberately planted false reports.
• C9 – borderline. A message with a listed link does not reach the recipient immediately, but sits in their quarantine until they release it. It is not lost.
• C2 – not met. The quarantine is an automated consequence for a message, without legal effect and with human release by the recipient.
• Other criteria – not met. IP networks are switched off (swarm_ip_enabled = 0, cfg/swarm_lib.php).

Interim result P7: two criteria (C6, C1) and one borderline case (C9). The threshold is reached; formexposed carries out the assessment as controller. With IP networks switched on, C1 and C6 would be met without restriction; switching them on requires a new version of this assessment (section 12). Measured on the development system, there are neither reports nor list entries.

P8 – Customer accounts, login, logs, support, e-mail, payments

• C1 and C9 – not met. Conspicuous behaviour in the free check leads to a note with the IP address (cfg/check_lib.php) and, where applicable, to further checks being rejected. That is abuse prevention with little effect, not an evaluation of personal aspects.
• Other criteria – not met. These are the usual data of a service for businesses.

Interim result P8: no DPIA required. The processing operations are described in the Records of Processing Activities.

P9 – Plugin figures, field errors, recorder, badge, client portal, “Fix it for me”

• The plugin and the extension transmit daily figures, the plugin inventory and error categories, and the WordPress plugin additionally transmits link domains for swarm protection (on by default) (P7), no content, addresses, names or visitor IPs; the recorder holds selectors for at most 15 minutes in the administrator’s browser. No criteria met.
• When loaded, the badge transfers the usual connection data into the web server’s log, without a cookie. No criteria met.
• The client portal processes subscribers’ e-mail addresses with double opt-in on behalf of the agency. No criteria met.
• “Fix it for me” has pasted form code rewritten by a language model on our own server; the code is not stored. C8 in a weak form, nothing else.

Interim result P9: no DPIA required.

3.4 The list of the Polish supervisory authority under Art. 35(4)

The competent authority is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO). The President published the list of the kinds of processing operations requiring a DPIA in the communication of 17 June 2019 (Komunikat Prezesa Urzędu Ochrony Danych Osobowych z dnia 17 czerwca 2019 r. w sprawie wykazu rodzajów operacji przetwarzania danych osobowych wymagających oceny skutków przetwarzania dla ich ochrony, Monitor Polski 2019, item 666). The list assigns its entries to the criteria of the WP248 guidelines, gives examples and is expressly not exhaustive; it does not replace the assessment under Art. 35(1).

In our reading, the following kinds of processing on the list correspond in substance to processing operations of formexposed:

Kind of processing under the list (paraphrased)	Assigned criterion	Processing operation at formexposed	Assessment
Comparison, evaluation or inference based on the analysis of data from different sources	C6	P7 Swarm protection	applies
Evaluation or scoring, including profiling	C1	P7 Swarm protection; P1 and P2 as borderline cases	applies to P7
Processing of special categories of personal data	C4	P6 Delivery check	applies depending on the Customer
Innovative use or application of technological solutions	C8	P1 to P4 (language model for classification)	applies in a weak form
Large-scale processing	C5	P3 Study	applies to large lists
Systematic monitoring of publicly accessible places, including with recognition of features	C3	–	does not apply: places are meant, not websites

This allocation is a reading, not a quotation; the wording of the entries is to be checked against it in the legal review. It confirms the result of section 3.3 but does not change it. To our knowledge, UODO has not published a list under Art. 35(5) – processing operations for which no DPIA is required.

3.5 Result of the threshold assessment

Processing operation	Met	Borderline	Result
P1 Free check	C8 (weak)	C1, C5	not mandatory; included
P2 Prospect check	C8 (weak)	C1	not mandatory; included
P3 Study	C8 (weak), C5 for large lists	–	required (obligation of formexposed)
P4 Checking Customer domains	C8 (weak)	C4 (file check)	not mandatory; included
P5 Scan behind the login	–	C4	not mandatory; included; for the Customer depending on content
P6 Delivery check	C4; C7 depending on the Customer	C3 (rather met), C5	required (obligation of the Customer; this page assists under Art. 28(3)(f))
P7 Swarm protection	C6, C1	C9	required (obligation of formexposed)
P8 Accounts, logs, support, payments	–	–	not required
P9 Plugin figures, badge, portal, “Fix it for me”	C8 (weak, only “Fix it for me”)	–	not required

Result on Art. 35(1): A DPIA is required for individual processing operations of formexposed. It is required for swarm protection and for studies of the designed size, and formexposed carries it out as controller. For the delivery check it is required in the typical constellation, but as an obligation of the Customer; formexposed provides the basis. For the other checks of third-party and own websites it is not mandatory. We nevertheless include them, because they use the same technology, because several borderline cases point in the same direction and because the data subjects – operators without an account and people on checked pages – know nothing of the processing. No assessment is required for accounts, logs, support and payments.

Sections 6 to 10 therefore apply to P1 to P7. Where a statement applies to only one of these processing operations, it is marked as such.

4. Data protection officer: the assessment under Art. 37

No data protection officer has been designated. Art. 37(1) binds the controller and the processor alike; the question is therefore our own. The three statutory cases:

Art. 37(1)	Condition	Result
point (a)	Public authority or body	Not applicable; LW IT Solutions Company Lukas Wójcik is a private sole proprietorship.
point (b)	The core activities consist of processing operations which require regular and systematic monitoring of data subjects on a large scale	The core activity is the checking and monitoring of websites and forms, regularly and systematically. However, no people are monitored: the crawler does not observe behaviour, and the delivery check evaluates e-mails only for delivery and authenticity. Not met.
point (c)	The core activities consist of processing on a large scale of data under Art. 9 or 10	Not by design. Special categories may reach us through the control copy of the delivery check; that is incidental, not a core activity. Not met.

In our assessment, there is therefore no obligation to designate one. Whether Polish law requires a designation beyond this under Art. 37(4) is an open question for the legal review. Since no data protection officer has been designated, the advice under Art. 35(2) does not apply. If the legal review finds that there is an obligation to designate one, the advice of the data protection officer then designated will be sought before this assessment is approved (section 12). The contact person for questions about this assessment is the owner at contact@lukaswojcik.com.

5. Method, sources and limits of this version

The facts in this document come from the source code of the application and the scanner, from the database schema, and from row counts and settings of the development system, measured on 11 October 2026. The database and servers were accessed read-only. Where a measurement contradicts an intention – including a statement in our own legal documents – we report the measurement. We do not apply approved codes of conduct under Art. 40, compliance with which would have to be taken into account under Art. 35(8).

• The development system was measured. The service has not yet launched. The figures are therefore small and partly artefacts of testing: 112 checks, 110 of them without a Customer domain; 432 screenshots; 2 domains, 1 of them verified; no delivery check switched on; no test account stored for the scan behind the login; no study; no reports in swarm protection. Measurements are to be repeated before launch and at regular intervals thereafter.
• Not measured in this version and to be added before approval are: the configuration of the production system, including whether and how the control mailbox is set up and whether the key pair for the scan behind the login is set up there; whether the language model software logs requests; the state of server administration (R13); the contract with the e-mail service provider.
• It could not be measured how many genuine visitor messages will pass through the control copy and which sectors Customers will come from. Both determine the weight of R1 and R2 and are to be established after launch.
• The source references point to files and functions in the source code of the development system. What is decisive is the function described, not its location in the file.

This document is a draft. It has not yet been approved by the controller (section 12), and two of its conclusions – the assessment of scale for P1 and P3 and the weight of the delivery check – depend on figures that will only exist after launch.

6. (a) Systematic description of the processing operations and purposes

6.1 How the checking system is structured

formexposed runs on its own servers in Poland, without an external hosting provider: a web server with the application and the database, and a scan server with the checking service and a local language model, both in the same internal network. A check proceeds as follows:

1. The application creates a job in the database – subject to the limits and blocks set out in section 6.3.
2. The checking service on the scan server fetches the job, checks the blocklist, hostnames and, for anonymous checks, the age of the domain a second time, and starts an isolated container for exactly this job: its own network with its own filter rules, no special privileges, a read-only file system, memory and process limits, and a time limit (scanner/src/worker.js).
3. Inside the container, an automated browser retrieves at most eight public pages, first the home page, then preferably contact, imprint and support pages. Beforehand it reads robots.txt; an exclusion for FormExposedBot or for all crawlers that covers the home page ends the check, as does an unreachable robots.txt or a server error on retrieval (scanner/src/net.js). Prohibitions for individual sub-paths are not observed separately. Form pulse, proof retrieval, the header tool and the search for exposed files do not read robots.txt. In addition to the eight pages, there are 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; the pages are loaded one after another, not in parallel. Every request from the browser – including redirects and embedded content – passes through a filter that rejects private networks and other ports.
4. The container writes a result and the screenshots to a temporary directory. The checking service passes the result and the images to the application over the internal network and deletes the temporary directory, even after an error (scanner/src/worker.js).
5. The application processes the result, compares it with the previous check for Customer domains and reports changes to the destinations the Customer has set up.

6.2 What the crawler stores – and what it does not

Item	What is stored	What is not stored	Source reference
Pages	Address, HTTP status, headers, Content Security Policy, third-party hosts requested (at most 120)	Page content as text or HTML	scanner/src/crawl.js
Form fields	Type, name, label, placeholder, required field, visibility, length of an existing value	Field values; for hidden fields, the first 24 characters of the value are only read during the check (to detect tokens)	scanner/src/crawl.js
Recipient addresses in the form	only the domain	the address	scanner/src/crawl.js
Scripts	Inventory with checksum; addresses and opening text without account identifiers of advertising and analytics services	Account and pixel identifiers	scanner/src/crawl.js
Eavesdroppers	which advertising pixels and recording tools load before and after “Reject” is clicked in the cookie banner, and whether they mask inputs	Identifiers of the accounts with these services	scanner/src/mitleser.js, scanner/src/einwilligung.js
Form text	up to 400 characters go to the local language model if the rules do not recognise the type	Disclosure to third parties; storage of the text	scanner/src/classify.js
Screenshots (crawler)	visible area of the first page; for each visible form, an image of the form element	–	scanner/src/crawl.js
Screenshots (active check)	Image of the response page to the test submission; in addition the status, target address, title and the first 300 characters of its text	–	scanner/src/active.js
Screenshots (browser journeys)	Image of the form with blacked-out input fields, compressed, at most 32 KB	Inputs	scanner/src/browser.js
Behind the login	as for form fields above	Screenshots, cookies, links	scanner/src/login.js

Personal data are not contained in these items by design, but they are incidentally: the name of a contact person next to the form, a team photo on the home page, a telephone number in a label, the e-mail domain of an individual, a name in a placeholder. Behind the login, details of the test account and, depending on the website, of other users are added.

6.3 Who triggers a check, and what then applies

Trigger	Trust level in the job	Test submissions	Result accessible via	Deletion
Someone enters a domain on the home page (free check)	anonymous	no	Report under a random link	30 days, including images (cfg/check_lib.php)
Plugin or extension without an account	plugin	no	Report under a random link	30 days
Agency for a prospect	registered	no	Short finding and report under a random link	90 days (cfg/akquise_lib.php)
Customer, domain without proof	registered	no	Account; report under a random link	13 months, the last check is kept
Customer, domain with proof	verified	yes, at most five per check	Account; report under a random link	13 months, the last check is kept (cfg/fristen_lib.php)
Study	internal	no	only totals after publication	upon publication; without publication no time limit (R4)
Internal check from the command line by the provider	internal; for our own test and demo domains also “verified”	no; with the “verified” level yes (only our own test and demo domains)	internal only	no time limit (R4)

Several layers sit in front of the free check (cfg/check_lib.php): an emergency stop; reCAPTCHA; the same domain at most once in seven days (after that the existing report is shown); limits per IP address, per session (as a hash value, never the session identifier itself) and for the whole service per day; the blocklist from opt-out and robots.txt; the check that the domain points to public addresses; and a block for very new or unknown domains. Anomalies – many different domains from one IP address, many requests in a short time – are noted with the IP address and trigger a signal without content (cfg/check_lib.php).

6.4 Checking domains in the Customer account

The Customer proves that it is entitled to control a domain: by DNS record, meta tag, file or via our plugin (cfg/verify_lib.php). Only then is the domain treated as verified. The monitoring scheduler plans regular checks only for active, monitored and verified domains (cfg/monitor_lib.php).

• Active test submissions are tied to two gates: the application sets the active mode for Customers only for verified domains (for our own test and demo domains, the provider can create a check with the “verified” level via an internal command-line tool), and the checking service checks the trust level and the emergency stop fc_active_enabled again (scanner/src/worker.js). Only a form can be submitted that the rules recognise with high certainty as a general contact form, that has no required fields for real personal data and whose domain does not look like a public authority, educational institution, clinic, medical practice, police or court (scanner/src/classify.js). The language model cannot make a form submittable (scanner/src/classify.js). At most five submissions go out per check (fc_active_max_posts), clearly marked, with the sender dummy@formexposed.com, an address under .invalid to test e-mail validation and a harmless additional header line to detect header injection (scanner/src/active.js).
• Browser journeys check configured form journeys in a browser up to the point just before submission. Only GET and HEAD requests are permitted; everything else is aborted, as are addresses containing words for logging out, deleting, buying or paying (scanner/src/browser.js). For the check, required fields are filled with made-up values that never leave the browser.
• Exposed files are searched for weekly, only for verified domains, with at most one retrieval per path, at most 8 KB, and content never stored (cfg/dateien_lib.php).
• An independent second probe has been prepared and is switched off by default (browser_probe_enabled = 0). If switched on, it would receive only the domain, address, selector, steps and browser choice, never credentials, screenshots or visitor data (cfg/formular_probe_lib.php).

6.5 Scan behind the login

Prerequisites: the function is set up, the domain is verified, and the Customer is on a paid plan and is the owner or administrator of the workspace (cfg/login_lib.php); it confirms that the account is a test account with as few rights as possible (cfg/login_lib.php).

1. The username and password are immediately encrypted on the web server with the public key of the scan server: a one-time key per record (X25519), key derivation (HKDF-SHA256), AES-256-GCM, bound to the domain (cfg/login_lib.php). Only the checking service on the scan server has the private key (scanner/src/geheim.js). Anyone who has the web server, the database or a backup has only ciphertext.
2. The interface shows only the first character and the length of the username (cfg/login_lib.php). Credentials are never displayed, never logged and never output via the API.
3. For a check, the application attaches the ciphertext to the job. The checking service decrypts it, immediately clears the field in the job and passes the credentials to the container only via standard input, never as command-line arguments (scanner/src/worker.js). Remnants in aborted jobs are cleared by the status process after one hour (cfg/login_lib.php).
4. Inside the container, the browser logs in. It aborts if the login page redirects to another host, if the login form carries a CAPTCHA (we do not bypass CAPTCHAs) or if a password field is still visible after submission (scanner/src/login.js). It then clears the password field in the page’s memory and forgets the credentials (scanner/src/login.js).
5. It reads at most five pages of the same domain specified by the Customer. Addresses containing words for logging out, deleting, removing or cancelling are blocked (scanner/src/login.js). Nothing is submitted behind the login, no screenshots are taken, and cookies and links do not end up in the result (scanner/src/login.js).
6. Deletion is final: the ciphertext is overwritten with random data of the same length, the row is deleted and pending jobs are cleared (cfg/login_lib.php). When the domain is deleted, the row disappears automatically via a foreign key.

6.6 Delivery check

The delivery check answers the question of whether an e-mail from the contact form really arrives, and evaluates its authenticity features. It is optional, switched off by default and requires a control mailbox to be set up (cfg/zustellung_lib.php).

1. If the Customer switches it on, the domain receives a random tag. The Customer enters the control address with this tag as a blind copy in its form.
2. From then on, every form e-mail also goes to the control mailbox: our marked test submissions and all genuine messages from visitors. The e-mails go directly to the mailbox at Namecheap, Inc. (Private Email), Phoenix, Arizona, USA – they only arrive if the MX records of our domain point there; via forwarding, for example at the domain registrar Namecheap, Inc., they do not reach the mailbox – and remain there until they are retrieved.
3. The status process retrieves the mailbox every five minutes (srv/cron_status.php). For each e-mail, it reads the headers and at most the first 8 KB of the text, without marking them as read (cfg/zustellung_lib.php).
4. From the headers it determines the tag and thus the domain, and from the text, where applicable, the identifier of our test (cfg/zustellung_lib.php). What is stored is the time, the domain and, where applicable, the test identifier (cfg/zustellung_lib.php), for 180 days (cfg/zustellung_lib.php).
5. From the headers it evaluates SPF, DKIM and DMARC and stores the result against the domain: the check results, the domain of the sender address, the domains of the signatures and the address of the sending mail server (cfg/zustellung_lib.php). If the result deteriorates, an alert that can name the sender domain is sent to the Customer once (cfg/zustellung_lib.php).
6. It then marks every retrieved e-mail for deletion, including one that could not be assigned to any domain, and removes it from the mailbox at the end of the run (cfg/zustellung_lib.php). If the run aborts before that, the e-mails remain until the next successful run.
7. Only the copy of exactly the test in question counts as proof of delivery (cfg/zustellung_lib.php). If it does not arrive within three hours (delivery_wait_h), the service reports “Delivery missing”.

The text of genuine messages is never written to the database, and neither is the visitor’s address. Both are nevertheless read: the retrieval loads the first 8 KB of every e-mail into memory in order to search for the test identifier.

6.7 Swarm protection

1. The protection layer of the WordPress plugin stops a message as spam and counts the domains of the links in it. Once a day, the plugin reports these domains with their hit count to us, at most 60 per day; no addresses, no text, no IP addresses (cfg/swarm_lib.php).
2. Once a day we compile the list from this: a domain is put on it if it has been reported within seven days by at least three different websites and with at least five hits (swarm_min_sites, swarm_window_days, cfg/swarm_lib.php). Large services from a fixed exception list and our Customers’ domains, in each case including subdomains, never go on the list (cfg/swarm_lib.php).
3. The list goes to all connected websites with the response to the daily report. Their protection layer places messages with links to listed domains in quarantine, not in the bin.
4. Whatever no longer appears in the new list drops out; reports are deleted after 30 days (cfg/swarm_lib.php).
5. IP networks (/24 or /48) have been prepared but are switched off until the legal review is complete (cfg/swarm_lib.php).

6.8 Use of artificial intelligence

A language model runs on our own scan server, not with an AI provider. It is used in three places: in the checking service it classifies forms whose type the rules do not recognise; in doing so it sees the page title, page address, labels of the submit buttons, field types, names, labels and placeholders, and up to 400 characters of form text (scanner/src/classify.js). It is only asked if the rules return “unknown”; forms classified in this way are never submitted and do not count towards the score and the verdict. The score, verdict, abuse prevention, swarm protection and spam rules are fixed rules, not AI. In “Fix it for me”, it rewrites pasted form code; the code is not stored. For eligible checks of domains in paid accounts, it also generates a prioritised action plan from the hostname, overall result and score, CMS, relevant form type and page address, any identified plugin and selected failed or unclear findings. The request is temporarily stored in the internal job queue and deleted after collection or scheduled cleanup of entries more than one hour old. The generated text, language, status and timestamp are kept with the scan result under its retention rules. The report labels the plan as an AI summary and makes the individual findings authoritative; the plan does not change the website or the scan result. The model makes no decisions about people. More on this on the page EU AI Act: How formexposed Uses AI.

6.9 Legal bases

Processing operation	Legal basis
P1 Free check: checking the requested domain; limits and abuse prevention	in relation to the requesting person, Art. 6(1)(b); in relation to the operator and persons depicted, Art. 6(1)(f); abuse prevention, Art. 6(1)(f)
P2 Prospect check	Art. 6(1)(f) (legitimate interest of the agency and of formexposed)
P3 Study	Art. 6(1)(f)
P4 Checking Customer domains	Art. 6(1)(b) in relation to the Customer; for third-party data on its website, the Customer’s instructions under Art. 28
P5 Scan behind the login	Customer’s instructions under Art. 28; the Customer’s legal basis
P6 Delivery check	Customer’s instructions under Art. 28; the Customer’s legal basis (in our suggested text for Customers, Art. 6(1)(f))
P7 Swarm protection	Art. 6(1)(f) (joint defence against spam across many websites)

Our legitimate interest in P1 to P3 lies in showing operators and their service providers weaknesses in their forms before they are exploited for spam or abuse, and in providing the service. The data come from publicly accessible sources. The balancing of interests is set out in section 7; whether Art. 6(1)(f) supports checking third-party websites on request is an open question for the legal review.

6.10 Recipients and transfers to third countries

Recipient	What	Processing operation	Status
No one outside formexposed	Check results, screenshots, classification by the language model	P1–P5	The checking service and the language model run on our own servers; in the crawler’s checking path, no call to a third party was found other than to the checked website itself, to the services whose content it embeds (as with any visitor), and to the RDAP service rdap.org for the domain age (only the domain name); the monitoring watchers are listed in the next row
Anyone who knows the link	Report with findings and screenshots	P1, P2, P4	random link with 128 bits (cfg/check_lib.php), pages with noindex (www/report.php)
Services queried by the monitoring of a Customer domain	DNS blocklists (SpamCop, PSBL, Mailspike, SURBL): domains and IP addresses of servers, no visitor data; Google Web Risk only if set up: the address of the home page; timestamping authorities Certum and DigiCert: only a hash value of the evidence log; RDAP via the IANA registry: only the domain name; providers’ status pages: nothing is transmitted; wpvulnerability.net: identifier of a plugin (without version) or theme and the WordPress version	P4	in use; details in the Records of Processing Activities and on the page Sub-processors
Namecheap, Inc. (Private Email), Phoenix, Arizona, USA	Control copies including genuine visitor messages	P6	Contract not yet concluded; place of processing and transfer mechanism still to be examined
Namecheap, Inc. (USA)	Registrar and DNS; until the mailbox is set up, forwarding of general e-mails to addresses of our domain, not of the control copies (these reach the mailbox only via MX records pointing directly to it)	– (no control copies)	Transfer mechanism to be examined
Alert channels chosen by the Customer (e-mail, webhook, Slack, Discord, Microsoft Teams, Google Chat, Telegram)	Event, domain, link; for the authenticity check, the sender domain if it does not belong to the website	P4, P6	destination chosen by the Customer; partly outside the EU. We send Telegram messages via our bot; the transfer mechanism for this is an open question for the legal review
All connected websites	List of link domains	P7	via the response to the plugin
Second probe	Domain, form address, selector, steps	P4	switched off

6.11 Retention, measured, not intended

Deletion mostly takes place at night at 03:00 in the status process (srv/cron_status.php, cfg/fristen_lib.php); swarm protection reports and prospect rows are deleted daily from 04:00, delivery check assignments on every retrieval; anonymous and prospect reports are deleted via their expiry date (cfg/check_lib.php). Screenshots are deleted from disk together with their scan (cfg/fristen_lib.php).

Data	Period according to the code	Source reference	Finding
Free check including images	30 days	cfg/check_lib.php	effective
Prospect check including images	90 days	cfg/akquise_lib.php; srv/cron_status.php (prospect rows)	effective
Checks of a Customer domain	13 months; the last one is kept as long as the domain exists	cfg/fristen_lib.php	effective
Results of browser journeys including blacked-out images	13 months	cfg/fristen_lib.php	effective
Data of a deleted domain	immediately; orphans at night	cfg/fristen_lib.php (fe_domain_loeschen(), fe_fristen_lauf())	effective, including the script inventory and script changes, which have no retention period of their own beyond that (see Records of Processing Activities)
Study: raw data including images	upon publication	cfg/studie_lib.php	without publication, no time limit; the list of checked hosts remains without a time limit even after publication
Internal checks without a domain and without a report	none	–	no deletion; measured: 85 checks with 369 images since 22 September 2026 (R4)
Delivery check assignments	180 days	cfg/zustellung_lib.php	effective
Result of the authenticity check against the domain	until the next result or the deletion of the domain	cfg/zustellung_lib.php	overwritten, not time-limited
Control copies in the mailbox	until the next successful retrieval (five-minute interval)	cfg/zustellung_lib.php	copies and backups at the mailbox provider not verified
Credentials for the scan behind the login	until deletion by the Customer or of the domain; in the job at most until the end of the run, remnants after one hour	cfg/login_lib.php	effective; in backups only as ciphertext for up to 14 days
Reports in swarm protection	30 days	cfg/swarm_lib.php	effective
Limits of the free check (IP, country, session hash)	7 days	srv/cron_status.php	effective
Notes on conspicuous behaviour with IP address	90 days after resolution	srv/cron_status.php	unresolved notes without a time limit; measured: 3 notes, all resolved
IP address, country, browser relating to an opt-out	12 months; the exclusion remains	cfg/fristen_lib.php	effective
Database backups	14 days	cfg/backup_lib.php	effective; the backups are currently stored at the same location as the database and are not separately encrypted; an encrypted copy at a second location is planned (R13)

7. (b) Assessment of the necessity and proportionality

The yardstick is the stated purposes: to show operators whether their forms are protected against spam and abuse (P1 to P5), to check whether form e-mails arrive and appear authentic (P6), and to defend jointly against spam across many websites (P7). These purposes are legitimate. The question under Art. 35(7)(b) is narrower: is this processing necessary to this depth for the purpose, and is the interference proportionate to the benefit?

Component	Necessary for the purpose?	Proportionate in the form as built?
Retrieval of a few public pages, structure of the forms, detected protective measures	Yes. Without them there is no finding.	Yes. At most eight pages (plus the views from section 6.1), a prohibition of the home page in robots.txt is respected, no values of visible fields, recipient addresses only as a domain.
Screenshot per form	Yes, as evidence in the report: the operator can see which form is meant.	Largely. The fields are empty because the crawler types nothing in. The image does, however, show the surroundings of the form element without blacking anything out (R3).
Screenshot of the home page	Not required for the finding itself. It serves recognition of the checked website in the report.	Only to a limited extent; further minimisation planned. Home pages often show people: team photos, contact persons, customer testimonials with names. See R3 and section 9.3.
Reading the values of hidden fields (first 24 characters, only during the check)	Yes: tokens and timestamps are detected from them.	Yes. Only the detection result is stored, not the value, also behind the login (R8).
Response page to the test submission (image and 300 characters of text)	Yes, as evidence of how the form responded.	Yes. The response relates to our marked test message without personal data.
Classification by the language model	Useful, not necessary: without it, more forms remain “unknown”.	Yes. Local, without disclosure, without the right to submit.
Local action plan from selected findings and scan metadata	Useful for prioritising remediation, not necessary for producing the individual findings.	Limited to existing scan metadata and at most 18 distinct failed or unclear findings, without screenshots or entered field values in the prompt. The plan is advisory and labelled as AI-generated; the individual findings remain authoritative. URLs and notes may still contain personal data, and the generated text follows scan retention and bearer-link access. These limits reduce exposure but do not prove factual accuracy (R10).
Active test submissions	Yes. Whether a protection works only becomes apparent when it is tested.	Yes, with a cap and marking. The precondition – proof of control – is, however, never renewed (R7).
Search for exposed files	Yes for the Customer, whose form data may be exposed there.	Yes. Only verified domains, at most 8 KB, content never stored.
Scan behind the login	Yes for forms in the members’ area that would otherwise remain unchecked.	Largely. Encryption and deletion are carefully built; the login, however, accepts unencrypted connections and faulty certificates (R8).
Control copy of genuine visitor messages	Not for proof of delivery. That relies only on the copy of our test (cfg/zustellung_lib.php). Genuine messages come along because a blind copy in the form does not distinguish between a test and a genuine message. They are useful for the authenticity check (SPF, DKIM, DMARC) because they show the actual sending route.	Partly. Content is not stored but is read, and it remains with the mailbox provider, whose contract is still open, until retrieval (R1, R2). A less intrusive design is technically possible: with our plugin, the blind copy could be limited to marked test messages (section 9.3).
Storage of the sender domain of genuine messages	Partly: it shows whether the form sends with the visitor’s address as the sender (a frequent cause of being classified as spam).	Conditionally. For an individual with their own domain, the domain is personal data, and it goes in the alert to the Customer and its channels (R1).
Shared list of link domains	Yes. A spam link that appears on many websites at the same time is a strong signal that a single website does not have.	Yes, with minimum numbers, exceptions and quarantine instead of deletion. IP networks would not be proportionate without a new assessment.
Raw data of the study	Until evaluation, yes.	Without a maximum period, no (R4).
Report under a random link	Yes. Passing the report on – for example to the service provider that looks after the website – is the purpose of the free check.	Yes. Random link with 128 bits, noindex, free report only as an extract (cfg/check_lib.php, FE_FREE_DETEKTOREN), deletion after 30 days.

Lawfulness. For P1 to P3 and P7 we rely on Art. 6(1)(f). In favour of the balancing: the data are public and are retrieved in the same way any visitor does; nothing is submitted; personal data are incidental and minor; the periods are short; the operator can exclude further checks by the crawler through a prohibition of the home page in robots.txt and any further check through our opt-out page, immediately and without proof; the benefit – a protected form – also accrues to the operator and its visitors. Against it: the operator learns nothing of the check, the report is intended for third parties, and in the case of sole traders it evaluates a person. We consider the balancing to be justifiable as long as the measures from section 9.1 remain in place; legal confirmation is pending.

Information to data subjects (Art. 13 and 14). We inform operators and people on checked pages through the crawler page, which is named in the identifier of every retrieval, through the Privacy Policy and through the opt-out page. Informing people who incidentally appear in a screenshot individually would only be possible if we identified them – which would be a further, more serious interference. To that extent we rely on Art. 14(5)(b). Visitors whose messages pass through the control copy are informed by the Customer; the Data Processing Agreement requires this, and we provide a text block for it.

Data minimisation (Art. 5(1)(c)). It is visible in many places and grounded in the code: no field values, recipient addresses only as a domain, account identifiers in script addresses hidden, no content from the control copy in the database, no screenshots behind the login, only domains in swarm protection. In two places, further minimisation is possible and planned (section 9.3): for the home page screenshot without blacking out and for the sender domain of genuine messages.

Storage limitation (Art. 5(1)(e)). Since 27 September 2026, the nightly run has complied with the periods in the Privacy Policy for Customer data and clears data left over without an associated domain from the period before that (cfg/fristen_lib.php). Two routes without a time limit remain open: internal checks and unpublished studies (R4).

Accuracy (Art. 5(1)(d)). A finding can be wrong: a form appears unprotected because the protection only loads after an interaction, or the crawler was treated differently by a firewall than a visitor. For an operator whose website is publicly passed around as “Exposed”, this is a question of reputation. The report therefore names the method, shows evidence and points out the limits of a check from the outside.

Result on proportionality: Checking third-party and own websites is, in its form as built, essentially proportionate. In three places there is a need for improvement that can be remedied by ordinary means and for which measures are planned (section 9.3): the screenshots of the home page, the internal checks without a time limit and the unencrypted login for the scan behind the login. The delivery check is proportionate for the test copy and for the authenticity check; for genuine visitor messages it holds only as long as their content is not stored, the route via the mailbox provider is contractually secured and the Customer informs its visitors. Today, the second of these three points is missing.

8. (c) Assessment of the risks to the rights and freedoms of data subjects

What is assessed is the risk to the data subjects, not to formexposed. Likelihood is rated as remote, possible, likely or materialised; “materialised” means that the event is not a forecast but a measured state. Severity is rated as limited, significant, serious or very serious, depending on what the person stands to lose: the confidentiality of their message, control over an account, their business reputation, the ability to exercise a right. The level results from both and describes the current state with the measures from section 9.1.

No.	Risk	Processing operation	Likelihood	Severity	Level
R1	Genuine visitor messages in the control copy, including possible special categories	P6	Materialised once switched on	Serious	High
R2	Route of the control copy via the mailbox provider without a concluded contract and with a possible third-country link	P6	Likely as long as the contract is missing	Serious	High
R3	Screenshots of third-party websites without blacking out	P1–P4	Likely	Limited	Medium
R4	Check data and screenshots without a deletion route	P3, internal checks	Materialised	Significant	High
R5	Checking and public rating of third-party websites without the operator’s knowledge; misuse as a reconnaissance tool	P1	Possible	Significant	Medium
R6	Prospect check as a basis for unsolicited approaches	P2	Likely	Limited	Medium
R7	Proof of control is never renewed	P4, P5	Possible	Significant	Medium
R8	Credentials and content in the scan behind the login	P5	Possible	Serious	Medium; high for real accounts
R9	Active test submissions and file check on the Customer’s website	P4	Remote	Significant	Low
R10	Classification by a language model	P1–P4	Remote	Limited	Low
R11	Shared blocklist from reports by many websites	P7	Possible	Limited	Low to medium; high with IP networks
R12	Reports and screenshots under a public link	P1, P2, P4	Possible	Limited	Low
R13	Infrastructure weaknesses: backups, server access, scan server	all	Possible	Serious	High
R14	Data subject rights for people who do not know us	P1–P6	Likely	Limited	Low

R1 – Genuine visitor messages in the control copy

This is the most serious risk of the service, and it arises not from an error but from the design. A blind copy in the form does not distinguish between our test message and a visitor’s message. If a Customer switches on the delivery check, every message sent via that form reaches our control mailbox (cfg/zustellung_lib.php). The retrieval reads the headers and the first 8 KB of the text into memory in order to search for our test identifier (cfg/zustellung_lib.php). For an ordinary contact form, that means name, e-mail address, telephone number and the complete message.

What the visitor writes is up to them, and the field invites personal content: an appointment request describing symptoms to a medical practice, an account of a legal dispute to a law firm, a job application, an enquiry about a child to a school. Our legal documents say that copies “should not contain any special categories of personal data”. That is a request to the Customer, not a protective measure: neither it nor we know in advance what a visitor will write.

Two side routes belong to this. First, the authenticity check stores the domain of the sender address against the domain (cfg/zustellung_lib.php). If the form sends with the visitor’s address as the sender, this is the visitor’s domain – meaningless for a large mail provider, but personal data for an individual with their own domain. This domain also appears in the alert that goes to the Customer and to the channels it has chosen (cfg/zustellung_lib.php). Second, it stores the address of the sending mail server (cfg/zustellung_lib.php); as a rule, this is the website’s server, not the visitor’s.

Likelihood – materialised once switched on. The question is not whether genuine messages arrive, but how many. Measured on the development system, the function is not switched on for any domain. Severity – serious. The confidentiality of a message to a business matters to many people, and data under Art. 9 are to be expected for some of the typical Customers. The severity is mitigated by the fact that the content does not end up in the database, remains in the mailbox only briefly and is not read by any person at formexposed. Level – high.

R2 – Route of the control copy via the mailbox provider without a concluded contract

Before our retrieval sees a control copy, it is held in the mailbox at Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. It only arrives there if the MX records of our domain point directly to this mailbox; forwarding at the domain registrar Namecheap, Inc. is not a station of the control copies (via forwarding they do not reach the mailbox). For the station that remains, the contractual arrangements are still open: the contract with the mailbox provider has not been concluded, its storage locations, sub-processors and backup periods have not been established, and whether an adequacy decision or standard contractual clauses are required for its place of processing and apply is open. For our own transactional e-mails, this is a matter of contract design. For the control copies it is more serious: there these are data we receive as a processor, and every service provider along the route is a sub-processor for whom we are liable under Art. 28(4).

In addition, “deleted after retrieval” applies only to our view of the mailbox. Whether the provider keeps deleted e-mails in its own backups or in a bin, and for how long, has not been verified. If a retrieval aborts, the e-mails remain until the next successful run (cfg/zustellung_lib.php); if the status process fails, they remain indefinitely. Finally, securing the retrieval itself is one of the points to be checked on the production system before launch (section 9.3).

Likelihood – likely as long as the contract is missing: every control copy takes this route. Severity – serious, for the same reasons as R1. Level – high. The application’s set-up checklist reports the missing mailbox as a warning; there is no lock that blocks the delivery check without a documented contract.

R3 – Screenshots of third-party websites without blacking out

The crawler takes a screenshot of the visible area of the first page and an image of the form element of every visible form (scanner/src/crawl.js). Nothing is blacked out in the process. This is different for browser journeys: there, input fields are masked before the screenshot (scanner/src/browser.js). So only the images from browser journeys are “cleaned”, not those from the crawler and not the image of the response page from an active check.

Because the crawler types nothing in, the form fields are empty. However, the home page of a small business often shows the owner, the team, customer testimonials with names and photos, or a chat window with the picture of an employee. All of this is public; the screenshot turns it into a copy that is stored with us, appears in the report and can be passed on with the link.

Likelihood – likely. 432 screenshots were measured in the data set of the development system. Severity – limited: the content is already public, and the periods for checks without an account are short. Level – medium, because the people depicted are unaware and the home page image is not needed for the finding.

R4 – Check data and screenshots without a deletion route

The nightly run deletes checks by two routes: via the expiry date of a report (cfg/check_lib.php) and via the period for checks of a Customer domain (cfg/fristen_lib.php, only for checks with a domain). A check that has neither a report nor a domain falls through both nets. These are the checks with the trust level “internal”: studies and checks that the provider creates from the command line.

• Studies delete their raw data upon publication (cfg/studie_lib.php). If a study is never published – because it has too few websites with a form (cfg/studie_lib.php then refuses publication) or because it is left lying – checks, forms, findings and screenshots remain without a time limit.
• Internal checks from the command line have no deletion route at all. Measured on 11 October 2026: 85 such checks of third-party websites with 978 forms and 369 screenshots, the oldest from 22 September 2026, none with a report or a domain.
• Notes on conspicuous behaviour in the free check contain the IP address and are deleted 90 days after they are resolved (srv/cron_status.php). A note that is never resolved remains. Measured: three notes, all resolved.

Likelihood – materialised. The 85 checks are not a scenario but existing data. On the development system they are checks from a field test; the same code applies on the production system. Severity – significant: there is no retention period for these data. With regard to the principle of storage limitation (Art. 5(1)(e)), this is an open point with a planned measure (section 9.3, priority “first”), and it affects precisely people who know nothing of the check. Internal checks are described in the Records of Processing Activities; the Privacy Policy does not yet name them separately (section 9.4). Level – high.

R5 – Checking and public rating of third-party websites without the operator’s knowledge

Anyone can have any publicly accessible website checked, without an account and without any connection to it. The operator is not notified. The result is a report that rates the website as “Exposed”, “Partially protected” or “Protected” and that anyone with the link can see. Two consequences are conceivable for data subjects. A sole trader is given a rating publicly – even if only for the recipients of the link – that may be a false finding. And the report shows a spammer which form can be filled in without obstacle.

A series of blocks stands against this (cfg/check_lib.php): at most one check per domain in seven days, after that the same report; limits per IP address and session; a daily cap for the whole service; no checks of very new domains, which are typical of abuse; a note and a signal for conspicuous behaviour; robots.txt and opt-out, checked twice (cfg/check_lib.php and in the checking service). The free report is an extract: it shows only the basic findings, not the evidence of all detectors. And it says nothing that a bot could not find out for itself in seconds – an unprotected form is visible from the outside.

Likelihood – possible. Severity – significant for a sole trader whose form is targeted after a report or whose rating is wrong. Level – medium.

R6 – Prospect check as a basis for unsolicited approaches

In the interface, the prospect check is described as a “door-opener for the first conversation”. How the agency uses the short finding is for the agency to decide; technically, it can also send it to an operator who did not ask for it. We do not contact anyone (cfg/akquise_lib.php), and the Terms of Service oblige the agency to comply with the rules on advertising and solicitation. An unsolicited e-mail with the finding is, however, direct marketing even between businesses, which in Poland (Art. 398 of the Electronic Communications Law (Prawo komunikacji elektronicznej, PKE)) and in Germany (§ 7(2) of the German Act against Unfair Competition (Gesetz gegen den unlauteren Wettbewerb, UWG)) requires prior consent. The interface does not point this out; the texts of the prospect check speak only of “passive” and “opt-out list”.

Likelihood – likely, because the function serves customer acquisition and we cannot verify whether the recipient has consented. Severity – limited: for the operator it is an annoying marketing e-mail with a rating of its website. Level – medium. The risk lies in the agency’s conduct; because the function comes from us, a notice in the interface is planned (section 9.3).

R7 – Proof of control is never renewed

Active test submissions, the search for exposed files and the scan behind the login require the Customer to have proven that it is entitled to control the domain. This proof is checked once (cfg/verify_lib.php) and never again. There is no route in the code by which a domain loses its proof. If the domain changes owner, an agency ends its engagement or the operator removes the DNS record, the checks continue – up to daily, with up to five test submissions and, where stored, with the login of a test account that the new operator may not know about. What is not possible, by contrast, is transferring the proof to another host by renaming: the hostname of a domain with proof of control cannot be changed.

Likelihood – possible: changes of domain and of engagement are everyday occurrences for agencies. Severity – significant for the new operator and its employees, who receive marked test messages and whose website is searched for exposed files without their consent. Level – medium. The test messages explain themselves and refer to the crawler page and the opt-out; the opt-out also works against checks by Customers.

R8 – Credentials and content in the scan behind the login

The encryption of the credentials is carefully built: the web server can no longer read them after storage, the database and backup contain only ciphertext, the record is bound to its domain, the credentials enter the container only via standard input and are then cleared from memory (section 6.5). Two gaps remain; a third point concerns only reading, not storing.

• Unencrypted login is permitted. The address check allows http alongside https (cfg/login_lib.php, scanner/src/login.js). If the Customer enters a login page with http, the username and password travel across the internet in plain text with every check.
• Certificate errors do not stop the login. The login does not currently abort when the certificate of the Customer’s site is invalid (scanner/src/login.js). The certificate therefore does not fully protect the credentials on their way to the Customer’s site. Aborting on certificate errors is planned (section 9.3, priority “first”).
• Values of hidden fields behind the login are read, not stored. The crawler reads the first 24 characters of the value of hidden fields (scanner/src/crawl.js), and the same extraction function runs behind the login (scanner/src/login.js). There, hidden fields frequently carry an account number, a user identifier or the e-mail address of the logged-in account; however, only the field name, type, label and the detection result make it into the field map and the findings.

Added to this is what the code cannot prevent: the Customer confirms that it is using a test account with as few rights as possible (cfg/login_lib.php), but it can enter a real administrator account. The pages the scanner then reads are determined by the Customer; addresses containing words for logging out and deleting are blocked, but other actions that a website triggers via a simple request are not.

Likelihood – possible. Severity – serious if an account with wide rights is affected; the members’ area with the data of all users is then open. Level – medium for a test account with few rights, high for a real account. Measured on the development system, no test account is stored.

R9 – Active test submissions and file check on the Customer’s website

A test submission goes to the people who read the Customer’s form e-mails – its employees or a service provider. It contains no personal data: the sender is dummy@formexposed.com, the text and subject are marked and state the check identifier (scanner/src/active.js). The risk lies in a misclassification: if the scanner took an application, booking or advice form for a contact form, the test message would end up in a process that has consequences. Against this stand the strict rules for “submittable” (scanner/src/classify.js), the block for domains of public authorities, educational institutions, clinics, medical practices, police and courts (scanner/src/classify.js) and the exclusion of the language model from this decision (scanner/src/classify.js). From the response, the status, target address, title, 300 characters of text and an image are stored; they relate to our test message.

The file check reads at most 8 KB from typical paths. If a database dump really is exposed there, these 8 KB may contain form entries made by visitors. They are only checked for a signature and discarded (cfg/dateien_lib.php); what is stored is the path, type and severity.

Likelihood – remote. Severity – significant. Level – low. Measured on the development system, there is one active check in the data set, with no accepted submission.

R10 – Classification by a language model

For forms that the rules do not recognise, the language model receives the page title, address, button texts, field descriptions and up to 400 characters of form text (scanner/src/classify.js). This may include a name, for example “Your contact person: …”. It runs on our own server; in the code, nothing goes to a third party. Whether the model software logs requests has not been verified. Its result determines only the form type displayed and cannot make a form submittable; a wrong classification leads to a worse finding, not to an action.

Likelihood – remote. Severity – limited. Level – low.

R10 – Additional action-plan stage

For eligible paid reports, the same local model also generates advisory steps from selected findings and scan metadata. Unlike classification, the output is a natural-language summary retained with the scan. Hostnames, page addresses and notes may contain personal data that the model could repeat. A wrong recommendation may lead a reader to weaken protection or make an unnecessary change; passing on a report link may disclose repeated personal data to another recipient. The code does not automatically execute the recommendation, alter the score or verdict, or check the factual correctness of the text. It limits the input and output length, labels the summary as AI-generated and states that the individual findings are authoritative. These are controls, not proof that the recommendations are correct or that the report is anonymous. The earlier likelihood and severity rating for classification does not by itself rate this added generation stage; its residual risk must be assessed with the actual data and use of the underlying check.

R11 – Shared blocklist from reports by many websites

A domain on the list causes messages with links to it to end up in quarantine on all connected websites. If the domain belongs to an individual – a tradesperson, a photographer, a blog – their messages containing a link to their own website reach the recipients late. Such a domain can get on the list because spammers misuse it, or because someone deliberately sends failing messages containing it to several websites.

Against this stand (cfg/swarm_lib.php): a minimum of three different websites and five hits within seven days; fixed exceptions for large services; never our Customers’ domains; manual removal via a tool on the server; quarantine instead of deletion; the list is rebuilt daily, and whatever is no longer reported drops out. Those affected cannot see the list and have no route of their own to demand removal, other than through us.

Likelihood – possible. Severity – limited, because nothing is lost and the recipient can release the message. Level – low to medium. With IP networks switched on, networks of entire providers would be affected, IP addresses are personal data, and the severity would rise to significant: high.

R12 – Reports and screenshots under a public link

Reports from the free check, the prospect check and the checks of Customer domains can be accessed without logging in under a random link. The link contains 128 bits of randomness and cannot be guessed (cfg/check_lib.php). The pages carry noindex, the application sends a referrer policy that passes on only the origin (www/.htaccess), and screenshots are only delivered together with the report to which they belong; another image number returns “not found” (www/shot.php). The risk is not cryptographic but human: a link is passed on, copied into a ticket, shared in a chat. Whoever opens it is only recorded in the page access log like any page view (60 days), in which the link itself appears only in masked form; there is no list of readers per report.

Likelihood – possible. Severity – limited, because the report shows only public information and expires after 30 or 90 days respectively; reports on Customer domains remain accessible as long as the check exists (13 months, the last one longer). Level – low.

R13 – Infrastructure weaknesses

The following points are listed as open in our internal review pack and are not glossed over here. We describe them as precisely as Customers need for their own assessment, but not so precisely that the description shows an attacker the way; we will provide the details to a supervisory authority on request.

• Backups of the database are currently stored at the same location as the database and are not separately encrypted; an encrypted copy at a second location is planned (cfg/backup_lib.php). Until then, they do not protect against loss of the location, and anyone who obtains the database also obtains the backups. The credentials for the scan behind the login are contained in them only as ciphertext.
• No encryption of the database at rest. The exceptions are the fields that are encrypted individually (credentials of the test accounts, two-factor secret).
• Connections within our internal network are not encrypted throughout.
• Server administration. The security of the administrative access to our servers does not yet meet the standard we intend for operation; the hardening of server administration is continuing.
• Check environment. The scan server opens third-party websites in a browser. The check containers are isolated – their own network, no special privileges, read-only, limited (scanner/src/worker.js). The separation between the check environment and the other parts of the service is being further strengthened (section 9.3).

Likelihood – possible. Severity – serious, because in an emergency everything would be affected at once. Level – high. The individual points can be remedied by ordinary means (section 9.3).

R14 – Data subject rights for people who do not know us

Anyone who appears incidentally in a screenshot or whose message passed through a control copy usually does not know that we exist. Even if they do, they have no key to “their” data: we do not store it by person but by domain and check. We can only answer an access request under Art. 15 if the person names the domain; we can then go through the existing checks and images. For genuine visitor messages there is nothing to disclose, because we do not store them – except for the sender domain from R1. The opt-out works only for operators of a domain, not for people depicted; for them, the route via contact@lukaswojcik.com remains.

Likelihood – likely as a structural situation. Severity – limited, because the data are short-lived and not organised by person. Level – low.

9. (d) Measures to address the risks

Each measure carries a status, and the statuses are not decorative. Implemented today – verified means: read in the code of the development system and, where possible, measured against the database. Partial means: the mechanism exists but does not yet fully achieve its purpose. Planned means: proposed by this assessment and not built; whether and when is decided by the owner. Still to be determined are procedures and decisions that no code replaces. A DPIA that presents planned measures as implemented loses its value precisely in the situation in which it is needed.

9.1 Implemented today – verified

Measure	Addresses	Source reference
robots.txt is read by the crawler before every check; an exclusion covering the home page, an unreachable robots.txt or a server error ends the check (sub-paths are not observed individually; pulse, proof retrieval, header tool and file search do not read it)	R5, lawfulness	scanner/src/net.js
Opt-out without proof, effective immediately, for the domain and its www variant, for anonymous checks, prospects, studies and Customer checks (ongoing monitoring ends with the next scheduled check); checked twice (application and checking service); lifted only by us on request with proof	R5, R7, Art. 21	cfg/check_lib.php; cfg/akquise_lib.php; cfg/studie_lib.php; scanner/src/worker.js
Free check: emergency stop, reCAPTCHA, one check per domain and week, limits per IP address and session, daily cap, no new domains, only public addresses, note and signal without content in case of anomalies	R5	cfg/check_lib.php
For limits, the session is stored only as a hash value, never the session identifier	Minimisation	cfg/check_lib.php
No field values (beginnings of hidden fields and data attributes are only read during the check, section 6.2); recipient addresses only as a domain; account identifiers in script addresses hidden	Minimisation	scanner/src/crawl.js
The free report is an extract: only basic findings, no evidence from all detectors	R5	cfg/check_lib.php, FE_FREE_DETEKTOREN
Reports under a 128-bit random link, noindex, images only for their own report, outside the public web directory; the link appears in the page access log only in masked form	R12	cfg/check_lib.php; www/report.php; www/shot.php
Deletion: anonymous reports after 30 days, prospects after 90 days, Customer checks after 13 months (the last one per domain is kept as long as the domain exists), the data of a deleted domain immediately (for exceptions see section 6.11), images in each case along with them	Storage limitation	cfg/check_lib.php; cfg/fristen_lib.php
Study: publication only as a total, segments only from 20 websites with a form, raw data deleted upon publication	R4 partly, P3	cfg/studie_lib.php
Check containers: their own isolated network, no special privileges, read-only, memory and process limits, time limit; filter against private destinations for every request, service workers blocked and WebSocket connections closed so that nothing bypasses the filter; requests by the web server only on web ports and only to exactly the public address checked beforehand	R13	scanner/src/worker.js; scanner/src/net.js
Active check for Customers only for a verified domain (internally also for our own test and demo domains) and with the emergency stop switched on, checked twice; at most five submissions; only clearly recognised contact forms without required personal data; no domains of public authorities, educational institutions, clinics, medical practices, police or courts; the language model may not release anything; test message without personal data, marked, with a reference to the crawler page and opt-out	R9	scanner/src/worker.js; scanner/src/classify.js; scanner/src/active.js
Browser journeys: only GET and HEAD, dangerous addresses blocked, made-up values do not leave the browser, images with blacked-out input fields	R3 (for these images), R9	scanner/src/browser.js
File check: only verified domains, one retrieval per path, at most 8 KB, content never stored	R9	cfg/dateien_lib.php
Second probe: switched off by default; would receive only a fixed list of harmless items, signed	Recipients	cfg/formular_probe_lib.php
Scan behind the login: only a verified domain, paid plan, owner or administrator, “test account” confirmation; encryption with the public key of the scan server, bound to the domain; credentials never displayed, logged or output via the API; handover only via standard input; field in the job cleared immediately, remnants after one hour; no screenshots, no submissions, no logout or deletion addresses, abort on CAPTCHA; final deletion with overwriting	R8	cfg/login_lib.php; scanner/src/login.js; scanner/src/geheim.js; scanner/src/worker.js
Delivery check: switched off by default; retrieval reads only headers and 8 KB, without a read marker; content and visitor address never in the database; every retrieved e-mail is deleted, including unassignable ones; assignments deleted after 180 days; proof only via the copy of exactly this test	R1, R2	cfg/zustellung_lib.php
Swarm protection: only domains, IP networks off; minimum numbers; exceptions for large services and Customer domains; quarantine instead of deletion; list rebuilt daily; reports deleted after 30 days	R11	cfg/swarm_lib.php
Language model on our own server, without the right to submit	R10	scanner/src/classify.js
Action plan: local generation from selected findings, no screenshots or entered field values in its prompt; capped finding count and note length; cleaned plain text with capped length; visible AI notice, individual findings authoritative; no automatic website changes or score/verdict decisions	R10 partly; incorrect advice and incidental personal data remain possible	cfg/plan_lib.php; www/report.php
Signals via Telegram contain only a fixed sentence without variables	Recipients	cfg/check_lib.php
Weekly restore test of the backup, with an alert on failure	Availability	cfg/backup_lib.php; srv/cron_status.php

9.2 Partial – in place, but not yet achieving its purpose

Measure	Why it is not yet fully effective
“Cleaned” screenshots	Only the images from browser journeys are blacked out. The crawler’s images – home page and form elements – and the image of the response page from an active check are not (R3).
Periods for check data	Effective for anonymous, prospect and Customer checks; not for internal checks and unpublished studies; unresolved anomaly notes without a time limit (R4).
Deletion of the control copies	Effective in our view of the mailbox. If the run aborts, e-mails remain; what the mailbox provider keeps in its own backups has not been verified (R2).
Protection of credentials in the scan behind the login	Strong at rest and in the checking service; not on the way to the website: http is permitted, certificate errors are ignored (R8).
Proof of control	Is checked once and then applies forever; the hostname of a domain with proof of control cannot be changed, however, so that the proof does not pass to another host (R7).
Information to data subjects	In place for operators via the crawler page, identifier, Privacy Policy and opt-out; for visitors in the delivery check, dependent on the Customer adopting the text block; the application does not check this.
Request to Customers not to put special categories into the control copy	Stated in the legal documents, but not supported technically: during set-up, the application does not ask about the type of website and does not warn about domains that look like health, law or education (R1).

9.3 Planned – not implemented

Measure	Addresses	Priority
Deletion route for internal checks: delete checks without a domain and without a report after a fixed period (proposal: 30 days); delete the raw data of a study at the latest a fixed period after its completion, even without publication (proposal: 90 days); delete the existing 85 checks with 369 images once	R4	First
Enable the delivery check only once the contract with the mailbox provider has been concluded, storage locations, sub-processors and backup periods have been documented and the transfer mechanism for the mailbox provider has been clarified and the MX records of our domain point directly to the mailbox; until then, keep the function blocked in the production system	R2	First
Check the security of mailbox retrieval on the production system and document it before the delivery check is enabled	R2	First
Scan behind the login only via https and with a valid certificate; reject http addresses; certificate errors at login as a reason to abort	R8	First
Do not store values of hidden fields behind the login (only name, type and length) – already implemented this way, no further step	R8	Done
Limit the control copy to test messages where the plugin or the extension is in use: blind copy only for submissions with our test identifier	R1	High
Do not store the sender domain of genuine messages or write it into alerts if it is neither the website’s domain nor that of a known sending service; in the alert, “foreign sender domain” instead	R1	High
Warning when setting up the delivery check for domains that look like health, law, social services or education, with a reference to the Customer’s own DPIA	R1	High
Renew proof of control regularly (proposal: before every active check, verify whether the DNS record, meta tag, file or plugin connection still exists; otherwise continue passively and notify the Customer)	R7	High
Stop photographing the home page, or only with blacked-out images and faces; limit form images to the form element (as today) and mask input fields as for browser journeys	R3	High
Notice in the interface of the prospect check: sending the short finding unsolicited by e-mail or telephone is direct marketing even between businesses and requires prior consent (Art. 398 of the Polish Electronic Communications Law; in Germany § 7(2) UWG, although presumed consent suffices for calls to businesses)	R6	High
Infrastructure: complete the hardening of server administration; encrypted copy of the backup at a second location; encrypt connections in the internal network throughout; further strengthen the separation between the scan server and the application	R13	High
Period for unresolved anomaly notes (proposal: resolution within 30 days, otherwise deletion of the IP address)	R4	Medium
A page or form through which someone can request the removal of a domain from swarm protection	R11, R14	Medium
Before switching on IP networks in swarm protection: a new version of this assessment	R11	Condition
Record whether the language model software stores requests and, if so, switch off these logs	R10	Low

9.4 Procedures and decisions still to be determined

Besides technical safeguards, Art. 35(7)(d) also requires procedures. These are still outstanding:

• Personal data breach. Detection: the owner, the application’s error alert, reports via the vulnerability reporting point or contact@lukaswojcik.com. Decision on notification to UODO within 72 hours (Art. 33(1)): the owner. Informing affected Customers as controllers: without undue delay, if possible within 48 hours, as promised in the Data Processing Agreement. To be determined: a written procedure description and a first exercise; for the delivery check, in addition, how to establish which Customers are affected by a breach at the mailbox provider.
• Sectors. To be determined: whether the delivery check is offered, offered with a warning or excluded for websites from health, law, social services and education.
• Internal checks. To be determined: what the provider uses internal checks from the command line for, who may create them and how long their results remain; and whether, beyond the Records of Processing Activities, they need to be named in the Privacy Policy.
• Studies. To be determined: who compiles lists, from which sources, with what maximum size, and a check before every study as to whether it complies with the assumptions of this assessment.
• Views of data subjects (Art. 35(9)). They have not been sought for this version. Art. 35(9) requires them to be sought only “where appropriate”; in our assessment, this is currently not the case here. Operators of checked websites and visitors to Customer websites have no channel of their own to us; addressing them specifically would itself be a new processing of their data, and the service has not yet launched, so there is as yet no group of actual data subjects. Their interests are taken into account indirectly: through robots.txt and opt-out, through the short periods and through the fact that the content of control copies is not stored. At each review under section 12 we reconsider whether seeking their views is appropriate, for example via feedback on the crawler page or from Customers of the delivery check.

10. Residual risk and prior consultation under Art. 36

Art. 36(1) requires prior consultation of the supervisory authority where the DPIA indicates that the processing would result in a high risk in the absence of measures taken by the controller to mitigate the risk. The question is therefore not whether high risks were identified – four were – but whether a high risk remains once the measures are in place.

For the processing operations for which formexposed is the controller (P1 to P4, P7), the high risks R4 and R13 can be remedied by ordinary means: a deletion route and a clean-up of the existing data, an encrypted off-site backup and the hardening of two servers. With the measures from 9.3, they fall to low to medium. R3, R5, R6 and R7 are at medium and fall to low with the proposed measures. Swarm protection without IP networks remains low to medium. Prior consultation is not indicated for this part if the measures marked “first” and “high” are implemented before launch. If any of these measures has not been implemented before launch, a high risk remains for the processing operation concerned. That processing operation will then be started only once the measure has been implemented, or UODO will first be consulted under Art. 36(1).

For the delivery check (P6), the situation is different, for a reason that no measure entirely removes: what a visitor writes is up to them. With a concluded contract, secured retrieval, limitation to test messages where possible and dispensing with the sender domain, R2 falls to low and R1 to medium. For Customers whose visitors typically provide data under Art. 9, R1 may nevertheless remain high. The obligation to consult then lies with the Customer as controller, not with formexposed. Our recommendation to such Customers is not to set up the control copy for the general contact form, but only for forms without sensitive content, or to do without the delivery check.

Residual risk, honestly stated. Today, with the measures from 9.1, four risks are at high: R1 and R2 (delivery check), R4 (check data without a deletion route) and R13 (infrastructure). With the measures from 9.3, R2, R4 and R13 fall to low to medium. R1 remains at medium and is permanently dependent on decisions made by Customers. None of the other risks is above medium after the measures.

Art. 36 is not a penalty, and consulting is not an admission. It is the route the Regulation provides for the situation in which a useful procedure carries a risk that the controller does not fully control. A Customer who wants to use the delivery check for messages containing health data will find the facts for that decision here.

11. What Customers need for their own DPIA (Art. 28(3)(f))

For the delivery check and the scan behind the login, the Customer is the controller. This page provides it with the description (sections 6.5 and 6.6), the risks from our perspective (R1, R2, R8) and the status of the measures (section 9). Only the Customer can answer the following questions:

1. What do my visitors write? Is it to be expected that data on health, religion, origin, trade union membership, sexual orientation, criminal offences or about children will come in via the form? Then a DPIA for the control copy is as a rule required, and the control copy for this form should be reconsidered.
2. Do I need the control copy for all messages? To prove that our test message arrives, it is sufficient for that message. Where the form allows it, set the blind copy only for test messages.
3. How do I inform my visitors? The Data Processing Agreement requires it; the Privacy Policy Text for Your Website describes the route of the copy and our role.
4. What legal basis do I have? Our suggested text names Art. 6(1)(f) (reliable receipt of enquiries). For data under Art. 9, this basis alone is not sufficient.
5. Which alert channels do I choose? Alerts from the authenticity check can name the sender domain. Anyone who sends alerts to chat services outside the EU transfers it there.
6. For the scan behind the login: Is the test account really a test account with the least rights necessary? Can the login page be reached only via https? Does the test account see data of other users? If so: on which of the specified pages?
7. When do I delete? The delivery check and the test account can be switched off and deleted at any time; the test account is then permanently overwritten.

Further documents for the Customer’s assessment: the Data Processing Agreement, the technical and organisational measures, the list of sub-processors and the Records of Processing Activities. We answer questions about individual facts at contact@lukaswojcik.com.

12. Review, version and approval

Art. 35(11) requires a review to assess whether the processing is performed in accordance with the DPIA, at least when there is a change in the risk. We review this assessment at least annually and also before each of the following events; each triggers a new measurement, not just a reading:

• launch of production operation, with figures from the production system instead of the development system;
• first activation of the delivery check on the production system and conclusion of the contract with the mailbox provider;
• switching on IP networks in swarm protection;
• the first study, and every study with a larger list than the previous one;
• switching on the second probe or a new recipient in the checking path;
• any new use of the language model that goes beyond the uses covered by this assessment; the prioritised action plan in paid reports is an added use and requires the assessment to be reviewed;
• any change to the screenshots, the periods or the preconditions for active checks.

Item	Entry
Controller	LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland · NIP 7252266190 · contact@lukaswojcik.com
Competent supervisory authority	Prezes Urzędu Ochrony Danych Osobowych (UODO), ul. Moniuszki 1A, 00-014 Warszawa, Poland
Data protection officer	Not designated; assessment under Art. 37 in section 4
Basis of the facts	Source code of the application and the checking service, database schema, row counts and settings of the development system, measured on 11 October 2026, read-only
Related documents	Privacy Policy, Data Processing Agreement, Technical and Organisational Measures, Sub-processors, Records of Processing Activities, EU AI Act, Acceptable Use and Abuse, FormExposedBot, Opt-out
Version	1.1 of 23 October 2026; factual addendum on the local action-plan stage to the first version of 11 October 2026
Reviews under Art. 35(11)	23 October 2026: source-code review of the added local action-plan stage. Inputs, storage, roles, advisory output and implemented safeguards were added to the corresponding sections; no completed production measurement or new residual-risk rating is asserted. The earlier measurements dated 11 October 2026 and the approval status below remain unchanged. Further reviews are entered here with date, reason and result.
Approval	Not yet approved. Approval by the owner after legal review and after a decision on the measures from section 9.3 and the questions from section 9.4. External data protection advice has not been sought so far.

One closing observation belongs in the document and not in a covering letter. The parts of formexposed that reach furthest into other people’s domains – the test submissions and the login with someone else’s credentials – are built with the most caution: two gates, hard caps, encryption that locks even us out. The risks in this assessment lie mostly elsewhere: in what comes along incidentally – genuine messages in a blind copy, people in a screenshot, checks that no one deletes any more. That is a favourable starting position, because the incidental can be stopped without changing the service.