Document version 1.0 · Effective 2 October 2026

This Data Processing Agreement ("DPA") is concluded under Article 28(3) of Regulation (EU) 2016/679 ("GDPR") between the Merchant and the Provider identified in section 1, in respect of the personal data the Provider processes on the Merchant's behalf through the application Consentia (the "App").

1. Parties

The Provider (processor)

Legal name	TRANSYLVANIA MARKETING LTD SRL
Company registration code	43230933
Registered address	Str. Crișanei 2, 550012 Sibiu, România
Email	contact@transilvaniamarketing.ro

The Merchant (controller) is the natural or legal person operating the online store on which the App is installed. The Merchant is identified by the store domain recorded at installation and by the account details held by the store platform. The Merchant does not need to restate its identity for this DPA to be valid and complete.

The email address above is the Provider's designated channel for all data protection matters under this DPA, including documented instructions, data subject requests forwarded by the Merchant, audit requests and breach correspondence. Written correspondence to the registered address is also accepted.

The Provider has not designated a data protection officer. The contact point for all data protection matters is the email address above.

2. How this DPA is concluded

2.1 Acceptance by installation and use. This DPA is a binding legal act within the meaning of Article 28(3) GDPR. It is concluded, and becomes binding on both parties, when the Merchant installs the App on its store, and it continues to apply for as long as the App remains installed or the Provider holds any personal data processed on the Merchant's behalf. No signature, countersignature or separate acceptance step is required.

2.2 If the Merchant does not agree. A Merchant who does not accept this DPA must not install the App and, if it is already installed, must uninstall it. In that case the deletion described in section 17 applies.

2.3 A signed copy is available on request. The Merchant may at any time ask the Provider, by email, for a copy of this DPA signed by the Provider, for its own records or for its accountability file under Article 5(2) GDPR. The Provider will provide one. Where the Merchant's internal rules, its own DPA template, or a request from a supervisory authority require a separately executed document, the Provider will negotiate and sign one in good faith. A separately signed document prevails over this DPA to the extent of any conflict between them.

2.4 Each installation is a separate agreement. Where one person operates several stores, this DPA applies separately to each installation. Nothing in this DPA creates any relationship between different Merchants, and the Provider does not combine data from different Merchants' stores into any cross-merchant product or dataset.

3. Scope, and relationship with other documents

3.1 What this DPA governs. This DPA governs the processing of Visitor personal data that the Provider carries out on behalf of the Merchant through the App, as detailed in Annex 1.

3.2 What this DPA does not govern.

a) Merchant account data. For the store domain, the store platform access token and the server access logs, the Provider acts as controller in order to provide, secure, maintain and support the App. That processing is described in the Provider's Privacy Policy and is not processing on the Merchant's behalf. The qualification in section 5.5 applies to the access logs.

b) The store platform. The App runs on the store platform. the store platform's own processing as operator of the platform is governed by the Merchant's own agreements with the platform provider, including the store platform's data processing terms. The Provider is not a party to those agreements.

c) Google. Any processing Google performs in connection with the Merchant's own Google tags, products or accounts is governed by the Merchant's own agreements with Google. The Provider is not a party to those agreements. What the App transmits to Google is stated in Annex 1, point 9.

d) The Merchant's own store. Cookies, tags, pixels and scripts placed on the store by anyone other than the App, and the Merchant's own privacy practices, are the Merchant's responsibility.

3.3 Order of precedence. In respect of the processing of personal data on the Merchant's behalf, this DPA prevails over the App's terms of service and over the Privacy Policy. The Privacy Policy remains the authoritative description of the processing for which the Provider is controller. Where the Privacy Policy and the Annexes to this DPA describe the same processing, they are intended to be read consistently; if they conflict, the Annexes prevail for processing on the Merchant's behalf.

4. Definitions

4.1 "Personal data", "processing", "controller", "processor", "sub-processor", "data subject", "personal data breach" and "special categories of personal data" have the meanings given in Articles 4 and 9 GDPR.

4.2 "Visitor" means any person who visits the Merchant's store and to whom the consent banner is displayed. "Consent Record" means a single row stored by the App describing one consent-related event, as itemised in Annex 1. "Visitor Data" means the personal data described in Annex 1. "Applicable Data Protection Law" means the GDPR, Romanian Law 190/2018, Romanian Law 506/2004, and any other data protection or electronic communications privacy law applicable to the processing.

5. Roles of the parties

5.1 For Visitor Data, the Merchant is the controller and the Provider is the processor. The Merchant determines the purposes and means of the processing; the Provider processes Visitor Data only to provide the App's functions to that same Merchant.

5.2 Nothing in this DPA makes the Provider a joint controller with the Merchant, with the store platform or with Google. The Provider does not decide why Visitor Data is collected and does not use it for its own purposes.

5.3 The Provider does not act as controller in respect of Visitor Data. If the Provider were ever to process Visitor Data for a purpose of its own, it would do so as controller and would need its own legal basis; the Provider does not do this, and any change would be published in advance under section 21.

5.4 The Merchant acknowledges that the App is a standardised, multi-tenant service. The Provider determines the technical means by which the service is delivered — the architecture, the database schema, the security measures and the sub-processors — within the limits set by this DPA and subject to the Merchant's right to object under section 12.

