Data processing agreement (DPA)

This agreement governs how Ibram & Dawwa GmbH processes personal data on behalf of its customers when they use Regensbot. It meets the requirements of Art. 28 of the General Data Protection Regulation (GDPR). As of 28 October 2026 (version 2026-10-28).

This is a translation; the German Auftragsverarbeitungsvertrag is binding.

§ 1 Parties and conclusion of the agreement

Controller ("customer")

The business that uses Regensbot under the terms of service (AGB) of Ibram & Dawwa GmbH.

Processor ("provider")

Ibram & Dawwa GmbH
Johanna-Kinkel-Straße 1+2
93049 Regensburg
Germany

Represented by the managing director Ibrahim Anjro. Amtsgericht Regensburg, HRB 21570.

(1) The customer concludes this agreement by accepting Regensbot's terms of service. No separate signature is needed. The agreement is part of the terms of service. It is concluded in electronic form (Art. 28(9) GDPR). The provider stores which version of the terms was accepted and when (§ 3(2) AGB).

(2) The agreement applies to all personal data the provider processes for the customer in Regensbot.

(3) The provider is not required to appoint a data protection officer and has not appointed one, because fewer than 20 people at the provider regularly process personal data. The contact for data protection questions is the managing director Ibrahim Anjro, e-mail info@ibramdawwa-gmbh.de, phone +49 1575 1702770.

(4) If the customer itself processes the data on behalf of a third party (for example as an agency), this agreement counts as an agreement with a further processor under Art. 28(4) GDPR. The customer passes on its client's instructions through the channels in § 4 and ensures that its client has authorised the use of the provider and of the sub-processors in Annex 2. The customer exercises its client's rights under Art. 28(3)(h) GDPR on the client's behalf.

§ 2 Subject matter and duration

(1) The provider makes Regensbot available. Regensbot is software for the technical checking and monitoring of websites, among other things for search engines, AI crawlers, Google Search Console and Google Merchant Center. In doing so the provider processes personal data on behalf of the customer. The customer is the controller for the pages it has fetched and for the data it connects or uploads (Google services, server logs, files). § 3 describes the processing in detail.

(2) Data for which the provider is itself the controller are not covered by this agreement. These include user accounts with sign-in data and the proof of acceptance of the terms, sessions, security logs, billing and payment data, the servers' access logs, the access tokens of the Google connection with the account number and e-mail address of the person who connects, e-mail sending records and the operation of the crawler (domain block list, observing robots.txt, fetch limits across all customers). The privacy notice applies to these data.

(3) The agreement applies as long as the customer uses Regensbot. It ends when the last member of the customer's organisation deletes their account or the use of Regensbot ends altogether (for example by termination under the terms of service). Its obligations continue until all data have been deleted or returned under § 12.

§ 3 Nature, purpose and scope of the processing

(1) Nature of the processing: fetching, collecting, storing, analysing, summarising, displaying, transmitting to the customer and deleting. The processing is automated.

(2) Purpose: the provider processes the data only to provide the Regensbot functions the customer uses. It does not use the data for its own purposes.

(3) Location: the provider processes the data on a virtual server in Frankfurt am Main, Germany. Exceptions are listed in Annex 2.

(4) The following applies to the individual functions. Some functions run only if the customer switches them on or connects a service. Some retention periods depend on the plan: 7 days (Free), 90 days (Pro) or 365 days (Agency). Regensbot deletes data without a period of their own, for example crawl data, log totals, checklists and AI review results, at the latest 30 days after the website, organisation or account they belong to is deleted. With the organisation Regensbot deletes all of its data (§ 12).

3.1 Audits of single pages and website crawls

Regensbot fetches the pages the customer has audited and analyses them. In a crawl Regensbot reads several pages of a website. How many depends on the plan and on whether the customer has verified the website. § 12 AGB governs how the crawler observes robots.txt.

Types of data

Addresses (URLs) of the pages, HTTP status and redirects, page titles, meta descriptions, language details, a selection of link texts, details from structured data (for example name, web address and image of authors), audit results with short text excerpts. In stored excerpts Regensbot makes e-mail addresses, phone numbers and credentials unrecognisable, and in stored addresses of single audits the values of parameters that look like credentials or e-mail addresses. Regensbot does not store the full content of the pages in audits and crawls.

Data subjects

People named on the audited pages, for example authors, employees and contact persons of the customer.

Retention

