Data Processing Agreement

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

Version 2.2 · Last updated: 29 October 2026

Agreement on the processing of personal data on behalf of a controller pursuant to Art. 28 of the General Data Protection Regulation (GDPR)

between the Customer of formexposed as controller (the “Customer”) and LW IT Solutions Company Lukas Wójcik, al. Tadeusza Kościuszki 80/82, lok. 301, 90-437 Łódź, Poland, NIP (Polish tax identification number) 7252266190, as processor (“we”).

Preliminary remarks: what this Agreement is about

formexposed checks the contact forms of websites for their protection against spam and abuse, monitors them and reports changes. For most of the data that arises in the process, we are the controller ourselves: for the customer account, billing, the security of the Service, the logs and for checks without an account. Our Privacy Policy describes this processing; this Agreement does not apply to it.

Some functions, however, bring personal data of third parties into the Service, and it is the Customer who decides about that data: copies of genuine enquiries from visitors to its website, the addresses of the people who receive its alerts, the login details of a test account, code that it gives us to work on. We process this data only on the Customer’s behalf. This Agreement applies to it. Which functions these are in detail is set out in Annex 1 at the end of this Agreement.

The Agreement follows Art. 28(3) GDPR and is modelled in structure and content on the European Commission’s standard contractual clauses between controllers and processors (Implementing Decision (EU) 2021/915). It does not adopt them word for word but describes the actual Service. Where we set out an obligation under Art. 28 GDPR in more detail, the level of protection of the Regulation is not to be undercut.

§ 1 Subject matter, scope and roles

(1) The subject matter of this Agreement is the processing of personal data by us on behalf of the Customer in providing the Service under our Terms of Service. The subject matter, nature and purpose of the processing, the types of personal data and the categories of data subjects are set out for each function in Annex 1.

(2) This Agreement does not cover processing for which we ourselves are the controller, in particular the customer account and the members of a workspace, sign-in and account security, billing, support, logs, backups of these data of our own, the free check without an account, checks of domains in the account for which the Customer has not yet provided proof of control, the prospect check, the study, the badge and what the WordPress plugin and the TYPO3 extension transmit: daily figures, the plugin inventory and, for a connected WordPress plugin, the domains of links from blocked messages for swarm protection (switched on by default). Beyond that, by the way these extensions are built, these data contain no content, names, addresses or IP addresses of visitors. By contrast, backups, insofar as they contain Customer Data, and access to Customer Data for operation, troubleshooting and security are part of the processing on behalf of the Customer; § 7(3) and § 15(5) apply to them.

(3) The Customer is the controller within the meaning of Art. 4(7) GDPR for the data in Annex 1. If the Customer itself acts as a processor for a third party, for example an agency for its clients, we are a sub-processor for that data. The Customer then ensures that this Agreement is compatible with the obligations under its own contract and passes on instructions from the third party to us only through itself.

(4) Conclusion: the Agreement is concluded on registration together with the Terms of Service, with every Customer, even if it does not use any of the functions in Annex 1. It is concluded electronically; this satisfies Art. 28(9) GDPR. For this purpose we store the version displayed, its checksum, and the time, IP address and browser identifier of acceptance.

§ 2 Definitions

Terms such as “personal data”, “processing”, “controller”, “processor” and “personal data breach” have the meaning given in Art. 4 GDPR. In addition:

• Customer Data means the personal data that we process on behalf of the Customer under Annex 1.
• Sub-processor means a further processor that we engage and that processes Customer Data in doing so (Art. 28(2) and (4) GDPR).
• Workspace means the area in the Service in which a Customer manages its domains, settings and members. All Customer Data is assigned to a workspace.
• Text form means any legible declaration on a durable medium, in particular an e-mail.
• Days means calendar days. If the end of a period falls on a Saturday, Sunday or public holiday in Poland, it ends on the next working day.

§ 3 Term

(1) The Agreement applies for as long as we process Customer Data. It begins on registration and does not end merely because a paid plan ends: after cancellation the account continues as a free account, and with it, where applicable, Customer Data. It ends when the account has been deleted and we no longer hold any Customer Data of the Customer, except in backups until they expire (§ 15).

(2) Obligations which by their nature continue to have effect survive termination, in particular confidentiality, deletion, evidence and liability.

(3) Ordinary termination of this Agreement alone is excluded, because without it no Customer Data could be processed for as long as the account exists. If the Customer wishes to end it, it deletes its account (§ 15(3)). The termination rights under § 9(3) and § 16 and the termination rights under the Terms of Service remain unaffected.

§ 4 Instructions

(1) We process Customer Data only on documented instructions from the Customer, including with regard to a transfer to a third country or to an international organisation. This does not apply where Union or Member State law to which we are subject requires us to carry out processing. In that case we inform the Customer of that legal requirement before processing, unless that law prohibits such information on important grounds of public interest (Art. 28(3), second sentence, point (a) GDPR).

(2) The Customer’s instructions are documented exhaustively in this Agreement, in the Terms of Service and in the settings that the Customer makes in the Service. Examples: setting up the delivery check is the instruction to accept and evaluate copies of the form e-mails; creating an alert destination is the instruction to send notifications there; storing a test account is the instruction to sign in with it for the scan behind the login. The Service is built so that it does only what these settings provide for.