5.5 Server access logs — an honest qualification. The Provider's hosting provider keeps ordinary HTTP access logs for every request reaching the App. Each entry contains the request time, method and path, response status and duration, the requesting IP address (srcIp) and the browser user-agent string (clientUa). These logs are generated by the hosting infrastructure, not by the App's own code; they are not linked to Consent Records, are not used to identify Visitors, are not used for analytics, statistics, advertising or profiling, and are not disclosed to anyone. They are retained for 7 days and then expire automatically at the hosting provider. The Provider processes them as controller under Article 6(1)(f) GDPR, for the security and availability of the service. However, because requests made by the banner reach the App through the store platform's app proxy, those log entries may contain the IP addresses of the Merchant's Visitors. To the extent that such log entries are regarded as processed on the Merchant's behalf, the Provider applies to them the whole of this DPA, and they are described as a separate line in Annex 1. This qualification is stated so that nothing in this DPA can be read as a broader claim than the Provider can keep.

6. Subject matter, duration, nature and purpose of the processing

Article 28(3), opening paragraph.

6.1 Subject matter. The processing of Visitor Data necessary to provide the App to the Merchant.

6.2 Nature of the processing. Collection of consent events through the store platform's app proxy; recording and storage in a database; structuring and retrieval; display in the Merchant's admin interface; aggregation into counts and rates; export to a CSV file at the Merchant's request; transmission of the consent state to Google Consent Mode v2 and to the store platform's customer privacy interface; and erasure.

6.3 Purpose of the processing. Exclusively the four functions of the App: (i) displaying the consent banner; (ii) giving effect to the Visitor's choice by transmitting it to Google Consent Mode v2 and to the store platform's customer privacy interface; (iii) maintaining a register of consents that the Merchant can export as CSV, as evidence of the consent obtained; and (iv) showing the Merchant aggregated statistics about that Merchant's own store. The App performs no function beyond these four. It is not an analytics product, not an advertising product, not a marketing product and not a customer relationship management product.

6.4 Duration. From installation of the App until the earlier of (i) deletion of the Merchant's data under section 17, or (ii) the date on which the Provider no longer holds any personal data processed on the Merchant's behalf. Individual Consent Records are in any event deleted 12 months after the event they record. Access logs are retained for 7 days.

6.5 Further detail on the nature, purpose, duration and frequency of the processing is set out in Annex 1, which forms an integral part of this DPA.

7. Types of personal data and categories of data subjects

Article 28(3), opening paragraph.

7.1 Categories of data subjects. Visitors of the Merchant's online store to whom the consent banner is displayed.

7.2 Categories of personal data. Set out in Annex 1, point 7, field by field.

7.3 What is excluded. The consent register contains no name, email address, telephone number, IP address, order data, customer account data, device identifier or browser fingerprinting data of any kind. These exclusions are unconditional: they are not limited to a particular plan, tier, configuration or region, and no setting the Merchant may choose waives them. They are a design choice, not a configuration option. The qualification in section 5.5 concerns the hosting provider's access logs only.

7.4 Special categories. The App is not designed to process special categories of personal data within the meaning of Article 9 GDPR, or data relating to criminal convictions and offences within the meaning of Article 10 GDPR. The Merchant must not instruct the Provider to process such data through the App and must not configure the banner in a way that causes such data to be submitted to it.

7.5 Children. The App has no means of determining a Visitor's age and performs no age verification, age inference or age-based targeting. Where the Merchant's store is directed at children, it is for the Merchant, as controller, to assess the applicable rules on the consent of minors, including Article 8 GDPR and the national age threshold in the relevant Member State.

7.6 Pseudonymous nature of the records. A Consent Record contains no direct identifier of the Visitor. The consent identifier it stores is a random value generated by the store platform. The Provider holds no key, table or additional dataset that would allow it to link that value to a named individual, an email address, an order or a customer account. The Provider nevertheless treats Consent Records as personal data and applies this DPA to them in full. The consequences for data subject rights are stated in section 14.4.

8. Processing only on documented instructions

Article 28(3)(a).

8.1 The Provider processes Visitor Data only on the Merchant's documented instructions, including with regard to transfers of personal data to a third country or an international organisation, unless required to do otherwise by Union or Member State law to which the Provider is subject. In that case the Provider will inform the Merchant of that legal requirement before processing, unless the law prohibits such information on important grounds of public interest.

8.2 What constitutes documented instructions. The Merchant's documented instructions consist of, and are limited to:

a) this DPA, including its Annexes; b) the Provider's Privacy Policy, as published from time to time; c) the Merchant's installation and activation of the App, and its configuration of the banner through the App's settings (including the texts, the categories offered, the display rules and whether the floating consent control described in Annex 1, point 11 is enabled); d) the Merchant's use of the App's functions, including requesting a CSV export; and e) any further instruction the Merchant sends by email to the address in section 1 and that the Provider accepts in writing.

8.3 Instructions outside the scope of the App. An instruction that would require a change to the App's functionality, to its data model, to its security measures or to its sub-processors is outside the standardised service. The Provider is not obliged to accept such an instruction. The Provider will tell the Merchant, without undue delay, if it considers an instruction to fall outside the scope of the App or to be technically impossible, and the parties will discuss it in good faith. If no agreement is reached, the Merchant may terminate under section 20.

