GDPR & Data Processing Agreement

This page sets out the data-protection commitment of BEO TECHNOLOGY SPÓŁKA Z OGRANICZONĄ ODPOWIEDZIALNOŚCIĄ and the binding Data Processing Agreement (DPA) under Article 28 GDPR that applies whenever we process the personal data of your website visitors on your behalf through the SGTM.space Service.

1. Our GDPR commitment

When you use server-side tagging Containers, personal data of your Visitors (such as their IP address and user agent) passes through our infrastructure. We are committed to processing that data only on your instructions and in line with the GDPR. In summary, we encrypt data in transit, apply access controls and data minimization, vet our sub-processors, use Standard Contractual Clauses for transfers outside the EEA, retain data only as long as needed, and assist you with data-subject requests, data-protection impact assessments and audits. The binding terms follow below.

2. Definitions

"Controller", "Processor", "Sub-processor", "Personal Data", "Processing", "Data Subject" and "Personal Data Breach" have the meanings given in the GDPR. "Customer" means the account holder acting as Controller; "Operator", "we", "us" means BEO Technology sp. z o.o. acting as Processor; "Visitor Data" means the personal data of the Customer's website visitors processed through the Service.

3. Roles of the parties

With respect to Visitor Data, the Customer is the Controller and the Operator is the Processor. With respect to account, billing and login-security data, the Operator acts as a controller as described in the Privacy Policy.

4. Subject-matter and duration

The subject-matter is the processing of Visitor Data necessary to provide the Service. Processing lasts for the duration of the agreement between the parties plus the return/deletion period described in section 15.

5. Nature and purpose of processing

We process Visitor Data to receive, proxy and route server-side tagging requests through the Cloudflare Worker to the sGTM backend, to pass the Visitor's country and region code to that backend for the Container's region-specific settings, to record request metadata and analytics, and to operate any add-ons the Customer enables (Better Loader, Cookie Extender, Bot Filtering and Request Enricher). Outside a Live debug session (below), the GA4/measurement payload contained in requests is passed through and is not decoded or stored by the Worker.

Live debug. When the Customer starts a Live debug session for a Container, we also capture the traffic of the testers who join it, for the duration the Customer chooses (15, 30 or 60 minutes), so that the Customer can see how its tags behave. A tester joins by opening the start link the Customer gives them: it shows the tester a page saying what is captured and until when, with a link to leave the session, and sets the _sgtm_dbg cookie on the Customer's site until the session's scheduled end. Only the requests of a browser that carries that cookie are captured, together with the server container's reports on those requests (section 6); nothing changes for other Visitors. Before starting a session, the Customer confirms in the Service that the testers know their requests are shown there; the confirmation and its version are recorded. What a session captures is shown to the Customer in the Container's Live debug tab and is described in section 6.

6. Personal data and data subjects

Categories of data subjects: the Customer's website visitors and end users, including the testers who join a Live debug session.

Categories of personal data processed through the Service:

• Visitor IP address (received from the CF-Connecting-IP header and stored as received);
• User-Agent, Referer and Host headers;
• request URI/path and query, HTTP method, status code, response size, duration and timestamp;
• request category (for example GA4, Universal Analytics, gtag.js or other);
• cookies read and re-issued with an extended lifetime by the Cookie Extender add-on;
• the Visitor's country and region code (for example US and USCA), derived from the Visitor IP address at the edge and forwarded to the Customer's Container with every request, whether or not an add-on is enabled, so that the region-specific settings of the Customer's server container work; the Visitor IP address is not part of it;
• approximate location and network data (country, region, city, postal code, coordinates, time zone and network) derived from the Visitor IP address at the edge, and device and browser details derived from the User-Agent, forwarded to the Customer's Container by the Request Enricher add-on; of these, the Visitor IP address, region, city, postal code and coordinates are forwarded only when the Customer enables detailed location, apart from the country and region code in the previous item.

Records of these requests are stored in Google BigQuery, and aggregated daily request counts per Container are stored in the Operator's database. Neither the country and region code nor the data the Request Enricher adds is stored: that data travels only with the request to the Customer's Container.

Live debug sessions additionally process, for the testers only:

• the requests their browsers send to the Container's tagging and Better Loader hosts, as the Cloudflare Worker receives them (address, headers and body, the body up to a size limit), what the Worker did with each request and the response it returned;
• where the page agent runs in the tester's browser (brought by Better Loader, or by a snippet or a web GTM tag template the Customer installs), what the page puts in its dataLayer and the tracking requests it sends, including those sent directly to Google, Google Ads, Meta or other advertising services;
• where the Customer installs the Live debug tag templates in its GTM containers, which web and server tags fired for the events they report on and the event data the server container processed. The Worker adds an X-SGTM-Debug header, holding the session identifier and the request's identifier, to the testers' data requests it forwards to the Customer's Container, and the server tag template uses it to send its reports on those requests back to the Worker.

This data is redacted before it is stored: cookie values are kept only for tracking cookies (such as _ga, FPID, _gcl_*, _fbp and _fbc) and for the session's own _sgtm_dbg cookie, and every other cookie is shown only by its shape; Authorization, API-key and GTM preview headers and GTM environment credentials in addresses are masked; IP addresses in the client IP headers and in IP fields (such as ip_override) are kept with their last part hidden; values under a fixed set of keys for an e-mail address, a phone number, a first or last name, a street, postal code or city, or a user identifier (such as email, phone, first_name and user_id; a GA4 parameter such as ep.phone counts by its own name), every value of user-data objects, and plain e-mail addresses anywhere are replaced by a description of their shape (their kind and length, or the first characters of a SHA-256 hash), never the value. All other data, such as the user agent, page addresses, pseudonymous tracking identifiers and values under other keys, is kept as received. Captured data is stored only in a Cloudflare Durable Object for that session and is never written to BigQuery or to the Operator's database.