(3) The Customer gives further instructions in text form to contact@lukaswojcik.com or via the support window. The owner and the administrators of the workspace are entitled to give instructions; instructions by means of settings in the Service are given by whoever is permitted by their role to make the setting. The Customer confirms an oral instruction in text form without undue delay; until then, we may wait before executing it, unless the instruction concerns the erasure or restriction of data. We treat an instruction that goes beyond the agreed scope of services as a request to change the services; we may refuse it or make it subject to remuneration that we state in advance in text form. We do not refuse on this ground an instruction that concerns an obligation under the GDPR, such as an erasure.

(4) If, in our opinion, an instruction infringes the law, we inform the Customer immediately (Art. 28(3), second subparagraph, GDPR). We may suspend its execution until the Customer confirms or amends the instruction. We do not carry out an instruction that is manifestly unlawful. We are not obliged to carry out a comprehensive legal review of every instruction; responsibility for its lawfulness remains with the Customer.

§ 5 Purpose limitation and what we do not do with Customer Data

(1) We process Customer Data only for the purposes in Annex 1 and only to the extent that the function concerned requires.

(2) We do not use Customer Data for our own purposes. In particular, we do not analyse it for advertising, do not sell it, do not combine it with data of other customers into profiles and do not use it to train language models. The language model that assists with individual functions runs on our own server; nothing is sent to an external AI service.

(3) The Customer permits us to compile from Customer Data aggregated figures that can no longer be attributed to any person, any customer or any domain, for example on deliveries, errors or check results. The aggregation is processing under this Agreement; the resulting figures are no longer personal data and no longer Customer Data. We do not attempt to re-identify persons from them.

§ 6 Obligations of the Customer

(1) The Customer is responsible for the lawfulness of the processing it instructs us to carry out. This includes having a legal basis for it and informing the data subjects under Art. 13 and 14 GDPR.

(2) If the Customer uses the delivery check, it informs the visitors to its website in its privacy policy that a copy of the form e-mail is sent to us. The Service shows a suggested text for this on the domain’s page; further text blocks are available at Privacy Policy Text for Your Website. The suggestion does not replace the Customer’s own assessment.

(3) For the scan behind the login, the Customer creates a dedicated test account that has only the rights needed to read the pages specified and that does not show any real data of customers, patients, members or employees. It does not store login details of a real person or login details it is not authorised to use. The rules of use are also set out in Acceptable Use and Abuse.

(4) The Customer does not have special categories of personal data (Art. 9 GDPR) or data relating to criminal convictions (Art. 10 GDPR) processed via the Service, insofar as it can avoid this. When using “Fix it for me”, it does not paste in code containing real personal data, and it creates client portals only for persons who have ordered the report.

(5) Client portals: for the monthly report to subscribers, the Customer, usually an agency, is the controller. The Service obtains each subscriber’s confirmation via a confirmation link (double opt-in) and offers unsubscription in every e-mail. Whether the consent covers the content of the report is for the Customer to assess.

(6) If the Customer detects errors or irregularities in the processing, it informs us without undue delay.

(7) If the Customer embeds the badge, this is not processing on its behalf; our Privacy Policy describes the processing involved. The Customer mentions this in its privacy policy.

§ 7 Confidentiality

(1) We grant access to Customer Data only to persons who need it for their tasks and who have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality (Art. 28(3), second sentence, point (b) GDPR). The commitment continues after their work has ended.

(2) At present the owner runs the Service himself. If further persons join, they are bound to confidentiality and instructed in the handling of personal data before they first have access.

(3) We look into a workspace only insofar as this is necessary for operations, troubleshooting, support or abuse prevention. The support function “view as customer” is limited to one hour, blocks changes to password, address, second factor, subscription, export and deletion, and is logged; the Customer sees the access in its data export.

§ 8 Security of processing

(1) We take the technical and organisational measures under Art. 32 GDPR that ensure a level of security appropriate to the risk. They are described on the page Technical and Organisational Measures. That page forms part of this Agreement (Annex 2) in the version published there at the relevant time. The Customer was able to view the description before concluding the Agreement. Whether the measures provide an appropriate level of security for the processing that the Customer entrusts to us is assessed by the Customer on its own responsibility (Art. 28(1) GDPR), in particular before it switches on a function from Annex 1.

(2) The page describes only measures that have actually been implemented. Anything planned but not yet implemented is expressly marked there as “planned” and does not form part of the measures we commit to until it has been implemented.

(3) We may adapt the measures to technical progress and to the development of the Service as long as the overall level of protection does not decrease. We publish every change with a new version number and date on the page and in the overview Changes to the Contract Documents. If a change removes a previously described measure without replacement or weakens it, we additionally notify the Customer in text form at least 30 days in advance; the Customer may then object as in the case of a new sub-processor (§ 9(3)). If a measure has to be replaced at short notice to counter a threat, this may be done without advance notice provided the level of protection does not decrease as a result; notification then follows without undue delay.