8.4 The Provider will not use Visitor Data to develop, train, improve or evaluate any machine-learning or artificial-intelligence model, will not sell it, will not share it with advertising networks or data brokers, and will not build, publish or sell cross-merchant benchmarks, industry reports or any other aggregated product derived from Merchants' data.

9. Obligation to inform the Merchant if an instruction infringes the law

Article 28(3), final sub-paragraph.

9.1 The Provider will immediately inform the Merchant if, in its opinion, an instruction infringes the GDPR or any other Union or Member State data protection provision.

9.2 In that case the Provider may suspend execution of the instruction concerned until the Merchant withdraws, confirms or amends it. A suspension under this section is not a breach of the Provider's obligations and does not affect the continued operation of the rest of the App.

9.3 This section does not oblige the Provider to carry out a general legal review of the Merchant's processing, and the Provider's silence on an instruction is not advice that the instruction is lawful. The Merchant remains responsible for the lawfulness of its instructions.

10. Obligations and rights of the Merchant

Article 28(3), opening paragraph.

10.1 The Merchant's rights. The Merchant is entitled to: give documented instructions under section 8; access, view and export the Consent Records of its store at any time while the App is installed; receive the information and assistance described in sections 14, 15 and 18; be notified of changes to the sub-processors under section 12 and to object to them; be notified of personal data breaches under section 15.2; and terminate under section 20.

10.2 The Merchant's obligations. The Merchant:

a) determines and documents the legal basis for the processing of Visitor Data and warrants that the processing it instructs is lawful. The Provider does not determine the legal basis. Typically a Merchant relies on Article 6(1)(c) GDPR, compliance with the legal obligation under Article 7(1) GDPR to be able to demonstrate that the data subject consented, and/or Article 6(1)(f) GDPR, its legitimate interest in operating a functioning consent mechanism and keeping proof of the choices made; b) publishes its own privacy policy and cookie information and provides Visitors with the information required by Articles 13 and 14 GDPR and by the national rules transposing Article 5(3) of Directive 2002/58/EC (in Romania, Law 506/2004), including the existence of the consent register; c) configures the banner lawfully — in particular so that refusing is as easy as accepting, that non-essential cookies are not set before consent, and that the texts shown are accurate for its store. The Provider supplies the mechanism; the Merchant decides what it says and how it behaves; d) enables a withdrawal mechanism. The App provides a floating control that reopens the preferences window so that a Visitor can change a previous choice at any time. It is for the Merchant to enable it, or to provide an equivalent means of withdrawal, so that withdrawing consent is as easy as giving it (Article 7(3) GDPR); e) handles data subject requests addressed to it as controller, with the Provider's assistance under section 14; f) exports the register before expiry where it needs to retain evidence of consent for longer than 12 months (section 17.2). Once records are deleted the Provider cannot restore them; g) does not submit special categories of data or data relating to criminal convictions through the App (section 7.4); h) keeps its contact details current so that notices under sections 12 and 15.2 can reach it; and i) remains responsible for its own accountability obligations, including its record of processing activities (Article 30 GDPR) and, where required, its data protection impact assessment (Article 35 GDPR).

11. Confidentiality

Article 28(3)(b).

11.1 The Provider ensures that any person authorised to process Visitor Data — including its own personnel, contractors and any individual acting under its authority — has committed to confidentiality or is under an appropriate statutory obligation of confidentiality, and that the commitment survives the end of that person's engagement.

11.2 The Provider takes steps to ensure that any natural person acting under its authority who has access to Visitor Data does not process it except on the Merchant's instructions, unless required to do so by Union or Member State law (Article 32(4) GDPR).

11.3 Access to Visitor Data is limited to the persons who need it in order to operate, secure, maintain and support the App.

11.4 This section applies in addition to, and not instead of, any confidentiality obligation the parties owe each other under the App's terms of service or under general law.

12. Sub-processors

Article 28(2) and 28(4).

12.1 General authorisation. The Merchant gives the Provider general written authorisation to engage sub-processors for the processing of Visitor Data, subject to the conditions in this section. That authorisation is given by accepting this DPA under section 2.1.

12.2 Current sub-processors. The sub-processors engaged at the date of this version are listed in Annex 3. Apart from them, the Provider discloses Visitor Data to no one. There is no advertising network, no data broker, no analytics vendor, no email provider and no artificial-intelligence vendor in the Provider's processing chain for the App.

12.3 Conditions imposed on sub-processors. Where the Provider engages a sub-processor, it does so by a contract or other legal act imposing on that sub-processor the same data protection obligations as are set out in this DPA, in particular the obligation to provide sufficient guarantees to implement appropriate technical and organisational measures so that the processing meets the requirements of the GDPR. The Provider remains fully liable to the Merchant for the performance of its sub-processors' obligations (Article 28(4) GDPR).

12.4 Notification of changes, and the right to object. The Provider will inform the Merchant of any intended addition or replacement of a sub-processor at least 30 days before that change takes effect, by email to the address associated with the Merchant's installation, by notice in the App's admin interface, or by publishing an updated version of Annex 3 and of the Privacy Policy with a new version number and date — and in the case of a material change, by email as well. The Provider's standing commitment is that an amendment affecting the sub-processors is published before the change takes effect, never after.