Audit results, depending on the plan at the time of the audit, 7, 90 or 365 days, at the longest until 30 days after the website or the organisation is deleted. Crawl data until the website or the organisation is deleted; deleted for good 30 days later. Background jobs contain page addresses: their result is cleared after 30 days and the record deleted 90 days after completion; when the website is deleted for good, Regensbot clears its finished jobs at that point.

3.2 Rendering pages in a browser

Regensbot can render pages in a browser to find errors that only show then. This function runs on a separate server. It is not in operation at present. § 8(6) applies before it starts.

Types of data

The rendered page (HTML), screenshots and the browser's console and request logs. They can contain any data visible on the page.

Data subjects

As in 3.1.

Retention

For pages with an error, warning or pending confirmation 30 days. For pages without findings Regensbot deletes the files at once. Files never analysed after 2 days. The records of the individual renders (address, result) after the period of the current plan: 7, 90 or 365 days.

3.3 Server log data of the customer's websites

The customer can send Regensbot access logs (log data) of its web servers. Regensbot analyses how search engine and AI crawlers visit the website and measures response times.

The standard route is Regensbot's command-line tool. It filters the log data on the customer's own computer. It sends only lines from crawlers whose IP address is on the crawler operator's published address list. It first summarises visitors' lines into response-time statistics. It does not send individual visitor lines.

The customer can send or have retrieved full log lines (raw data) only if the provider has switched these routes on and the customer sets them up (HTTP upload, Cloudflare Logpush, Amazon S3 or Cloudflare R2). These routes are switched off at present.

Types of data

Standard route: IP address, user agent, time, requested address, status and amount of data of crawler requests; response-time statistics without reference to individual visitors. With raw data also: IP addresses, user agents, requested addresses, referrers and times of the website's visitors.

Data subjects

Visitors to the customer's websites; operators of crawlers.

Retention

Regensbot deletes raw data after analysis, at the latest 24 hours after receipt. They are not included in backups. Regensbot keeps permanently only daily values (count, amount of data and response times per host, page type, crawler and status), the first appearance of new addresses and log alerts. These values remain until the customer deletes the website or the organisation and are deleted for good 30 days later. Regensbot does not store visitors' IP addresses and user agents permanently. To check whether an address really belongs to a crawler, Regensbot queries the DNS. Regensbot keeps the result for confirmed crawlers for 7 days. It keeps unconfirmed addresses only as a cryptographic check value (HMAC), for 24 hours.

3.4 Data from the customer's Google services

The customer can connect its Google account to Regensbot: Google Search Console and optionally Google Merchant Center and Google BigQuery. Regensbot then reads data from these services with the customer's permission. Regensbot only reads; it changes nothing there. For Merchant Center the permission Google grants also allows changes; Regensbot uses it only to read. Regensbot's use and transfer to any other app of information received from Google APIs will adhere to the Google API Services User Data Policy, including the Limited Use requirements. The provider does not use data from Google APIs to develop, improve or train AI models, and does not pass it on for that purpose.

Types of data

Search Console properties, URL inspection results, performance data with queries, page and country, product samples and product issues from Merchant Center, aggregated values from BigQuery (for example click totals). BigQuery queries run in the customer's Google project.

Data subjects

Users of Google Search, where queries relate to a person; people named in product data or on audited pages.

Retention

Performance data with queries 24 hours, at most 7 days. Merchant Center data 30 days. URL inspection results until the customer removes the connection, at the longest until 30 days after the website or the organisation is deleted. The list of properties until the customer removes the connection, at the longest until 30 days after the organisation is deleted.

3.5 Uploaded evidence

The customer can upload files as evidence.

Types of data

Screenshots from Search Console and Merchant Center, Search Console exports (CSV, XLSX), redirect lists, URL lists, review registers (address, language, reviewing person, review date), approval registers (who approved generated content and when), original images with metadata, CI run results, PDF files and other files. Also file name, file type, size, time and the uploading person. The customer decides the content of the files.

Data subjects

Employees and agents of the customer, for example reviewing and approving persons; people named or shown in the files.

Retention

Depending on the plan at the time of upload, 7, 90 or 365 days from the upload, at the longest until 30 days after the website the file belongs to or the organisation is deleted. The customer can delete individual files itself earlier.

3.6 Checklists, workflows and releases

Types of data