§ 9 Sub-processors

(1) The Customer gives us general written authorisation to engage sub-processors (Art. 28(2) GDPR). The sub-processors we currently engage, with their registered office, purpose, data, place of processing and basis for any transfer to a third country, are listed on the page Sub-processors. That list forms part of this Agreement (Annex 3) in the version published there. Authorisation is deemed given for the sub-processors named there.

(2) We inform the Customer of any intended addition or replacement of a sub-processor at least 30 days in advance by e-mail to the account holder’s address. The notice names the sub-processor, its registered office, the function concerned, the data, the place of processing and the basis for any transfer. At the same time, the announced change is shown on the sub-processors page and in the overview of changes.

(3) The Customer may object in text form within those 30 days if it has an objective reason relating to data protection; it states the reason in the objection. We then look for a solution together with the Customer, for example by continuing to run the function concerned for the Customer without the new sub-processor or by switching it off. Until a solution has been found, we do not use the new sub-processor for this Customer’s Customer Data; if that is not technically possible, the function concerned is suspended for the Customer. If no solution is found, the Customer may terminate the contract for the Service or for the affected service with effect from the date of the change and, if we inform it only after that date that no solution is possible, with immediate effect within 14 days of that notice. For a prepaid period that it can no longer use as a result, we refund the pro rata amount. Our right to ordinary termination under the Terms of Service remains unaffected.

(4) We impose on every sub-processor by contract the same data protection obligations that this Agreement imposes on us, in particular sufficient guarantees to implement appropriate technical and organisational measures (Art. 28(4), first sentence, GDPR). We select each sub-processor carefully and check whether these guarantees exist before engaging it, again if it materially changes its terms, and otherwise at the annual review of our measures. Where a sub-processor provides evidence only in the form of a certificate, an audit report or its published terms, we base our check on that evidence if it is current and meaningful. On request, we send the Customer a copy of the contract with the sub-processor or of its data protection terms; we may first redact trade secrets and other confidential information, such as prices.

(5) If a sub-processor fails to fulfil its data protection obligations, we remain liable to the Customer for the performance of its obligations as for our own conduct (Art. 28(4), second sentence, GDPR). Our selection of a sub-processor does not shift any responsibility to the Customer. If a sub-processor fails to fulfil its contractual obligations and this concerns the Customer’s Customer Data, we inform the Customer without undue delay. If we have factually disappeared, ceased to exist in law or become insolvent without a legal successor assuming our obligations, the Customer is to be able to require the sub-processor to erase or return the Customer Data; we agree this with every sub-processor insofar as it permits (cf. Clause 7.7(e) of the standard contractual clauses 2021/915).

(6) Not sub-processors are recipients to which data is sent only because the Customer itself sets them up as a destination in the Service: chat services (such as Slack, Discord, Microsoft Teams, Google Chat) and webhook addresses for alerts. Setting up the destination is the instruction to send the notification there; the contractual relationship with these providers and any basis required for a transfer to a third country are the Customer’s responsibility. Our own obligations under this Agreement up to the point at which the notification is handed over remain unaffected. Telegram is likewise a destination chosen by the Customer, but it works differently: we send the message via our own bot to the chat that the recipient has linked to the bot themselves, and Telegram processes it outside the European Economic Area. By choosing Telegram, the Customer expressly instructs us to transfer the notifications there (Art. 28(3), second sentence, point (a) GDPR); should Telegram have to be classified as our sub-processor in this respect, the choice of this destination is at the same time deemed to be a specific authorisation under Art. 28(2) GDPR for this purpose. The basis under Chapter V GDPR on which this transfer takes place has not yet been conclusively settled; anyone who wishes to avoid a transfer without a settled basis chooses a different destination. Likewise, service providers that merely transmit data, such as our internet service provider, are not sub-processors.

(7) We operate the servers, database and computing capacity, including for the language model, ourselves in Poland. No hosting or cloud provider is involved.

§ 10 Transfers to third countries

(1) Our own servers on which we process Customer Data are located in Poland; where a sub-processor processes Customer Data, Annex 3 states the location. A transfer to a country outside the European Economic Area takes place only if the conditions of Art. 44 to 49 GDPR are met, and only on the Customer’s instructions under § 4 or to a sub-processor authorised under § 9.

(2) The basis for each sub-processor (an adequacy decision, such as the one for the EU-U.S. Data Privacy Framework in the case of certified recipients, or standard contractual clauses under Art. 46(2)(c) GDPR) is stated in the list of sub-processors. Where the list says “to be verified” for a recipient, Customer Data is not sent to it until the basis has been documented. If we engage a sub-processor outside the European Economic Area without an adequacy decision applying, we agree with it the standard contractual clauses under Implementing Decision (EU) 2021/914 (Module 3: processor to processor), assess beforehand whether the law and practice of the country of destination permit compliance with them, take any necessary supplementary measures and record the result. The Customer receives a summary of this assessment on request.

(3) For transfers to destinations chosen by the Customer itself (§ 9(6)), the Customer is responsible for the basis.

§ 11 Assistance with data subjects’ rights