7. Processing on documented instructions

We process Visitor Data only on the Customer's documented instructions, which consist of this DPA and the Customer's configuration in the Service. We will inform the Customer if, in our opinion, an instruction infringes the GDPR. We will not process Visitor Data for our own purposes.

8. Confidentiality

We ensure that persons authorized to process Visitor Data are bound by appropriate confidentiality obligations.

9. Security of processing (Article 32)

We implement appropriate technical and organizational measures, including: encryption of data in transit (TLS) and at rest; access control on a need-to-know basis; network isolation between tenants; logging and monitoring; secure software development and backups; incident response; and sub-processor vetting. Because Visitor IP addresses are stored as received, the Customer should take this into account in its own risk assessment. Live debug data is redacted before it is stored (section 6), can be read only with an access token issued for that session, and is deleted when the session ends (section 15). A summary of measures is provided in Annex 3.

10. Sub-processors

The Customer grants general authorization for the Operator to engage the sub-processors listed below. We will inform the Customer of intended changes (additions or replacements) and give the Customer the opportunity to object on reasonable data-protection grounds. We impose data-protection obligations on each sub-processor equivalent to those in this DPA.

Sub-processor	Purpose	Location
Cloudflare	Request Worker (proxy and logging), DNS and custom hostnames, KV configuration, R2 storage, Turnstile, Durable Objects (storage of Live debug sessions)	Global; Live debug sessions of a Container hosted in the EU are stored in Cloudflare's EU jurisdiction
Google Cloud	Cloud Run container hosting and BigQuery request-log storage	EU (europe-west1) by default
DigitalOcean	Dedicated and shared node hosting	EU (Frankfurt) by default

11. International transfers

Visitor Data is processed in EU regions by default. Where a sub-processor processes data outside the EEA, or where the Customer selects a non-EU Container region (for example US or Asia), transfers are made under appropriate safeguards such as the European Commission's Standard Contractual Clauses or an adequacy decision. The Customer acknowledges that its choice of Container region determines where Visitor Data is processed. A Live debug session of a Container hosted in the EU (its server runs in a region in an EU member state when the session starts) is stored in Cloudflare's EU jurisdiction; for any other Container, Cloudflare chooses where the session is stored, which may be outside the EEA, under the safeguards above.

12. Assistance to the controller

Taking into account the nature of the processing, we will assist the Customer by appropriate measures to respond to requests from data subjects, and to comply with the Customer's obligations under Articles 32-36 GDPR (security, breach notification, data-protection impact assessments and prior consultation). We provide controls in the Service to delete Visitor Data, to configure which cookies the Cookie Extender re-issues, to choose whether the Request Enricher forwards detailed location and to stop a Live debug session, which deletes what it captured.

13. Personal data breaches

We will notify the Customer without undue delay (and in any event within 72 hours of becoming aware) of any Personal Data Breach affecting Visitor Data, and will provide the information reasonably required for the Customer to meet its own notification obligations.

14. Audits

We will make available information necessary to demonstrate compliance with Article 28 GDPR and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates, on reasonable prior notice, subject to confidentiality and to reasonable limits on frequency and cost. We may rely on third-party certifications and reports where appropriate.

15. Retention, return and deletion of data

Retention during the Service. Visitor Data in request records, including the Visitor IP address and user agent, is retained for 90 days. After 90 days those records are deleted and only the aggregated daily request counts per Container survive: a number of requests per Container, per day, per request category, containing no IP address, user agent or any other identifier relating to a Visitor. Those aggregates are no longer personal data and are retained for as long as the usage figures and invoices they substantiate. The same 90-day window applies to webhook, security and provisioning logs, save that a provisioning entry documenting an unresolved technical fault is retained until the fault is resolved.

Live debug. What a Live debug session captures is deleted when the Customer stops the session, at once or within a minute, and at the latest when the session expires, at most 60 minutes after it started. Only a marker that the session has ended, without any captured data, remains for two hours, so that late requests are refused. The Operator's database keeps only the session's metadata (who started it and when, the Container, the duration, the page address entered, when it was stopped, and the confirmation with its version), without any captured data, and deletes it 90 days after the session's scheduled end.

On termination. On termination of the Service, and at the Customer's choice, we will delete or return Visitor Data and delete existing copies (including de-provisioning Containers and removing request logs, BigQuery records and KV configuration) within a reasonable period, unless retention is required by law. Aggregated daily counts may be retained where they substantiate invoices issued to the Customer. We will certify deletion on request.

16. Liability

Liability under this DPA is allocated in accordance with Article 82 GDPR and is subject to the limitation of liability in the Terms & Conditions, to the extent permitted by law.

17. Acceptance and precedence

This DPA is governed by Polish law and the GDPR. It can be accepted electronically in the customer panel; the accepted version and date are recorded. An enterprise customer may instead request a counter-signed copy. This DPA prevails over the Terms & Conditions on matters of personal-data processing.

18. Annexes

Annex 1, details of processing: subject-matter, duration, nature and purpose, types of personal data and categories of data subjects as set out in sections 4-6.

Annex 2, sub-processors: the list in section 10.

Annex 3, technical and organizational measures: TLS encryption in transit and encryption at rest; role-based access control; tenant network isolation; logging and monitoring; secure development lifecycle and backups; incident response; and sub-processor due diligence, as described in section 9.

Annex 4, transfer mechanism: Standard Contractual Clauses or an adequacy decision, as applicable under section 11.

For data-protection enquiries contact BEO Technology sp. z o.o. at [email protected].