12.5 The Merchant may object to an intended change on reasonable grounds relating to data protection, by email, within the notice period. If it objects, the parties will discuss the objection in good faith and the Provider will use reasonable efforts to make an alternative arrangement available. Where no alternative is reasonably available, the Merchant may terminate under section 20 by uninstalling the App before the change takes effect, in which case the deletion in section 17 applies. If the Merchant does not object within the notice period, the change is deemed approved.

12.6 Urgent replacement. Where a sub-processor must be replaced urgently, for reasons outside the Provider's control, to maintain the security or availability of the service, the Provider may make the replacement and will inform the Merchant as soon as possible afterwards, stating the reason. The Merchant's right to object and to terminate under section 12.5 then applies retrospectively.

12.7 The Provider will provide the Merchant, on request by email, with the information about a sub-processor that is necessary for the Merchant's own accountability, to the extent the Provider holds it and is not prevented from disclosing it by confidentiality obligations.

13. International transfers

13.1 The App's hosting and database are located in a European Union region. The Provider does not transfer Visitor Data outside the European Economic Area for any purpose of its own, and will not do so on the Merchant's behalf unless instructed in writing by the Merchant and unless a transfer mechanism under Chapter V GDPR is in place.

13.2 If the Provider ever intends to process Visitor Data outside the European Economic Area, it will publish an amendment under section 21 before that change takes effect, stating the transfer mechanism relied on, and section 12.4 to 12.6 will apply by analogy, including the Merchant's right to object and to terminate.

13.3 Two matters fall outside the Provider's control and require the Merchant's attention. the store platform: any processing or transfer carried out by the store platform as part of operating its platform is governed by the store platform's own terms, privacy documentation and data processing terms, to which the Merchant is a party. Google: the App transmits to Google only the granted-or-denied consent state, with no identifier and no personal data (Annex 1, point 9); any further processing or transfer by Google is governed by the Merchant's own agreements with Google.

14. Assistance with data subject rights

Article 28(3)(e); Chapter III GDPR.

14.1 The Provider assists the Merchant, by appropriate technical and organisational measures and insofar as this is possible, in fulfilling the Merchant's obligation to respond to requests to exercise the rights of data subjects under Chapter III GDPR: the right of access (Article 15), to rectification (Article 16), to erasure (Article 17), to restriction of processing (Article 18), to notification (Article 19), to data portability (Article 20), to object (Article 21), and not to be subject to automated individual decision-making (Article 22).

14.2 Requests must go to the Merchant. Visitors must address their requests to the Merchant, as controller. If a Visitor contacts the Provider directly about data processed on the Merchant's behalf, the Provider will not respond to the request on its merits and will not disclose or delete data. It will tell the Visitor to contact the Merchant and, where it can identify the store concerned, will inform the Merchant without undue delay.

14.3 How the Provider assists. The Provider assists principally by making the self-service functions of the App available to the Merchant: the register view, the CSV export, and the automated deletion described in section 17. Where those functions are not sufficient, the Provider will, on a written request from the Merchant sent by email, take reasonable steps to locate, provide, correct, restrict or delete a specific Consent Record, subject to section 14.4. The Provider may charge a reasonable fee for assistance that is disproportionate or repetitive, having told the Merchant the estimated cost beforehand and given it the opportunity to withdraw the request.

14.4 A practical limit, stated plainly (Article 11 GDPR). Because the register holds no name, email address, telephone number, IP address, order data, customer account or device identifier, the Provider has no means of identifying which Consent Record, if any, relates to a given individual. The consent identifier is a random pseudonym generated by the store platform and the Provider holds no key linking it to a person. In relation to Consent Records the Provider is therefore generally unable to identify the data subject within the meaning of Article 11 GDPR, and the rights of access, rectification, erasure, restriction and portability may be impossible to exercise against the record itself. A Visitor who can supply the exact consent identifier may ask the Merchant to have the corresponding record located. In any event, all Consent Records are deleted after 12 months. The Provider will state this limitation to the Merchant in response to any request it cannot execute, so that the Merchant can rely on Article 11(2) GDPR in its own reply to the data subject.

14.5 Withdrawal of consent. A Visitor who wishes to change a previous choice can do so through the consent banner, or through the floating consent control that the App leaves on the page where the Merchant has enabled it. Changing the choice creates a new Consent Record reflecting the new state; it does not alter or delete the earlier record, which remains in the register as evidence of what was chosen at that earlier time, until it expires under section 17.2.

15. Assistance with Articles 32 to 36

Article 28(3)(f).

15.1 Security (Article 32). The Provider implements and maintains the technical and organisational measures set out in Annex 2 and assists the Merchant in ensuring compliance with Article 32 by maintaining them, by keeping Annex 2 accurate, and by answering the Merchant's reasonable questions about them.

15.2 Personal data breaches (Articles 33 and 34). If the Provider becomes aware of a personal data breach affecting Visitor Data, it will notify the Merchant without undue delay (Article 33(2) GDPR), by email to the address associated with the Merchant's installation. The notification will contain the information then reasonably available to the Provider, and in any event, as it becomes available: the nature of the breach; the categories and approximate number of data subjects and of records concerned; the likely consequences; the measures taken or proposed to address the breach and to mitigate its effects; and a contact point for further information. Where the information cannot be provided at the same time, it will be provided in phases without further undue delay. The Provider will cooperate with the Merchant and take the remedial steps reasonably required, so that the Merchant can assess its own obligations towards its supervisory authority (Article 33(1) GDPR, which requires notification without undue delay and, where feasible, not later than 72 hours after the controller becomes aware of the breach) and towards affected data subjects (Article 34 GDPR). The Provider will not notify a supervisory authority or any data subject about a breach affecting Visitor Data on the Merchant's behalf unless the Merchant instructs it to do so or the law requires it. The Provider's notification to the Merchant is not an admission of fault or of liability.