(1) Taking into account the nature of the processing, we assist the Customer by appropriate technical and organisational measures, insofar as this is possible, in responding to requests from data subjects under Chapter III GDPR (Art. 28(3), second sentence, point (e) GDPR).

(2) Much of this the Customer can do itself in the Service: change or delete alert destinations, test logins and its own branding; change or switch off form journeys; revoke client portals (their subscribers remain stored until the workspace is deleted); remove a domain together with its data; download a data export. Where that is not enough, we help on request in text form.

(3) If a data subject contacts us with a request concerning Customer Data, we do not answer it on the merits ourselves but forward it to the Customer without undue delay, and no later than seven days after receipt, insofar as we can identify the Customer, and tell the person that we have done so. If we cannot identify the Customer, we tell the person what information we need in order to find it.

(4) We state one limitation openly: we do not store copies of form e-mails from the delivery check in the database, and the e-mail is deleted from the mailbox after successful processing, or with a delay in the event of a retrieval or deletion error. As regards a particular visitor, we can therefore usually only say that we no longer hold any content.

(5) If we learn that Customer Data is inaccurate or out of date, we inform the Customer without undue delay. The Customer can then rectify, erase or restrict it itself in the Service or by an instruction to us.

§ 12 Assistance with security, impact assessment and consultation

(1) Taking into account the nature of the processing and the information available to us, we assist the Customer in complying with its obligations under Art. 32 to 36 GDPR: security of processing, notification and communication of breaches, data protection impact assessment and prior consultation of the supervisory authority (Art. 28(3), second sentence, point (f) GDPR).

(2) To this end we provide, in particular, the description of the measures, the list of sub-processors and, on request, further information on data flows and retention periods. We publish our own assessment of the risks of the Service in the Data Protection Impact Assessment; the Customer may use it for its own assessment.

(3) For assistance under §§ 11 and 12 that the Customer cannot provide for itself using the functions of the Service or the published documents, that requires more than four hours of effort per calendar year and that is not due to a breach of this Agreement or of the GDPR on our part, we may charge remuneration for the time beyond that at an hourly rate that we state in advance in text form. Forwarding requests and notifying breaches are always free of charge. We do not make assistance owed by law conditional on payment or on agreement on remuneration.

§ 13 Personal data breaches

(1) If we become aware of a personal data breach affecting the Customer’s Customer Data, we notify the Customer without undue delay, if possible within 48 hours, by e-mail to the account holder’s address (Art. 33(2) GDPR). This is intended not to shorten the 72-hour period that the Customer must observe towards the supervisory authority. We are aware of a breach as soon as we have established with reasonable certainty that a security incident affects the Customer’s Customer Data; we investigate any suspicion without undue delay. The same applies to a breach at a sub-processor as soon as it notifies us of it.

(2) The notification contains, insofar as known, the information under Art. 33(3) GDPR: the nature of the breach, including the time or period at which it occurred, where possible with the categories and approximate number of data subjects and records concerned, a contact point for further information, the likely consequences and the measures taken or proposed. Anything not yet established at the time of the first notification we provide without undue further delay.

(3) We immediately take the measures needed to remedy the breach and mitigate its consequences, and we agree further steps with the Customer. We document every breach with the facts, its effects and the remedial action taken, and make the documentation available to the Customer on request.

(4) Notification of the supervisory authority or communication to data subjects is made by the Customer. We do so only on its instructions.

(5) We receive reports of security vulnerabilities that third parties find in the Service at Security.

(6) A notification and our cooperation under this section do not constitute an acknowledgement of a breach of duty or of liability. If a breach also affects data for which we ourselves are the controller, we fulfil our own obligations under Art. 33 and 34 GDPR for that data; in doing so, we disclose the Customer’s Customer Data only insofar as necessary for that purpose.

§ 14 Evidence and audits

(1) We make available to the Customer all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor mandated by it (Art. 28(3), second sentence, point (h) GDPR).

(2) We primarily demonstrate compliance through documents: the description of the measures, the list of sub-processors, the Records of Processing Activities covering the processing on behalf of customers (Art. 30(2) GDPR), written answers to questionnaires and, on request, extracts from logs or from the results of the restore test. We answer questionnaires within 30 days of receipt and, where there is a reason under paragraph 4, as quickly as that reason requires. External audit reports or certifications do not currently exist; we say so in order that nobody assumes they do.

(3) If the documents are not sufficient, the Customer may request an audit, including on site. The Customer announces a routine audit at least 30 days in advance in text form, stating its subject matter, expected duration and auditor; it takes place during normal business hours in Poland and is scheduled so that operations are not unnecessarily disrupted. Routine on-site audits take place no more than once per calendar year; paragraph 4 remains unaffected.

(4) No fixed waiting period where there is an urgent reason. In the event of a personal data breach, where there are concrete indications of a breach of this Agreement or of the GDPR, and where a supervisory authority requests an audit, neither the 30-day notice period nor the limit of one audit per year applies. The audit then takes place as soon as the reason requires and as is organisationally possible.