Status of requirements, confirmations with the confirming person and a free note, change history with the acting person's identifier, incidents (for example removals, drills, migrations), URL lists, monitors and release records (commit, environment, time, check result). Of GitHub webhooks Regensbot stores only the identifier, event type and a check value, not the content.

Data subjects

The customer's users in Regensbot; people named in notes.

Retention

Checklists, history, incidents and URL lists until the customer deletes the website or the organisation; deleted for good 30 days later. Release records 365 days. GitHub webhook records 30 days.

3.7 Notifications by e-mail

Regensbot sends the customer's users notifications, for example about log alerts, rendering errors, possibly injected pages or links and completed jobs. These e-mails may contain short excerpts from the customer's websites. Sending runs through the e-mail service in Annex 2. Regensbot keeps the content of an e-mail encrypted until it is sent and deletes it when it is sent. If an e-mail could not be sent, Regensbot deletes its encrypted content 90 days after it was created. The provider is itself the controller for the sending record (recipient address, type of message, time) (§ 2(2)).

Data subjects

Recipients at the customer; people named in the excerpts.

3.8 AI review (optional)

Regensbot offers an optional AI review of content. It is switched off for Regensbot at present. It runs only if the provider switches it on and the customer switches it on for a website it has verified. It is off for every website until the customer switches it on. Switching it on is an instruction by the customer under § 4. The Free plan includes no AI reviews.

Types of data

Text excerpts of the audited pages, structured details (for example headings and alternative texts), images of pages and screenshots uploaded by the customer. Regensbot stores the result with verbatim quotes and reasoning, but no more page text than these quotes, and, if a person at the customer confirms or rejects a result, this decision with the person.

Data subjects

As in 3.1 and 3.5.

Recipient

Anthropic (Annex 2), only while the AI review is switched on. Under its commercial terms Anthropic does not use the data to train its models.

Retention

Results with quotes and reasoning and the decisions on them until the website or the organisation is deleted; deleted for good 30 days later. A counter record without quotes, reasoning or decisions remains for the monthly quota until the organisation is deleted.

3.9 Activity of the customer's users

Everyone who works for the customer in Regensbot has their own account. The provider is the controller for the account itself (§ 2(2)). By contrast, the provider processes these people's activity in the customer's organisation on behalf of the customer. Owners and admins of the organisation see these details.

Types of data

The person's identifier and name, role in the organisation, type and time of the activity (for example who started an audit, confirmed a requirement or uploaded a file), API key used or AI assistant connected.

Data subjects

Employees and agents of the customer.

Retention

As the data the activity belongs to (3.1 to 3.8).

§ 4 Instructions

(1) The provider processes the data only on documented instructions from the customer. This also applies to transfers to a third country. Exception: EU or German law obliges the provider to process. The provider then informs the customer beforehand, unless the law prohibits this.

(2) Instructions are this agreement, the terms of service and the settings the customer makes in Regensbot. Examples: starting an audit or a crawl, setting up a log source, connecting a Google account, switching on the AI review for a website, deleting data.

(3) The customer gives further instructions in text form, for example by e-mail to info@ibramdawwa-gmbh.de. The owners and admins of the customer's organisation may give instructions.

(4) If the provider considers an instruction unlawful, it informs the customer without delay. It may suspend carrying it out until the customer confirms or changes the instruction.

(5) The provider treats instructions that go beyond the agreed scope of Regensbot as a request for a change of service.

§ 5 Customer obligations

(1) The customer is responsible for the lawfulness of the processing. It needs a legal basis for every processing activity. This applies in particular to log data of visitors to its websites and to uploaded files.

(2) The customer enters only addresses (URLs) of websites it owns or manages with the owner's permission. It may also have single, publicly accessible pages checked that it may lawfully have checked. It runs crawls only for websites it owns or manages with the owner's permission. Crawls beyond the limit for unverified websites require the customer to verify the website. § 11(1) and (2) AGB apply.

(3) The customer informs the data subjects under Art. 13 and 14 GDPR, for example the visitors to its websites in its privacy notice.

(4) Regensbot is not intended for special categories of personal data (Art. 9 GDPR) or data relating to criminal convictions and offences (Art. 10 GDPR). The customer does not upload or send such data.

(5) The customer keeps its credentials, API keys and upload links secret. It removes people from its organisation who should no longer have access.

(6) The customer keeps copies of the results it needs itself (§ 17(1) AGB).

(7) The customer informs the provider without delay if it notices errors or irregularities in the processing.