15.3 Data protection impact assessment (Article 35). On the Merchant's written request, the Provider will make available the information about the App that the Merchant reasonably needs in order to carry out a data protection impact assessment, including the Annexes to this DPA and the Privacy Policy, and will answer reasonable follow-up questions. The Provider does not carry out the assessment for the Merchant and does not advise on whether one is required.

15.4 Prior consultation (Article 36). On the Merchant's written request, the Provider will provide the Merchant with the information it reasonably needs in order to consult its supervisory authority under Article 36 GDPR, and will respond to reasonable requests for information made in the course of such a consultation.

15.5 Scope of the assistance. The Provider's obligations under this section are limited to the information available to it and take into account the nature of the processing and the standardised character of the App. The Merchant acknowledges that the Provider, as processor, does not hold the information about the Merchant's own store, its own purposes or its own other tools.

16. the store platform compliance notifications

16.1 The App responds to the store platform's mandatory compliance notifications: the customer data request notification, the customer data erasure notification, and the shop data erasure notification sent after uninstall.

16.2 The practical consequence of section 7.3 is that a customer data request or a customer data erasure notification will generally find no identifying customer data in the App to return or to erase, because the App holds no name, email address, telephone number, IP address in its register, order data, customer account or device identifier, and does not associate a Consent Record with a store customer.

16.3 The Provider's response to the shop data erasure notification is described in section 17.3.

17. Deletion and return of the data at the end of the processing

Article 28(3)(g).

17.1 Return. The Merchant can obtain the Visitor Data processed on its behalf at any time while the App is installed, in a structured, commonly used and machine-readable format, by using the CSV export function in the App's admin interface. That function is the Provider's standing means of returning the data, available without any request to the Provider and without charge.

17.2 Automated deletion after 12 months. Consent Records are deleted 12 months after the event they record. The deletion is carried out by an automated task in the App that starts with the server and repeats daily, and that deletes records older than 12 months across all stores. Deleted records are no longer available in the register, in CSV exports or in statistics, and the Provider cannot restore them. A Merchant who needs to retain evidence of consent for longer must export the register before expiry.

17.3 Deletion on uninstall. When the App is uninstalled, the session is deleted and the App ceases to have any access to the store. On receipt of the store platform's shop data erasure notification, the Provider deletes, in a single database transaction, both the sessions and all Consent Records of that store. The banner configuration is held as an application-owned metafield on the store platform and is removed there when the application installation ends.

17.4 On termination generally. On termination of this DPA for any reason, the Provider will delete all Visitor Data processed on the Merchant's behalf, in accordance with sections 17.2 and 17.3, unless Union or Member State law requires it to store the data, in which case the Provider will inform the Merchant of that requirement and will keep the data only for as long and only to the extent required. The Merchant is responsible for exporting what it wishes to keep before termination; the Provider is not obliged to retain data in order to allow a later export.

17.5 Backups — stated honestly. The Provider's hosting provider takes routine backups for disaster recovery. Data deleted under this section may therefore persist in those backups until the backups themselves expire in the ordinary rotation. The Provider does not use such backups for any purpose other than disaster recovery, does not restore them in order to recover deleted data, and does not make them accessible to anyone outside the sub-processors listed in Annex 3. The Provider does not state a fixed backup rotation period in this DPA because that period is set by the hosting provider and may change; the Provider will state the current position in writing on the Merchant's request.

17.6 The Provider will confirm the deletion in writing on the Merchant's request.

18. Information, audits and inspections

Article 28(3)(h).

18.1 The Provider makes available to the Merchant all information necessary to demonstrate compliance with the obligations laid down in Article 28 GDPR. That information includes this DPA and its Annexes, the Privacy Policy, the description of the App's functions and data model, and written answers to the Merchant's reasonable questions about the processing.

18.2 The Provider allows for and contributes to audits, including inspections, conducted by the Merchant or by another auditor mandated by the Merchant, in respect of the processing carried out on the Merchant's behalf.

18.3 How an audit is conducted. An audit request must be made in writing by email, with reasonable advance notice of at least 30 days, stating its scope. The Provider will first satisfy the request by providing documentation and written answers, which the parties agree will usually be sufficient given the nature and scope of the processing. Where documentation is not sufficient to address the Merchant's specific concern, the Merchant may carry out a remote audit, or an on-site inspection at the Provider's registered office during normal business hours, at a date agreed between the parties. An audit must not unreasonably disrupt the Provider's business, must not give access to the data or systems of other Merchants, to third-party confidential information, or to information the Provider is prohibited from disclosing, and is subject to confidentiality. Any auditor mandated by the Merchant must not be a competitor of the Provider and must sign a confidentiality undertaking.

18.4 Frequency and cost. The Merchant may audit once in any 12-month period at the Provider's cost. The Provider may charge its reasonable costs for any additional audit, having told the Merchant the estimated cost beforehand. No frequency or cost limit applies where an audit is required by a competent supervisory authority, is necessary following a personal data breach affecting the Merchant's data, or follows a material change notified under section 12 or 21.