(5) The Customer may mandate an auditor who is bound to confidentiality and who neither offers a service comparable to formexposed nor works for such a provider. We may require auditors not to take away or record secrets of other customers, login details or security details. The Customer and its auditor treat as confidential what they learn about our operations during an audit and use it only to verify compliance with this Agreement and the GDPR; they may disclose it to the competent supervisory authority, to advisers bound to confidentiality and insofar as required by law. Such arrangements must not defeat statutory audit rights.

(6) Each party bears its own costs of an audit. If our total effort for a Customer’s audits and questionnaires exceeds eight hours per calendar year, we may charge remuneration for the time beyond that at an hourly rate that we state in advance in text form, but not if the audit reveals a breach on our part or takes place for a reason under paragraph 4 for which we are responsible. We do not make the audit itself conditional on payment.

(7) The powers of the supervisory authorities remain unaffected. The supervisory authority competent for us is the President of the Personal Data Protection Office (Prezes Urzędu Ochrony Danych Osobowych, UODO), ul. Moniuszki 1A, 00-014 Warszawa. Both parties make the information under this section, including the results of audits, available to the competent supervisory authority on request.

§ 15 Deletion and return

(1) During the term, the retention periods in Annex 1 apply. They are enforced by a nightly run that deletes according to the same settings that also appear in the texts.

(2) Choice between return and deletion. After the end of the processing, the Customer decides whether we return or delete the Customer Data (Art. 28(3), second sentence, point (g) GDPR). Return takes place by means of the data export, which the Customer can download itself in the settings as a machine-readable file, or by us on request in text form within 30 days, in which case it also covers Customer Data not contained in the export, insofar as it can be returned (paragraph 4). Deletion takes place by removing a domain, which deletes its data, or by deleting the account, which the Customer triggers itself. If the Customer wants both return and deletion, it first downloads the export and then deletes.

(3) If the Customer makes no choice and deletes its account, this counts as choosing deletion. When the account is deleted, the workspaces of which the Customer is the sole owner are deleted immediately in the live system together with all Customer Data. If a workspace has further members, it passes to the member who has belonged to it longest, administrators before readers, and is not deleted; that member thereby becomes the Customer for that workspace. Anyone who does not want this removes the other members or the domains before deletion. If the contract for the account ends in another way, for example through our termination under the Terms of Service, we point the Customer to the export together with the notice of termination, and the Customer can download it until the end of the contract. No later than 30 days after the end of the contract, we delete the account together with the Customer Data; this is currently done manually.

(4) We say in advance what cannot be returned: login details for the scan behind the login are not part of the export because the web server cannot decrypt them (Annex 1, item 5); copies from the delivery check no longer exist after processing; code from “Fix it for me” is not stored at all.

(5) Backups. The database is backed up every night. Each backup is deleted after 14 days. Customer Data deleted in the live system remains in the older backups until then; individual records are not selectively deleted within a backup, because a backup must be an unaltered image of a point in time. Until they expire, the backups are protected like the database itself and are used only for restoration and for testing restoration; they are not searched or analysed. If we have to restore a backup, we re-execute deletion requests made after its date, insofar as we are aware of them, before the Service goes back into operation. A record has therefore disappeared from the backups as well no later than 14 days after its deletion in the live system.

(6) As things stand, we have no obligation to retain Customer Data. If a statutory retention obligation arises under Union or Polish law, we restrict the data concerned instead of deleting it, use it only for that purpose and delete it when the obligation expires.

(7) On request, we confirm the deletion in text form within 30 days, stating what still exists under paragraphs 5 and 6 and until when.

§ 16 Breaches, suspension and termination

(1) If we are unable to comply with an obligation under this Agreement, for whatever reason, we inform the Customer without undue delay.

(2) If we breach this Agreement or the GDPR, the Customer may require us to suspend the processing of the Customer Data concerned until the breach has been remedied. If the breach continues or is serious, the Customer may terminate the contract for the Service for cause, in particular if we do not remedy the breach within one month of being notified of it or do not comply with a decision of a court or supervisory authority concerning it. We refund on a pro rata basis any fees paid in advance for the period after the end of the contract.

(3) If the Customer insists on an instruction that we consider unlawful under § 4(4), we may terminate the contract for the affected service, provided we have notified the Customer of this beforehand and it does not change the instruction within one month.

(4) After termination, § 15 applies.

§ 17 Liability

(1) For damage suffered by a data subject, Art. 82 GDPR applies. This liability is not restricted by any contractual limitation of liability, including that in the Terms of Service.

(2) If a party has paid compensation to a data subject under Art. 82 GDPR, it may claim back from the other party the part corresponding to the other party’s share of responsibility for the damage (Art. 82(4) and (5) GDPR). This recourse, too, is not restricted by the limitations of liability in the Terms of Service.

(3) For all other claims between the Customer and us under this Agreement, for example for compensation of a party’s own damage or costs, the liability rules of the Terms of Service apply, insofar as permitted by law. We are liable for sub-processors under § 9(5) as for our own conduct. A fine imposed by a supervisory authority on a party for its own infringement is borne by that party itself.