§ 6 Confidentiality

(1) The provider uses only people and service providers who are bound to confidentiality in writing or in text form or are subject to a statutory duty of secrecy.

(2) Only the provider's managing director has access to the server and the database. He accesses the customer's data only where this is necessary for operation, troubleshooting or a request from the customer.

(3) The duty of confidentiality continues after this agreement ends.

§ 7 Security of processing

(1) The provider takes the technical and organisational measures under Art. 32 GDPR. Annex 1 describes them.

(2) The provider may adapt the measures to the state of the art. The level of protection must not fall. It documents material changes and updates Annex 1.

§ 8 Sub-processors

(1) The customer gives the provider general authorisation to use sub-processors (Art. 28(2) GDPR). By concluding this agreement the customer authorises the sub-processors in Annex 2.

(2) If the provider wants to add or replace a sub-processor, it informs the customer at least 30 days in advance in text form, usually by e-mail to the owners of the customer's organisation, and on this page.

(3) The customer may object to the change within these 30 days in text form for an important data protection reason, stating the reason. If the parties find no solution, the customer may terminate the Regensbot contract for cause with effect from the date the change takes effect. § 7(6) AGB applies to fees paid in advance.

(4) The provider contractually binds every sub-processor to the same data protection obligations as in this agreement. These include sufficient guarantees of appropriate technical and organisational measures (Art. 28(4) GDPR). The provider is liable to the customer for the sub-processor's compliance with these obligations.

(5) Services the customer itself chooses and connects to Regensbot are not sub-processors. These include its Google account (Search Console, Merchant Center, BigQuery), Cloudflare, Amazon S3, Cloudflare R2, GitHub and its AI assistant (for example Claude or ChatGPT). The customer's contracts with the respective provider apply to these services. Stripe is not a sub-processor either: Stripe processes payment data as an independent controller and receives no data under this agreement.

(6) The provider will name the provider of the server for rendering pages (3.2) under paragraph 2 before it puts the function into operation.

§ 9 Processing outside the EU

(1) The provider processes the data in the European Union. A transfer to a country outside the EU or the European Economic Area takes place only if the conditions of Art. 44 to 49 GDPR are met. For companies in the USA these are the adequacy decision on the EU-U.S. Data Privacy Framework, where the company is certified under it, and EU standard contractual clauses.

(2) Annex 2 states where such a transfer can occur.

§ 10 Assistance to the customer

(1) The provider assists the customer with appropriate technical and organisational measures so that it can meet data subjects' rights (Art. 12 to 23 GDPR). The customer can view and delete many data in Regensbot itself, for example a website or individual evidence files. Regensbot deletes the whole organisation when its last member deletes their account; on request in text form the provider also deletes it otherwise.

(2) If a data subject contacts the provider directly, the provider forwards the request to the customer without delay. It does not answer it itself unless the customer instructs it to.

(3) The provider assists the customer with the obligations under Art. 32 to 36 GDPR: security of processing, notification of breaches to the supervisory authority, communication to data subjects, data protection impact assessment and prior consultation of the supervisory authority. In doing so it takes into account the nature of the processing and the information available to it.

(4) The provider informs the customer without delay of inspections and measures by a supervisory authority insofar as they concern the customer's data.

(5) For assistance that goes beyond Regensbot's functions and is not due to a breach by the provider, the provider may charge a reasonable fee. It announces the fee beforehand.

§ 11 Notification of personal data breaches

(1) The provider notifies the customer of every breach of the security of the customer's personal data without delay after becoming aware of it.

(2) The notification goes by e-mail to the owners of the organisation concerned. As far as known, it contains:

• the nature of the breach, the categories and approximate number of data subjects and records concerned,
• a contact point for further information,
• the likely consequences,
• the measures taken and proposed.

The provider supplies missing details as soon as it has them.

(3) The provider takes measures without delay to remedy the breach and mitigate its consequences.

(4) Notifying the supervisory authority and communicating with data subjects is the customer's responsibility. The provider assists it.

(5) The contact point for personal data breaches and security questions is info@ibramdawwa-gmbh.de, phone +49 1575 1702770. If the customer notices a breach, it reports it there.

§ 12 Deletion and return

(1) During the term Regensbot deletes data automatically according to the periods in § 3.

(2) If the customer deletes a website or the last member of its organisation deletes their account, Regensbot first marks the data as deleted. The customer can then no longer use them. 30 days later Regensbot deletes them for good, including the website's audit results and evidence files. Only counter records without addresses or content remain for the plan's quotas.