18.5 Sub-processors. Where an audit concerns a sub-processor, the Provider will satisfy the request by making available the information it holds about that sub-processor and by exercising, on the Merchant's behalf and so far as its contract with the sub-processor allows, its own audit rights. The Merchant has no direct audit right against a sub-processor under this DPA.

18.6 No certification is claimed. The Provider does not hold, and does not claim to hold, any security certification, third-party audit report, code of conduct adherence or attestation within the meaning of Articles 40 to 43 GDPR. The Provider does not have an independent audit report to offer in place of an audit. This is stated expressly so that the Merchant can take it into account in assessing its processor and does not rely on a guarantee that does not exist.

18.7 The Provider will cooperate, on request, with a competent supervisory authority exercising its powers in relation to the processing carried out on the Merchant's behalf, and will inform the Merchant without undue delay of any binding request from a supervisory authority or a law enforcement authority concerning Visitor Data, unless prohibited from doing so by law.

19. Liability

19.1 Each party is liable in accordance with Article 82 GDPR and the applicable law.

19.2 Nothing in this DPA limits or excludes either party's liability towards a data subject, towards a supervisory authority, or to the extent that liability cannot be limited or excluded under the applicable law. Nothing in this DPA transfers to the Merchant a liability that the GDPR places on the Provider as processor, or vice versa.

19.3 Any limitation of liability agreed in the App's terms of service applies to claims between the parties under this DPA, to the extent permitted by the applicable law and subject to section 19.2. This DPA does not itself create, extend or reduce any such limitation. The Provider makes no statement in this DPA about insurance cover and does not represent that any is in place.

20. Duration and termination

20.1 This DPA takes effect on installation of the App and remains in force for as long as the Provider processes personal data on the Merchant's behalf.

20.2 The Merchant may terminate this DPA at any time by uninstalling the App. Section 17 then applies. Termination of this DPA does not of itself terminate any separate subscription or billing arrangement, which remains governed by the App's terms of service and by the store platform's billing rules.

20.3 Sections 11 (confidentiality), 17 (deletion and return), 18 (information and audits), 19 (liability) and 22 (governing law) survive termination for as long as is necessary to give them effect.

21. Amendments to this DPA

21.1 The Provider may amend this DPA, for example to reflect a change in the App's functionality, in the sub-processors, in the location of the data, or in the applicable law or the guidance of a supervisory authority. Each version carries a version number and an effective date, shown at the top of this document.

21.2 Where an amendment materially affects the processing of personal data — in particular any change to the categories of data in Annex 1, to the exclusions in section 7.3, to the retention periods in section 17, to the security measures in Annex 2, to the sub-processors in Annex 3, or to the location of the data under section 13 — the amended version will be published before the change takes effect, and the Provider will notify the Merchant in accordance with section 12.4.

21.3 Continued use of the App after the effective date of an amended version constitutes acceptance of that version. A Merchant who does not accept an amendment may terminate under section 20 before the effective date.

21.4 An amendment cannot reduce the protection afforded to data subjects below what Article 28 GDPR requires. Any provision of an amended version that would do so is void to that extent, and the corresponding provision of the previous version continues to apply.

22. Governing law, jurisdiction and supervisory authority

22.1 This DPA is governed by Romanian law, as supplemented by the GDPR as directly applicable Union law, without prejudice to any mandatory data protection rule of the Merchant's own Member State and to any mandatory consumer protection rule that may apply.

22.2 The courts having jurisdiction over the Provider's registered office in Sibiu, Romania, have jurisdiction over disputes arising out of this DPA, without prejudice to any mandatory rule of jurisdiction that applies to the Merchant and to the right of a data subject to a remedy under Articles 77 to 79 GDPR.

22.3 The Provider is established in Romania. Its supervisory authority is the Autoritatea Națională de Supraveghere a Prelucrării Datelor cu Caracter Personal (ANSPDCP), B-dul G-ral. Gheorghe Magheru 28-30, Sector 1, 010336 Bucharest, Romania, anspdcp@dataprotection.ro, www.dataprotection.ro. The Merchant's own supervisory authority is determined by the Merchant's own establishment.

22.4 If any provision of this DPA is held invalid or unenforceable, the remainder continues in force and the invalid provision is replaced by a valid provision having, so far as possible, the same effect.

23. Contact

TRANSYLVANIA MARKETING LTD SRL Str. Crișanei 2, 550012 Sibiu, România Company registration code 43230933 contact@transilvaniamarketing.ro

Use this address for documented instructions, data subject requests, audit requests, breach correspondence, a request for a signed copy of this DPA, and any question about this document. See also the Privacy Policy, which describes the processing for which the Provider acts as controller.

Annex 1 — Details of the processing

Forms an integral part of the DPA. Referred to in sections 6 and 7.

1 to 6. Summary