(4) If a claim is made against a party by a data subject or a supervisory authority, that party informs the other without undue delay, and both cooperate in clarifying the matter. Neither party acknowledges a claim for which it intends to seek recourse from the other without the other’s consent; consent may not be refused without an objective reason.

§ 18 Contact point and data protection officer

(1) The Customer addresses data protection questions concerning this Agreement, instructions and notifications to contact@lukaswojcik.com or via the support window and the Contact page. Our notifications under this Agreement are sent to the account holder’s e-mail address; the Customer keeps it up to date.

(2) We have not designated a data protection officer because, in our assessment, the conditions of Art. 37(1) GDPR are not met. If that changes, we will announce the designation in this Agreement.

§ 19 Final provisions

(1) Precedence. If a provision of the Terms of Service or of another agreement conflicts with this Agreement, this Agreement prevails in all matters concerning the processing of Customer Data; the Customer’s own terms and conditions do not apply. Amendments and additions to this Agreement in an individual case require text form and must refer to it expressly; they become part of this Agreement and take precedence over it to the extent of their provisions. If this Agreement conflicts with mandatory provisions of the GDPR, those provisions prevail.

(2) Amendments. We amend this Agreement only for one of the following objective reasons: a change in the law or in its interpretation by courts and authorities, including through new standard contractual clauses of the European Commission; a change to the Service, its functions or its technical basis; a change of a third party necessary for providing the Service; to prevent misuse or security risks; or to correct errors and ambiguities. We announce amendments, stating the amended wording, the reason and the planned date, at least 30 days in advance by e-mail to the account holder’s address and in the overview of changes. Without this notice period, we amend only what is exclusively to the Customer’s advantage, is purely linguistic in nature or corrects obvious errors, what a law, a court or an authority requires at shorter notice, and what is necessary to avert an imminent security risk; in these cases, too, we communicate the amendment as soon as possible and state the reason. Silence does not constitute consent. Where an amendment requires the Customer’s consent, we obtain it expressly; without it, the previous version continues to apply, and the statutory and contractual termination rights remain. The Customer may object to an announced amendment in text form until it takes effect; the consequences are governed by the provisions of the Terms of Service on objections to an amendment. Amendments to Annexes 2 and 3 are governed by § 8(3) and § 9(2) and (3). All versions are recorded in the overview Changes to the Contract Documents.

(3) Governing law and place of jurisdiction. The law determined by the Terms of Service applies; mandatory provisions of the GDPR remain unaffected. The place of jurisdiction is governed by the Terms of Service.

(4) Language. The Agreement is available in all official languages of the European Union. In the event of discrepancies, the Polish version prevails.

(5) If a provision is invalid, the remainder of the Agreement remains valid. The invalid provision is replaced by the statutory provision that comes closest to its purpose; in case of doubt, by a provision that meets the requirements of Art. 28(3) GDPR.

Annex 1 – Processing on behalf of the Customer

For each function, this Annex describes the subject matter, nature and purpose of the processing, the types of personal data, the categories of data subjects and deletion (Art. 28(3), first sentence, GDPR). Unless stated otherwise, the nature of the processing is: collection, storage, retrieval, alignment, transmission to the destinations specified by the Customer, and erasure. The place of processing is our own servers in Poland; where a sub-processor is involved, this is stated. The periods in curly brackets are settings according to which the nightly deletion run actually works. The duration of the processing is the term of this Agreement (§ 3); within that term, the deletion periods stated for each function apply. The processing takes place on an ongoing basis for as long as the Customer uses the function. Special categories of personal data are not the subject matter of the processing; if they nevertheless enter the Service via form e-mails, § 6(4) applies.

1. Delivery check

Purpose: to check whether e-mails from the Customer’s form arrive and whether they are authentic (SPF, DKIM, DMARC).

How it works: the function is optional. The Customer enters the address of a control mailbox as a blind copy (Bcc) in its form. As a result, a copy of every form e-mail is sent to us, not only the copies of our test submissions but also those of genuine enquiries from its visitors. An automatic retrieval reads, via IMAP, the headers and at most the first 8 KB of the text, assigns the e-mail to the domain and, where applicable, to a test submission, and checks the authenticity features. After successful processing, the e-mail is deleted from the mailbox. In the event of a retrieval or deletion error, it may remain in the mailbox until the next successful run.

Data: content and headers of the form e-mails with everything visitors enter, such as name, e-mail address, telephone number and message, as well as sender and recipient addresses and technical information about the mail servers involved.

Data subjects: visitors to the Customer’s website who submit the form; recipients of the form e-mails at the Customer.

Stored and deletion: only the time, the assignment to the domain, where applicable the identifier of the test submission and the results of the authenticity check are stored in the database. The time and assignment are kept for 180 days; the most recent result of the authenticity check is kept with the domain until the next e-mail replaces it or the domain is deleted. The result of the authenticity check contains the IP address of the delivering mail server and the domain of the sender address; an alert names this domain only if it does not belong to the website. Content and full sender addresses of visitors are not stored in the database. The e-mail itself is deleted from the mailbox after successful processing, or with a delay in the event of a retrieval or deletion error.

Involved: the mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for the mailbox; the copies reach it directly via the MX records of our domain, not via forwarding, see Sub-processors.