(3) If the customer changes to a plan with a shorter retention period, Regensbot no longer shows older audit results and deletes them when the period that applied when they were created ends; evidence files keep the period set at upload; Regensbot deletes render records after the new plan's period. A restriction because of late payment (§ 8(2) AGB) is not a plan change.

(4) Until the end of the contract the customer can download evidence files itself and retrieve audit results through the application programming interface (API) or MCP.

(5) After the end of the contract the provider deletes all data it processes on behalf of the customer within 30 days at the latest. Copies in backups expire within 14 more days. Until then the provider uses them only to restore operation after an outage. Until final deletion the customer may request in text form that the provider hand over the data still held in a common, machine-readable format.

(6) The provider's statutory retention obligations remain unaffected. On request the provider confirms deletion in text form.

§ 13 Evidence and audits

(1) On request the provider makes available to the customer all information necessary to demonstrate compliance with the obligations under Art. 28 GDPR.

(2) The customer may carry out inspections itself or have them carried out by an auditor. The auditor must be bound to confidentiality and may not be a competitor of the provider.

(3) The customer announces an inspection with reasonable notice, as a rule at least 14 days in advance. Where there is a specific reason, such as a personal data breach, shorter notice is enough. Inspections take place during normal business hours and may not disrupt operation unreasonably. Other customers' data remain protected.

(4) The provider may first provide evidence through documents and information, for example this agreement with Annex 1. Inspections in data centres follow the hosting providers' terms.

(5) Each party bears its own costs of the inspection.

§ 14 Liability

(1) Towards data subjects the parties are liable under Art. 82 GDPR.

(2) Towards data subjects the provider is liable only if it has breached its obligations as a processor under the GDPR or acted against the customer's lawful instructions (Art. 82(2) sentence 2 GDPR).

(3) If one party has paid a data subject full compensation, it may claim back from the other party the share that corresponds to that party's responsibility (Art. 82(5) GDPR).

(4) Between the customer and the provider, the liability rules in § 15 AGB apply. They do not limit liability towards data subjects under Art. 82 GDPR.

§ 15 Final provisions

(1) In the event of conflicts between this agreement and the terms of service or other agreements of the parties, this agreement takes precedence on all data protection matters.

(2) § 18 of the terms of service applies to changes to this agreement. § 7(2) applies to Annex 1 and § 8 to Annex 2. Changes that lower the level of protection are excluded.

(3) If a provision of this agreement is invalid, the remaining provisions stay valid.

(4) The law of the Federal Republic of Germany applies. The terms of service govern the place of jurisdiction.

(5) The German version is binding. The English version is a translation.

Annex 1: Technical and organisational measures

This annex describes the measures under Art. 32 GDPR as they are actually implemented at Regensbot. As of 28 October 2026.

1. Organisation

• People and service providers who work for the provider are bound to confidentiality (§ 6).
• Only the managing director has access to the server, the database and the backups.
• Changes to Regensbot are checked before they go live: automated tests and a review of the change.

2. Confidentiality

Physical access. Regensbot runs on a rented virtual server at Hostinger in Frankfurt am Main. The provider runs no server rooms of its own. The hosting provider controls access to the data centre.

Access to systems.

• The application can only be reached internally on the server. The only access from outside is the nginx web server.
• The provider administers the server only through privileged access. There is no web-based administration interface.
• Regensbot stores passwords only as Argon2id hashes. They must be 15 to 128 characters long. Regensbot rejects common and leaked passwords. For the leaked-password check only a short part of a hash leaves the server (k-anonymity).
• After 100 failed attempts in a row Regensbot locks the account. Sign-in attempts are limited per account and per IP address range.
• The server manages sessions. They end after 30 minutes of inactivity, at the latest after 12 hours. After sign-in each session gets a new identifier. The session cookie is set as Secure, HttpOnly and SameSite=Lax.
• Sensitive actions, such as export and deletion, require the password again; this confirmation lasts 15 minutes.
• Forms are protected against cross-site request forgery.

Access to data.