Item	Detail
Controller	The Merchant operating the online store on which the App is installed
Processor	TRANSYLVANIA MARKETING LTD SRL, CUI 43230933, Str. Crișanei 2, 550012 Sibiu, România
Subject matter	Processing of Visitor personal data necessary to provide the Consentia cookie-consent app
Nature of the processing	Collection through the store platform's app proxy; recording; storage in a PostgreSQL database; structuring and retrieval; display in the Merchant's admin interface; aggregation into counts and rates; export to CSV on the Merchant's request; transmission of the consent state to Google Consent Mode v2 and to the store platform's customer privacy interface; automated erasure
Purpose	(i) displaying the consent banner; (ii) giving effect to the Visitor's choice; (iii) maintaining a register of consents and its CSV export as evidence; (iv) aggregated statistics for that same Merchant's store. No other purpose
Duration	From installation until deletion under section 17. Consent Records: maximum 12 months per record. Access logs: 7 days
Frequency	Continuous and event-based: one record per consent-related event
Categories of data subjects	Visitors of the Merchant's online store to whom the consent banner is displayed
Special categories	None. The App is not designed to process data under Article 9 or Article 10 GDPR
Transfers outside the EEA	None by the Provider. Hosting and database in a European Union region

7. Categories of personal data

For each consent-related event the App stores one row, containing the following and nothing else.

Data element	Description	Example
Consent identifier	A pseudonymous, random identifier generated by the store platform. Not created by the Provider and not derived from any identifying attribute of the Visitor. Optional: may be absent	—
Action	One of exactly four values: banner displayed, accepted everything, refused everything, chose by category	accept_all
Preferences	Yes or no: functional/preference cookies allowed	true
Statistics	Yes or no: analytics cookies allowed	false
Marketing	Yes or no: marketing cookies allowed	false
Region code	A country or country-subdivision code obtained from the store platform's customer privacy interface. Not a precise location, not a postal address, not GPS coordinates, not an IP address. Optional	RO, ROMS, DE
Page path	The path of the page on which the banner was shown. Optional	/collections/all
Banner text version	The version number of the wording displayed at that moment, kept as evidence of what the Visitor was shown	1
Date and time	The moment of the event	2026-10-02T11:14:09Z
Store domain	The store on which the event occurred	example-store.com

Separate line — server access logs. Request time, method and path, response status and duration, the requesting IP address (srcIp), and the browser user-agent string (clientUa). Generated by the hosting infrastructure, not by the App's code. Not linked to Consent Records. Retained 7 days, then expiring automatically at the hosting provider. Processed by the Provider as controller under Article 6(1)(f) GDPR for the security and availability of the service; to the extent such entries are regarded as processed on the Merchant's behalf, the whole of the DPA applies to them. See section 5.5.

8. What is not processed

The consent register contains none of the following, under any circumstances and through any mechanism: names; email addresses; telephone numbers; IP addresses; order data of any kind; customer accounts or any data from them; device identifiers; browser fingerprinting data of any kind.

The App does not: carry out profiling within the meaning of Article 4(4) GDPR; track a Visitor across websites; set any advertising cookie of its own; make automated decisions within the meaning of Article 22 GDPR; score, segment, rank, categorise or predict anything about an individual; sell data; share data with advertising networks; or use data to train any model. Recording the yes-or-no state of three consent categories is the execution of the Visitor's own choice, not an inference about the Visitor.

9. What is transmitted to Google

When a Visitor makes a choice, and for the default state that applies before any choice, the App transmits the consent state only — granted or denied, per category — to Google Consent Mode v2, across all seven signals:

ad_storage · ad_user_data · ad_personalization · analytics_storage · functionality_storage · personalization_storage · security_storage

No identifier and no personal data are transmitted to Google: no consent identifier, no page path, no region code, no store domain, no name, no email address, no IP address — nothing beyond the granted-or-denied state per category.

10. What is transmitted to the store platform

The App transmits the Visitor's choice to the store platform's customer privacy interface, so that the platform and any other app or tag relying on it can honour that choice. This transmission consists of the consent state.

11. Withdrawal mechanism

The App provides a floating control that reopens the preferences window, allowing a Visitor to change a previous choice at any time. The Merchant can enable it. Changing the choice creates a new Consent Record reflecting the new state.

12. Storage locations

Data	Where it is stored
Consent Records	PostgreSQL database hosted by Railway, European Union region
Sessions, including the store platform access token	Same database
Banner configuration chosen by the Merchant	Application-owned metafield on the store platform, not in the Provider's database
Server access logs	Hosting provider's logging infrastructure, 7 days

Annex 2 — Technical and organisational measures

Forms an integral part of the DPA. Referred to in sections 15.1 and 18. Article 32 GDPR.

The measures below are the measures actually implemented. The Provider lists no measure it does not apply, and claims no certification, audit report or attestation. Where a measure in this Annex ceases to be accurate, the Annex will be amended under section 21 and the Merchant notified under section 12.4.

1. Data minimisation and pseudonymisation (Article 32(1)(a))

• The consent register is designed to contain no name, email address, telephone number or IP address, and no order, customer-account or device data. Data that is not held cannot be compromised, so minimisation is the single most important protective measure here. The exclusions in Annex 1, point 8 are a design choice, not a configuration option.
• The only link to a person is the random consent identifier generated by the store platform. The Provider holds no key, table or additional dataset enabling re-identification.
• The App requests one the store platform permission only: read access to themes (read_themes), used exclusively to tell the Merchant whether the banner is active in the published theme. The App does not request and does not have access to protected customer data; within the store platform's classification it operates at Level 0 — no customer data. It cannot read orders, customers, carts, checkouts, payment data, fulfilment data or any customer account, because it does not hold the permissions required.

2. Encryption in transit