Limitation: a match only confirms that the corresponding copy has arrived in the control mailbox, not receipt by the actual recipient or an entry in a CRM. Without a control mailbox the function is not available. Copies should not contain any special categories of personal data (§ 6(4)).

2. Client portal and monthly report to subscribers

Purpose: sending a monthly report on the forms of a website on behalf of the Customer, typically an agency to its own clients, and providing a portal with these reports.

Data: e-mail address, language, time and IP address of the subscription, time of confirmation (double opt-in) and of unsubscription; content of the report (domain, check results, figures).

Data subjects: clients and contact persons of the Customer who subscribe to the report.

Deletion: unconfirmed subscriptions after 30 days. After unsubscription, the record of subscription, confirmation and unsubscription is kept for three years so that the Customer can demonstrate consent. Everything is deleted at the latest together with the workspace; revoking a portal alone does not delete its subscribers.

Involved: the mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for sending.

3. Alerts, reports and incidents

Purpose: delivering alerts, digests and reports to the destinations the Customer sets up, and managing incidents.

Data: e-mail addresses, addresses of webhooks and chat channels, the ID of a Telegram chat after the recipient has linked it; content of the notifications (domain, event, time, link into the Service, for check alerts the report link, through which results and screenshots can be accessed without signing in; Telegram receives only the link to the domain page in the account, which requires signing in, instead of the report link); dispatch log; escalation delivery attempts per incident and destination (number, times, result, error); name or e-mail address of the person who acknowledges an incident, and the person responsible with due date.

Data subjects: employees and service providers of the Customer who receive alerts or handle incidents.

Deletion: destinations until the Customer removes them or deletes the domain; dispatch log after 90 days; collected notifications 30 days after dispatch; incidents while unresolved and for 180 days after resolution, together with their escalation delivery attempts.

Involved: the mail service provider (Namecheap, Inc. (Private Email), Phoenix, Arizona, USA) for e-mail; for chat services and webhooks, the providers chosen by the Customer (§ 9(6)).

4. Checking the Customer’s websites: persons who happen to be visible

Purpose: checking and monitoring the forms and their protection on the Customer’s domains for which it has provided proof of control. As long as proof is lacking for a domain, we check it only passively and are ourselves the controller for these checks; this is described in the Privacy Policy.

Data: a scan reads public pages of the domain: addresses of the pages, structure of the forms (field names, types, labels, required and visibility attributes, no values; the scanner reads the beginnings of pre-filled hidden fields and of data attributes only during the check and does not store them), embedded scripts, protective measures. It takes screenshots of the visible area of the home page and of the forms, and for active test submissions also of the response page; they are not redacted. They and the page content read may contain personal data that the Customer itself publishes, such as names and contact details of contact persons, photos or reviews. We store recipient addresses of forms only as a domain. For each check, the Service creates a report under a random link through which the results and screenshots can be accessed without signing in until the check is deleted; the link appears in the account and in alerts (item 3). Anyone who passes the link on passes on the report.

Data subjects: persons whose details are visible on the Customer’s website.

Deletion: check results including screenshots for no more than 13 months; the most recent check is kept as long as the domain is in the account. When the domain is removed, the domain’s data is deleted, including checks, findings and screenshots.

Note: a language model on our own server helps to classify forms whose purpose the rules alone cannot recognise. Forms classified in this way are never submitted and do not count towards the score or the verdict. Active test submissions (no more than five per check) contain only labelled test texts without personal data.

Action plan in eligible reports. For the verified-domain checks described in item 4, our local language model may also generate a short prioritised action plan from the hostname, form-page addresses, form types, CMS information, existing risk level and score where available, any identified plugin and selected failed or unclear findings. These fields may incidentally contain personal data. The prompt does not include screenshots, entered form values or the full page source. The plan supports the same form-protection check, does not change the website and does not determine its score or verdict. Temporary requests and responses are held in the internal job queue until collection or scheduled cleanup of entries more than one hour old; this is not an unconditional deletion guarantee during an outage. The collected plan is stored with the scan under the same retention and deletion rules. The role distinction for passive checks on unverified domains in item 4 continues to apply.

5. Login details of a test account for the scan behind the login

Purpose: reading forms on up to five pages behind a sign-in specified by the Customer. Only for verified domains, only by owners and administrators of a workspace, only in paid plans. The test account is used only in the full check, not in the browser checks (item 6).

Data: sign-in address, username and password of the test account, information on the sign-in fields; whatever is visible to this account on the pages read, insofar as it concerns the structure of the forms.

Data subjects: the person in whose name the test account is held, if it is assigned to a person; persons whose details are visible in the test account.

Protection: username and password are encrypted on the web server with the scan server’s public key and bound to the domain. Only the scan server can decrypt them, during the scan; the web server, the database and the backups contain only ciphertext. The login details are never displayed, never logged and never output via the interface; the user interface shows only the first character and the length of the username. Behind the login nothing is submitted, no active test is carried out and no screenshot is taken; pages for signing out, deleting or cancelling are not visited.