• Organisations are separated from each other. Every query is limited to the organisation. Regensbot treats objects of another organisation as non-existent.
• Roles with fixed permissions: owner, admin, member. The last owner cannot be removed.
• API keys have a fixed scope of permissions and can be revoked. AI assistants connect through OAuth 2.1 with PKCE. Codes are valid for 120 seconds, access tokens for one hour. Refresh tokens are renewed on every use; Regensbot detects reuse and reports it by e-mail.
• The database can only be reached locally through a Unix socket. The application uses a database role without administrator rights.
• The configuration file with the keys is readable only by the system administrator (root); systemd passes the values to the services at start.
• Only signed-in members of the organisation or holders of a signed link get evidence files; such a link is valid for 15 minutes, at most one day. The files are served with a restrictive Content Security Policy.

Encryption and pseudonymisation.

• All connections from outside are encrypted with TLS. HTTP redirects to HTTPS; HSTS lasts one year. Regensbot sends e-mails only over TLS-encrypted connections.
• Regensbot stores session identifiers, API keys, one-time links, OAuth codes and tokens and upload tokens only as HMAC-SHA256 check values.
• Regensbot encrypts Google tokens, credentials for log sources, webhook secrets and e-mail content until it is sent with AES-256-GCM. The master key is not in the backups and can be rotated.
• Regensbot never stores visitors' IP addresses from log data permanently; the code prevents them from being logged or written to the database. Regensbot stores unconfirmed crawler addresses only as an HMAC check value.
• In stored excerpts Regensbot makes e-mail addresses, phone numbers and credentials unrecognisable, and in stored addresses of single audits the values of parameters that look like credentials or e-mail addresses.
• The server's disks are not encrypted. The application does not additionally encrypt the database, evidence files and backups. They are in directories that only the Regensbot or PostgreSQL service account and the system administrator can access.

3. Integrity

Transmission.

• Regensbot fetches only public addresses. Every resolved IP address is checked when the connection is made. Private networks and cloud providers' metadata services are blocked, also at operating system level.
• Security headers: Content Security Policy, X-Content-Type-Options, Referrer-Policy "no-referrer", HSTS, X-Frame-Options, Permissions-Policy. Pages with forms or secrets are not cached.

Input control.

• Regensbot logs security-relevant events with time, acting identifier and shortened IP address, for example sign-ins, failed attempts and new API keys, and deletes them after 12 months. The log contains no passwords, tokens, keys or full e-mail addresses.
• Every audit records which person, API key or AI assistant started it. Changes to checklists are in the change history.
• In the application's access logs Regensbot replaces secrets in addresses with a placeholder. The database's error logs contain no data from the queries.

4. Availability and resilience

• The services run with minimal rights: without additional privileges, with a read-only system except for one data directory, with a system call filter and with a memory limit. The backup service has no network access.
• Rate limits protect sign-in, registration, invitations and export. Every plan has quotas. At most 30 audits per hour are possible per domain. A crawl makes at most one request per second, for unverified websites one every two seconds.
• The size of requests is limited.
• E-mails and background jobs are retried on errors. After a crash, jobs continue.
• Rendering pages (3.2) runs, once in operation, separately on its own server without a database: browser sandbox, containers without administrator rights, restricted system calls, outgoing traffic only through a proxy with the same security rules.
• The provider promises no particular availability (§ 13 AGB).

5. Recoverability

• Every night Regensbot backs up the database and the evidence files, without raw log data. Every database backup is checked for readability. Backups are kept for 14 days.
• The backups are currently on the same server.
• Before every update an additional backup is made. An update can be rolled back to the previous version.

6. Data protection by default

• AI review, Google connection and raw log data are switched off until they are switched on.
• Regensbot sets only one necessary cookie. It uses no analytics or tracking tools and loads no scripts or fonts from third-party servers.
• Regensbot applies retention periods automatically (§ 3). Server logs are deleted after 14 days; the provider sets this period on the server, not in the application.

Annex 2: Sub-processors

As of 28 October 2026.

Notes:

• The provider will name the provider of the server for rendering pages (3.2) under § 8(2) before the function goes live.
• Stripe Payments Europe, Limited processes payment data as an independent controller. Stripe is not a sub-processor and receives no data under this agreement.
• Services the customer connects itself are not sub-processors (§ 8(5)).
• For page speed measurements (Google PageSpeed Insights and Chrome UX Report) Regensbot sends Google only the address of the checked page, no personal data.
• To check whether an IP address from log data belongs to a crawler, the server makes a DNS query for that address.
• Regensbot only downloads plug-in security advisories (Wordfence), version information (WordPress.org) and crawlers' address lists. It sends no personal data in doing so.