• All traffic to and from the App uses HTTPS/TLS.
• The Provider makes no statement in this Annex about encryption at rest, because that is a property of the hosting provider's managed database service and not a measure the Provider implements itself. The Provider will state the hosting provider's current position in writing on the Merchant's request.

3. Authentication and request integrity

• The Merchant's admin interface is reachable only through an authenticated the store platform session; the App relies on the store platform's OAuth flow and session tokens, and holds no password of its own for Merchants.
• Webhook requests are verified against their HMAC signature; a request with an invalid signature is rejected with HTTP 401 and is not processed.
• Events sent by the banner are accepted only through the signed store platform's app proxy. The signature is verified before anything is stored; a request that cannot be attributed to an installed store is rejected with HTTP 401.
• GET requests to the event endpoint perform no action and are rejected with HTTP 405.

4. Input validation

• The action field is accepted only if it is one of exactly four permitted values; any other value is rejected with HTTP 400 and nothing is stored.
• A request whose body is not valid JSON is rejected with HTTP 400.
• Free-text fields are length-limited before storage: consent identifier 64 characters, region code 8 characters, page path 255 characters. Anything longer is truncated.
• The three category values are coerced to strict booleans, so no arbitrary value can be stored in them.
• Database access goes through a parameterised query layer, so values submitted by a client are never interpreted as database commands.

5. Tenant separation

• Every stored record is keyed to the store domain taken from the verified the store platform session, never from client-supplied input.
• All reads — the register, the statistics and the CSV export — are scoped to the requesting store. One Merchant cannot see, export or affect another Merchant's records.
• Data from different Merchants' stores is not combined into any cross-merchant product or dataset.

6. Access control and credentials

• Access to the database is restricted to the App and to the persons who need it in order to operate, secure, maintain and support it.
• Credentials and secrets are supplied to the App through environment variables and are not stored in the source code.
• The store platform access token is stored solely in order to operate the App, is never exported, is never shared with anyone outside the sub-processors in Annex 3, and is deleted on uninstall. Offline access tokens are configured to expire.
• Confidentiality undertakings apply to every person authorised to process the data (DPA section 11).

7. Availability and resilience (Article 32(1)(b) and (c))

• Hosting, application runtime and managed PostgreSQL database are provided by Railway in a European Union region.
• The hosting provider takes routine backups for disaster recovery. The honest consequence for deleted data is stated in DPA section 17.5.
• A failure of the scheduled deletion task is caught and logged and does not stop the server; the task runs again at the next daily interval.

8. Enforced retention and erasure

• An automated task inside the App deletes Consent Records older than 12 months across all stores. It starts shortly after the server starts and repeats daily. The retention promise is enforced by code that actually runs, not only by text on a page.
• On the store platform's shop data erasure notification, the sessions and all Consent Records of that store are deleted in a single database transaction, so a partial deletion cannot result.
• On uninstall, the session is deleted and the App ceases to have any access to the store.
• Server access logs expire automatically after 7 days at the hosting provider.

9. Logging and monitoring

• The App writes operational log lines for compliance webhook handling and for the outcome of the deletion task, so that the execution of these obligations can be verified. Those log lines record the store domain and counts, not Visitor data.

10. Governance — stated honestly

• The Provider has not obtained any security certification and has not undergone a third-party security audit or penetration test. It adheres to no approved code of conduct or certification mechanism within the meaning of Articles 40 to 42 GDPR.
• The Provider has not designated a data protection officer. The contact point for all data protection matters is contact@transilvaniamarketing.ro.
• The Provider does not state a formal, documented process for regularly testing, assessing and evaluating the effectiveness of these measures within the meaning of Article 32(1)(d) GDPR. The measures are reviewed when the App changes. The Provider states this expressly rather than claiming a process it does not operate, so that the Merchant can take it into account when assessing its processor.
• No transmission over the internet and no storage system can be guaranteed to be absolutely secure. The Provider does not claim absolute security; it claims the measures set out above.

Annex 3 — List of sub-processors

Forms an integral part of the DPA. Referred to in section 12. Current as at the effective date of this version.

Sub-processor	Service provided	Data processed	Location of processing
Railway	Application hosting, managed PostgreSQL database, logging infrastructure	Consent Records, sessions including the store platform access token, server access logs	European Union region
The store platform provider	The platform on which the store and the App run; the app proxy through which banner events are received; storage of the banner configuration as an application-owned metafield	Consent events in transit; the banner configuration; the consent state transmitted to the Customer Privacy API	As governed by the store platform's own terms, privacy documentation and data processing terms, to which the Merchant is a party

Notes.

1. Apart from these sub-processors, the Provider discloses Visitor Data to no one. There is no advertising network, no data broker, no analytics vendor, no email provider and no artificial-intelligence vendor in the Provider's processing chain for the App. 2. The platform provider is listed for completeness and transparency. The platform provider is also the Merchant's own platform provider, and the Merchant has a direct contractual relationship with the platform provider covering that platform processing. 3. Google is not a sub-processor of the Provider. The App transmits to Google only the granted-or-denied consent state, with no identifier and no personal data (Annex 1, point 9). Any processing Google performs is governed by the Merchant's own agreements with Google. 4. Full legal entity details of each sub-processor are available from the Provider on request by email. 5. Changes to this Annex are notified under DPA section 12.4, and the Merchant may object under section 12.5.

End of Data Processing Agreement · version 1.0