Deletion: until the Customer removes the login details or deletes the domain; removal overwrites the ciphertext and clears pending jobs. The copy attached to the individual scan job is cleared after the run, any remnants after one hour at the latest.

6. Form journeys and browser checks

Purpose: recurring checks whether configured forms work in a real browser up to the point before submission.

Data: form addresses, selectors, preceding clicks and check steps, choice of browser, responsible person and due date; results with status, technical error categories, sanitised error messages, timings and a screenshot of the form on which the input fields are covered. A personal reference arises mainly through the responsible person and through content that the Customer itself writes into steps or labels.

Data subjects: employees of the Customer to whom forms are assigned.

Deletion: configurations until the domain is deleted; the Customer can change or switch them off individually, but currently cannot remove them individually. Results after 13 months.

Limitation: browser checks do not submit anything. An independent second probe is provided for in the Service but is not currently set up; without it there is no confirmation from a second location. If it is set up with a third party, § 9 applies.

7. “Fix it for me”

Purpose: inserting a protective component into form code that the Customer pastes in.

Data: the code pasted in, if it contains personal data, for example in comments, sample values or hard-coded addresses.

Data subjects: persons whose details appear in the code.

Processing and deletion: a language model on our own server inserts the component. The code is processed only for the duration of the request and is not stored. The Service works without login details for the Customer’s systems and does not install anything on its servers.

8. Own branding (white-label)

Purpose: displaying the Customer’s brand on reports and in the client portal.

Data: company name, website, contact details and logo, where applicable the name and contact details of a contact person.

Data subjects: contact persons of the Customer.

Deletion: until the Customer changes or deletes the details, at the latest together with the workspace.

9. Supplementary figures without personal reference

The optional form and field error figures of the WordPress extension contain no input, field names or visitor identifiers and are kept for 13 months. The recorder for form journeys keeps steps in the Customer’s browser for no more than 15 minutes; local daily counters remain on its website for no more than 14 days. We list them here so that the picture is complete; by the way they are built, they are not Customer Data.

10. Form protection (formconfirmed)

This number applies only if the Customer switches on the form protection (Terms of Service clause 5.7).

Purpose: to assess submissions via forms on the Customer’s websites in order to recognise automated submissions.

How it works: When a page with a protected form is opened, a script in the visitor’s browser fetches a signed task from our server and solves it (proof of work). On submission, the Customer’s server presents the result to our verification interface. We check the signature, age, single use and domain of the check token as well as further signals such as the time taken to fill in the form, an invisible trap field and repeated requests from the same shortened address. If the Customer switches on the content check, a language model assesses the text of the message that the Customer’s server sends along. What is returned is a score with a recommended action and reasons; the Customer decides what happens to the submission. There are no cookies, no browser storage and no device fingerprint.

Data: the visitor’s IP address when fetching the task and during verification, address and domain of the page, times and time taken to fill in the form, whether the trap field was filled in, browser identifier in the web server log; only with the content check switched on, the text of the message.

Data subjects: visitors to the Customer’s websites who open a page with a protected form or submit such a form.

Storage and deletion: the IP address is stored only in shortened form (IPv4 without the last byte, IPv6 the first 48 bits) and as a hash with a key that changes daily, for one hour; used check tokens for eleven minutes at most; check results without IP address and without text (action, score, reasons, domain, category of the content check) for 30 days; daily figures without personal reference for 400 days; the web server log for 14 days. The text of a message is processed only in memory and is neither stored nor logged nor used for training.

Where: on our own servers in Poland, the language model on our own hardware; there are no additional sub-processors.

Annex 2 – Technical and organisational measures

The measures are set out on the page Technical and Organisational Measures. It forms part of this Agreement in the version published at the relevant time; changes are governed by § 8(3).

Annex 3 – Sub-processors

The authorised sub-processors are listed on the page Sub-processors. It forms part of this Agreement in the version published at the relevant time; changes are governed by § 9(2) and (3).

Open before launch: the intended mail service provider is Namecheap, Inc. (Private Email), Phoenix, Arizona, USA. The data processing agreement applicable to this use, the actual places of processing and the appropriate basis for transfer have yet to be documented. This version confirms neither a concluded agreement nor certification under the Data Privacy Framework.

Version

Version 2.2 of 29 October 2026, replacing version 2.1. Changed: new number 10 in Annex 1 on the formconfirmed form protection; it applies only if the Customer switches it on. No other provision changes.

Version 2.1 of 22 October 2026, replacing version 2.0. Changed: in the event of discrepancies, the Polish version now prevails instead of the German one; the Agreement is available in all official languages of the European Union (language clause). No other provision changes.

Version 2.0 of 11 October 2026, replacing the version of 9 October 2026. Changed: structure following Art. 28(3) GDPR with reference to the standard contractual clauses 2021/915; Annex 1 complete for each function, now including login details for the scan behind the login, form journeys and the limitations of the delivery check; the technical and organisational measures and the list of sub-processors are separate pages and form part of the Agreement as Annexes 2 and 3; choice between return and deletion, backups with expiry and re-execution of deletion requests, no fixed waiting period for urgent audits, liability for sub-processors as for our own conduct.