Data Processing Agreement

This Data Processing Agreement (“DPA”) sets out the terms on which Pixadoro Ltd., Blvd. Cherni Vrah 47, 1407, Sofia, Bulgaria, company number 206777328, VAT: BG206777328, the operator of Kukie.io (“Kukie”, “we”, “us”), processes personal data on behalf of its customers (“Customer”, “you”). It contains the terms required by Article 28(3) of the General Data Protection Regulation (EU) 2016/679 (“GDPR”).

This DPA forms part of our Terms of Service (the “Terms”). It applies automatically to every Customer who accepts the Terms, from the moment the account is created, and needs no separate signature. If your organisation needs a copy countersigned by us for its records, email support@kukie.io.

This DPA covers the personal data of visitors to your websites, and of people who send a request through a site's privacy request form, that the Services process for you. It does not cover the data we collect about you as our customer (your account, team members and billing details). For that data we are the controller, and our Privacy Policy applies.

1. Definitions

Terms defined in the Terms of Service have the same meaning in this DPA. In addition:

• “Applicable Data Protection Law” means the GDPR, the Bulgarian Personal Data Protection Act, the UK GDPR and the Data Protection Act 2018, the Swiss Federal Act on Data Protection, and United States state privacy laws such as the California Consumer Privacy Act, in each case to the extent they apply to the processing of Customer Personal Data.
• “Controller”, “Processor”, “Data Subject”, “Personal Data”, “Processing” and “Supervisory Authority” have the meanings given in the GDPR.
• “Customer Personal Data” means the Personal Data of End Users and Requesters that we process on your behalf when providing the Services, as described in Annex I.
• “Dashboard” means the customer area of the Services at app.kukie.io.
• “End User” means a visitor to a website on which you have installed the Banner Script.
• “Requester” means a person who sends a request through the privacy request form of one of your websites (Annex I, item 8), whether or not they are an End User.
• “Personal Data Breach” means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.
• “Standard Contractual Clauses” means the clauses adopted by Commission Implementing Decision (EU) 2021/914.
• “Sub-processor” means a third party we engage that processes Customer Personal Data.

2. Roles and Scope

2.1. Controller and Processor

You are the Controller of Customer Personal Data and we are your Processor. You decide whether the Banner Script runs on a website, how it is configured, whether consent records are kept and for how long.

2.2. Agencies and Customers Acting for Others

If you use the Services on behalf of your own clients (for example as an agency managing their websites), you may act as a Processor yourself. In that case we act as your Sub-processor, you confirm that your client has authorised you to engage us on the terms of this DPA, and you pass on your client's instructions to us. We deal with you, not with your client, unless the law requires otherwise.

2.3. Details of the Processing

The subject matter, nature, purpose and duration of the processing, the types of Personal Data and the categories of Data Subjects are described in Annex I.

3. Your Instructions

3.1. Documented Instructions

We process Customer Personal Data only on your documented instructions. Your instructions are the Terms, this DPA, and the settings you choose in the Dashboard, such as banner and region rules, script and iFrame blocking, whether consent logging is enabled, the consent record retention period, whether optional features such as Advanced Analytics are turned on for a site, whether a site's privacy request form is turned on and the status you give each request, and the deletion of records or sites. When a member of your organisation connects an AI application through the AI Connector (Annex I, item 7), the connection they approve and the requests that application makes within it are also your instructions. When an owner or admin of your organisation creates an API key for the public API (Annex I, item 9), the permissions and sites they choose for it, and the requests made with it, are also your instructions. You may give further written instructions (email is enough) as long as they are consistent with the Terms and the functionality of the Services. Instructions that go beyond that functionality need our agreement.

3.2. Processing Required by Law

If European Union or Member State law requires us to process Customer Personal Data other than on your instructions, we will tell you about that legal requirement before processing, unless the law prohibits it on important grounds of public interest.

3.3. Unlawful Instructions

We will tell you promptly if, in our opinion, an instruction infringes Applicable Data Protection Law. We may suspend that instruction until you confirm or change it.

Some features send information from End Users' devices before they make a choice in the banner. Whether that needs End Users' consent depends on the law that applies to you, and the answer differs between countries. Before Advanced Analytics can be turned on for a site, the Dashboard tells you so and asks the owner or admin turning it on to confirm it. We keep a record of who confirmed it, when, and which version of the notice they saw.

3.4. No Other Use

We do not use Customer Personal Data for our own purposes. In particular we do not sell it, share it for advertising, use it to profile or track End Users or Requesters, or combine it with data from other customers or other sources. We may produce aggregated statistics (such as consent counts) that identify neither you nor any End User, as described in clause 6.6 of the Terms. The counts kept for Advanced Analytics (Annex I, item 6) are not used for those statistics: we use them only to show them to you, and we never combine them with other customers' counts or use them for any purpose of our own.

4. Your Obligations

You are responsible for:

• having a lawful basis for the processing you instruct, and giving End Users and Requesters the information required by Articles 13 and 14 GDPR, including in your own privacy or cookie notice;
• deciding whether to turn on features that store information on End Users' devices, read it from them, or send it from them before End Users make a choice, such as Advanced Analytics (Annex I, item 6), and, where the law that applies to you requires it, obtaining End Users' consent, telling them about it and offering them a way to object, under Article 5(3) of Directive 2002/58/EC as implemented in your country and any similar law;
• choosing any AI application your team members connect through the AI Connector, and checking that the terms of its provider, including any transfer of personal data outside the European Economic Area, are appropriate for the data it can request (Annex I, item 7). That provider is a recipient you choose, not our Sub-processor;
• keeping your API keys secret and choosing the systems that use them, and, where Customer Personal Data reaches a provider through those systems, including any transfer outside the European Economic Area, checking that its terms are appropriate for that data (Annex I, item 9). Those systems and their providers are recipients you choose, not our Sub-processors;
• the configuration of the Banner Script on your websites, including the consent categories, the scripts, cookies and services assigned to them, and the texts shown to End Users. Cookie categories suggested by our scanner are suggestions, and you decide whether to accept them;
• not configuring the Services to collect special categories of Personal Data (Article 9 GDPR) or data relating to criminal convictions;
• keeping your account secure, including managing team members and their roles and using two-factor authentication, which is available to every account;
• assessing whether the security measures in Annex II are appropriate for your processing.

5. Confidentiality

We ensure that every person we authorise to process Customer Personal Data is bound by a duty of confidentiality, by contract or by law. Access is limited to what is needed to provide, support and secure the Services and to comply with the law. The duty of confidentiality continues after the person's engagement with us ends.

6. Security

We implement the technical and organisational measures described in Annex II to protect Customer Personal Data, taking into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing, as required by Article 32 GDPR. We may change these measures as technology develops, provided that the overall level of protection is not reduced.

7. Sub-processors

7.1. General Authorisation

You give us a general authorisation to engage Sub-processors. The Sub-processors we use today are listed in Annex III. The full list of our service providers, including those that process only our own customer and billing data, is in section 6.1 of our Privacy Policy.

7.2. Sub-processor Contracts

We engage each Sub-processor under a written contract that imposes data protection obligations no less protective than those in this DPA, to the extent they apply to the service the Sub-processor provides. We remain responsible to you for the performance of each Sub-processor's obligations.

7.3. New Sub-processors

We will tell you by email, sent to the owner of your account, at least 30 days before a new or replacement Sub-processor begins processing Customer Personal Data, and we will update Annex III.

7.4. Objections

You may object to a new Sub-processor on reasonable data protection grounds by writing to us within 14 days of our notice. We will discuss your objection in good faith and, where possible, offer a way to use the Services without that Sub-processor processing your Customer Personal Data. If we cannot resolve the objection before the change takes effect, you may terminate the Agreement by written notice with effect before the new Sub-processor begins processing Customer Personal Data. Unpaid Fees for the remainder of the billing period do not become due on a termination under this clause.

7.5. Urgent Replacement

If we must replace a Sub-processor at short notice to protect the security or availability of the Services, we will tell you as soon as reasonably possible, and clause 7.4 applies from the date of that notice.

8. International Transfers

Customer Personal Data is stored in the European Union. Some Sub-processors process Customer Personal Data outside the European Economic Area in the course of their service, as shown in Annex III. We transfer Customer Personal Data outside the European Economic Area only where Chapter V of the GDPR is complied with, through an adequacy decision of the European Commission (including the EU-U.S. Data Privacy Framework for certified recipients) or through the Standard Contractual Clauses (Module Three, processor to processor) concluded with the Sub-processor, together with any supplementary measures that are needed.

If you are established in the United Kingdom or Switzerland, your transfer of Customer Personal Data to us in the European Union is covered by the adequacy regulations those countries have adopted for the European Union.

9. Data Subject Requests

9.1. Built-in Functions

The Services are designed so that you can answer most requests yourself. End Users can change or withdraw their consent at any time through the banner's preferences. In the Dashboard, you can find the consent records of one End User's browser by a consent ID the End User gives you, export them and delete them. You can also export a site's consent records, delete individual records or all records for a site, and shorten the retention period. If you turn on a site's privacy request form, End Users and other Requesters can send you requests through it, and you see, manage and export them in the Dashboard (Annex I, item 8).

9.2. Our Assistance

Where the Dashboard does not offer a function you need to answer a request under Chapter III GDPR, we will carry out the request on your written instruction within a reasonable time. We provide this assistance free of charge unless requests are manifestly unfounded or excessive.

9.3. Requests Sent to Us

If an End User or a Requester contacts us directly about Customer Personal Data, we will forward the request to you without undue delay and will not answer it ourselves, except to tell them to contact you, unless the law requires us to. The email we send a Requester to confirm their email address, when you have turned on a site's privacy request form, is part of that form and is sent on your instructions; it does not answer the request.

10. Personal Data Breaches

10.1. Notification

We will notify you of a Personal Data Breach without undue delay, and in any event within 72 hours after we become aware of it, by email to the owner of your account.

10.2. Content

Our notification will describe, as far as the information is available, the nature of the breach, the categories and approximate number of End Users or Requesters and records concerned, the likely consequences, and the measures taken or proposed to address the breach and reduce its effects. Where not all the information is available at once, we will provide it in stages without further undue delay.

10.3. Response

We will take reasonable steps to contain and investigate the breach, reduce its effects, and keep you informed. We will not notify a Supervisory Authority, End Users or Requesters about a breach of Customer Personal Data on your behalf unless you instruct us to or the law requires it. A notification under this clause is not an admission of fault or liability.

11. Impact Assessments and Consultation

Taking into account the nature of the processing and the information available to us, we will give you reasonable assistance with data protection impact assessments and prior consultations with a Supervisory Authority (Articles 35 and 36 GDPR) that relate to the Services, mainly by providing the information in this DPA and in our product documentation.

12. Audits and Information

12.1. Information

On request, we will make available the information necessary to demonstrate our compliance with this DPA and Article 28 GDPR, including a description of our security measures and written answers to a reasonable security questionnaire, once in any 12-month period (and additionally after a Personal Data Breach or at the request of a Supervisory Authority).

12.2. Certifications

We do not currently hold a third-party certification of our own, such as ISO/IEC 27001 or SOC 2. The data centres of our hosting provider are operated under an ISO/IEC 27001-certified information security management system.

12.3. Audits

If the information under clause 12.1 is not sufficient to demonstrate compliance, or a Supervisory Authority requires it, you may audit our compliance with this DPA, yourself or through an independent auditor who is bound by confidentiality and is not our competitor. Audits require at least 30 days' written notice, take place during Business Days, are limited to once in any 12-month period (except after a Personal Data Breach or at the request of a Supervisory Authority), and must not give access to other customers' data or put the security of the Services at risk. You bear your own costs of an audit.

12.4. Authority Requests

We will tell you without undue delay if a Supervisory Authority or other public authority contacts us about Customer Personal Data, unless the law prohibits it.

13. Deletion and Return

13.1. During the Agreement

You control the deletion of Customer Personal Data throughout the Agreement. Consent records are deleted automatically once they are older than the retention period set for the site (within the maximum of your Plan), by a job that runs every day. You can delete consent records in the Dashboard at any time. Privacy requests are deleted by a job that runs every day: a request whose Requester has not confirmed their email address once 24 hours have passed since it was sent, and a request you closed once 24 months have passed since you closed it. Deleting a site deletes its consent records, privacy requests, scan results and banner configuration immediately, and deleting your account does the same for every site in the organisations you own.

13.2. At the End of the Agreement

You can export your consent records from the Dashboard at any time before your account is closed and, under clause 8.4 of the Terms, you may request an export within 30 days after termination. After that period, we delete the remaining Customer Personal Data within a further 30 days, unless European Union or Member State law requires us to keep it. We will confirm the deletion in writing on request.

13.3. Backups and Technical Copies

Deleted Customer Personal Data leaves our backups within 30 days, as the backup cycle expires. Backups are used only for disaster recovery. Copies in server logs and processing queues are deleted automatically within the periods set out in Annex I.

14. United States Privacy Laws

To the extent the California Consumer Privacy Act or a similar United States state privacy law applies, we act as your “service provider” or “processor”. We will not sell or share Customer Personal Data, will not retain, use or disclose it outside our direct business relationship with you or for any purpose other than providing the Services, and will not combine it with personal information we receive from others except as those laws permit. We will tell you if we can no longer meet these obligations, and you may take reasonable steps to stop and remedy any unauthorised use.

15. Liability

Each party's liability under this DPA is subject to the limitations and exclusions in section 10 of the Terms. Nothing in this DPA limits either party's liability to Data Subjects under Article 82 GDPR, or any liability that cannot be limited by law.

16. Term, Precedence and Changes

16.1. Term

This DPA applies for as long as we process Customer Personal Data, including after the Agreement ends until the deletion under clause 13 is complete.

16.2. Precedence

For the processing of Customer Personal Data, this DPA prevails over the Terms and the Privacy Policy. Where Standard Contractual Clauses apply, they prevail over this DPA.

16.3. Changes

We may update this DPA to reflect changes in the law, in the Services or in our Sub-processors (for which clause 7 applies). We will tell you by email at least 30 days before a change that reduces the protection of Customer Personal Data takes effect, as described in section 15 of the Terms. The date at the top of this page shows when it was last updated.

16.4. Governing Law

This DPA is governed by the laws of Bulgaria, and the courts of Bulgaria have exclusive jurisdiction, as set out in section 17 of the Terms.

16.5. Severability

If any provision of this DPA is found invalid or unenforceable, the remaining provisions remain in full force.

16.6. Contact

Questions about this DPA, instructions, objections and audit requests can be sent to support@kukie.io.

Annex I: Description of the Processing

A. Parties

• Controller: the Customer, as identified in its Kukie.io account. Contact: the owner of the account.
• Processor: Pixadoro Ltd., Blvd. Cherni Vrah 47, 1407, Sofia, Bulgaria, company number 206777328. Contact: support@kukie.io.

B. Data Subjects

Visitors to the Customer's websites on which the Banner Script is installed (End Users). Where the Customer turns on a site's privacy request form, also the people who send a request through it (Requesters), who need not have visited the site.

C. Nature and Purpose

Showing a consent banner to End Users, holding back scripts and embedded content until the End User consents, storing the End User's choice, and keeping a record of consent so that the Customer can demonstrate it (Article 7(1) GDPR). Where the Customer turns on Advanced Analytics for a site, also counting how often the banner is shown and how it is answered, so that the Customer can see how the banner performs. Where a member of the Customer's organisation connects an AI application through the AI Connector, also making a consent record available to that application when it asks for it. Where the Customer uses the public API, also making a consent record and aggregate consent figures available to the Customer's systems when they ask for them with an API key. Where the Customer turns on a site's privacy request form, also receiving Requesters' requests, confirming their email address and showing the requests to the Customer, so that the Customer can answer them. The processing consists of collection, recording, storage, hashing, counting, retrieval, transmission and erasure. It is continuous for as long as the Banner Script runs on the Customer's websites, and for the privacy request form, for as long as the Customer keeps it on.

D. Processing Activities and Personal Data

1. Delivering the banner and detecting the region. Each time a page with the Banner Script loads, the End User's browser requests the script and region information from our servers through our content delivery network. The request contains the End User's IP address, browser user agent and the requested URL. The IP address is used to determine the End User's country (and, for the United States and Canada, the state or province) so that the right banner rules apply. The country is taken from the header added by our content delivery network or, failing that, looked up on our own servers in a locally stored geolocation database. No IP address is sent to a separate geolocation provider. Our application does not store the IP address. Technical server logs are kept for no longer than 90 days. On sites where the Customer turns on Advanced Analytics, each page load also sends the request described in item 6.

2. Recording consent (only while consent logging is enabled for the site, which is the default). Each consent record contains:

• a random consent identifier and a random visitor identifier, both generated in the End User's browser. The consent identifier is the one stored in the End User's consent cookie, so the End User holds the reference to their own record (where an older version of the Banner Script does not send it, our server generates the consent identifier instead);
• the action taken (for example accept all, reject all or a custom choice) and the consent categories accepted, plus the services accepted where the Customer asks for consent per service;
• the date and time, and the banner version shown;
• the End User's country code;
• the address of the page on which consent was given, without its query string or fragment;
• keyed cryptographic hashes (HMAC-SHA256) of the End User's IP address and browser user agent. The IP address and user agent themselves are not stored;
• where supplied, the resulting Google Consent Mode state.

Where the Customer turns on Advanced Analytics for a site, the request that records consent also says where the choice was made (for example the first layer of the banner or its preferences panel), which control was used, whether a stored choice existed before, the consent model and the banner language. These details are added to the daily counts described in item 6 and are not part of the consent record.

Consent records are kept for the retention period chosen for the site, which cannot exceed the maximum of the Customer's Plan (between 12 and 36 months), and are deleted within one month after that period ends. Short-lived technical copies exist while a record is being written: rate-limiting entries keyed on a hash of the IP address expire within 10 minutes, and a record that fails to be written is kept in the processing queue for up to 30 days for diagnosis.

3. Storing the choice on the End User's device. The Banner Script stores the End User's choice in the End User's own browser, where it is not accessible to us:

• the _cc_consent cookie holds the consent choices, the consent identifier of the matching consent record, the date, the banner version, the region and, where the End User allowed the sale or sharing of personal information while their browser sent Global Privacy Control, a mark saying so, for the period the Customer configures (1 to 730 days, 365 by default);
• local storage holds the random visitor identifier used in consent records, until the End User clears it;
• if the Customer enables consent cookies on its own subdomain, a kk_consent cookie holds the same choices for 365 days. To set it, our server receives the choices over that subdomain and returns them as a cookie without storing them;
• if the Customer enables the accessibility widget, the End User's display preferences are kept in local storage and are never sent to us;
• if the Customer has turned on Advanced Analytics and the End User objects to it through a control the Customer offers, local storage holds that objection (_cc_analytics_off) until the End User withdraws it or clears their browser storage. It is never sent to us.

4. Verifying a consent record. A consent record can be looked up by its consent identifier (the one in the End User's consent cookie) together with the site key. The response contains the choices, the date, the country code and the banner version, and does not contain the visitor identifier, the hashes or the page address.

5. Scanning, compliance checks and uptime monitoring. These features visit the Customer's public pages from our servers with a fresh automated browser. They do not process data about real End Users. The cookie scanner records the cookies and storage entries created during its own visit (including a sample of each value), and the scripts and embedded content it finds; scan results are kept for 30 days, and the 5 most recent scans of each site are always kept. Uptime checks record only the response status, response time and type of error.

6. Advanced Analytics (only on sites where the Customer turns it on, which is not the default). On each page load, the Banner Script sends one request to our servers that says only what the banner did on that page: shown (as a banner or as a cookie wall), a stored choice restored (allowing all, some or none of the optional categories), hidden by the consent model, or not shown on a page the Customer excluded. It also says the consent model, the banner language and, under the opt-out model used for regions such as US states, whether a Global Privacy Control or Do Not Track signal opted the End User out automatically. The request is sent without cookies and without a referrer, and it contains no page address and no identifier of the End User. Like every request, it reaches us with the End User's IP address and browser user agent. The IP address is used to determine the country and region, as in item 1, and the user agent is reduced to a device type and a browser family. Both are then discarded and are not stored, not even as hashes. Requests from known automated agents and from our own servers are not counted. This request, and the details a consent request carries under item 2, increase counters for the site and the day, each counter by a single attribute (for example the country, the device type or the button used) and never by a combination of attributes. No record of an individual request or choice is kept for this activity. On a very busy site we may count only a share of page loads and weight the counts to match, set by us and never by the End User's browser. The counters are held in a temporary store on our servers, normally for up to 15 minutes, and then added to daily totals, which are kept for the consent retention period of the site and deleted with its consent records. Short-lived rate-limiting entries keyed on a hash of the IP address expire within a minute. We use the totals only to show them to the Customer in the Dashboard and in its exports, and never for our own purposes (clause 3.4).

No request is sent, and no choice is counted, for an End User who has objected through a control the Customer offers (item 3), or whose browser sends a Global Privacy Control or Do Not Track signal. The one exception is the opt-out model, where those signals mean an objection to the sale or sharing of personal data, which this counting is not. There the page load and any choice are counted as for any other End User, except that a page load on which the banner applied the signal is counted as an automatic opt-out instead of a display. Our servers apply the same rule to the signals a request carries.

7. AI Connector (only where a member of the Customer's organisation connects an AI application, which is not the default, and only while the Customer's Plan includes it). The member chooses the application, the organisation, the sites and whether it may make changes, and Kukie.io checks the member's role and site access on every request. When the application asks for it, our servers return, for one consent record identified by its consent identifier, the action taken, the consent categories and services accepted, the date and time, the End User's country code and the banner version. They never return the visitor identifier, the hashes of the IP address and user agent, the page address or any other field of the record. Other information about End Users reaches the application only as totals (the consent figures shown in the Dashboard). We do not store the records an application asked for: our log of each request keeps only the tool used, the outcome, the duration and the size of the answer, for 90 days. The application's provider receives the data as a recipient the Customer chooses (clause 4), not as our Sub-processor.

8. Privacy request form (only on sites where the Customer turns it on, which is not the default). A Requester fills in a form on our servers for one of the Customer's websites. We store their name, email address, the type of request, the region they say they live in (and the country detected from their connection as in item 1, only when it lies in that region), any details and consent identifier they choose to give, the language of the form, the date and time, and the suggested deadline. Their IP address is used to protect the form from abuse and is not stored with the request: rate-limiting entries keyed on a hash of it, on a hash of the email address and on the site's public key expire within a day, and where the bot check is turned on the IP address is sent to Cloudflare to verify it (Annex III). Like every request, the form's requests appear in our technical server logs (item 1). When the form returns an error, what the Requester typed is kept in their browser session on our servers for up to 2 hours, so the form can show it again. We send the Requester one email with a link that confirms their address; only a hash of the link's secret is stored with the request, and the email names the website and the type of request, nothing the Requester typed. If the Requester replies to that email, the reply reaches our support mailbox, and we forward it to the Customer under clause 9.3. A request that is not confirmed within 24 hours is deleted. A confirmed request is shown only to the owners and admins of the Customer's organisation, who can change its status and deadline, add notes, export it and reply from their own email; we never answer a request. Owners and admins receive an email when a request is confirmed and 3 days before its deadline, without the Requester's name, email address or message. A request is deleted by a daily job once 24 months have passed since the Customer closed it, and at once with the site. While it is sent, the confirmation email, with the Requester's address and the link, sits in a processing queue, and one that fails to send is kept there for up to 30 days.

9. Public API (only while the Customer's Plan includes the public API, and only for an API key that an owner or admin of the Customer's organisation created with permission to read consent records). When the Customer's system asks for it, our servers return, for one consent record identified by its consent identifier and site, the consent identifier, the action taken, the consent categories and services accepted, the date and time, the End User's country code and the banner version. They never return the visitor identifier, the hashes of the IP address and user agent, the page address or any other field of the record. Other information about End Users reaches the Customer's system only as totals for a period it names (the consent figures shown in the Dashboard). We do not store the records returned: our record of each API request keeps the key, the endpoint's name, the time, the status, the duration, the request ID and a shortened IP address of the calling system, never the consent identifier, and our access log for the API removes the consent identifier from the address it records. Technical server logs that can contain the address are deleted within the period in item 1. The Customer's systems, and any provider that runs them, receive the data as recipients the Customer chooses (clause 4), not as our Sub-processors.

E. Special Categories

None by design. The Services are not designed to process special categories of Personal Data. A Requester's details in the privacy request form (Annex I, item 8) are free text and may contain anything the Requester chooses to write; the Customer decides how to handle it.

F. Duration

For the term of the Agreement and until deletion under clause 13.

G. Supervisory Authority

For Kukie: the Commission for Personal Data Protection of Bulgaria. For the Customer: the Supervisory Authority competent for the Customer.

Annex II: Technical and Organisational Measures

1. Confidentiality

• Hosting and physical security. All servers run in data centres of Hetzner Online GmbH in the European Union, operated under an ISO/IEC 27001-certified information security management system. We keep no servers or Customer Personal Data in our offices.
• Server access. Administrative access to the production servers is limited to authorised personnel and uses SSH key authentication. The database is protected by credentials and accepts connections from the application.
• Account security. Passwords are stored as bcrypt hashes and are checked against known breached passwords when set. Two-factor authentication (TOTP) is available to every account. Sign-in, two-factor and password reset attempts are rate-limited. Session cookies are Secure, HttpOnly and SameSite, and sessions expire after 120 minutes of inactivity.
• Roles and tenant separation. Every customer's data is logically separated by organisation and checked on each request. Access within an organisation follows the owner, admin and editor roles and per-site access, and exporting or deleting consent records, and seeing privacy requests, require the owner or admin role. The separation is covered by automated tests.
• Our staff's access. Our staff access a customer account only to provide support, investigate a security issue or meet a legal obligation. The start of every support session in a customer account is recorded in an audit log. The administration area is not visible to customer accounts.
• Secrets. Credentials for third-party services, two-factor secrets and mail server passwords are stored encrypted (AES-256). API keys are stored only as hashes.

2. Pseudonymisation and Data Minimisation

• IP addresses and browser user agents are never stored in consent records, only keyed HMAC-SHA256 hashes of them. The key is held outside the database.
• Page addresses are stored without query strings or fragments. Location is stored only as a country code.
• The Banner Script does not send the End User's other cookies, storage or page content to us.
• The Customer can switch consent logging off per site and shorten the retention period.
• Advanced Analytics is off unless the Customer turns it on for a site. It keeps only daily counts per site, each by a single attribute, and no End User identifier, IP address, user agent (not even as a hash), page address or referrer. Its request on each page load is sent without cookies or a referrer, and nothing is sent or counted for an End User who objects or whose browser sends a Global Privacy Control or Do Not Track signal, except under the opt-out model.
• Error reports are stripped of cookies, request bodies, headers and user details before they are sent to our error monitoring service.

3. Integrity

• Encryption in transit. All traffic to the Services uses HTTPS, with HTTP Strict Transport Security. Consent subdomains set up by customers require TLS 1.2 or higher. Backups are transferred over an encrypted SSH connection.
• Input handling. All input is validated on the server. Public endpoints are rate-limited per site, per visitor and per IP address. Server-side requests to customer-supplied addresses are restricted to public destinations. HTML and CSS supplied by customers are sanitised, and the Dashboard enforces a Content Security Policy and CSRF protection.
• Consent records. Consent records are written only by the server and cannot be edited in the Dashboard, only exported or deleted.
• Audit log. Sign-ins, failed sign-ins, password resets, account registrations, administrative actions, deletions of consent records, exports of one End User's records, changes to a site's privacy request form and exports of its privacy requests are recorded in an audit log.

4. Availability and Resilience

• Traffic passes through Cloudflare's network, which provides DDoS protection and caches each site's Banner Script at the edge.
• Consent records are written through a queue that retries failed writes automatically. Queue workers are supervised and restarted automatically, and a scheduled job empties the queue if a worker stops.
• Errors are reported to an error monitoring service. System health, the task scheduler and the age of the latest backup are checked automatically, and failures raise an alert.

5. Recoverability

• A full database backup is taken every six hours and stored with a separate backup provider in the European Union for 30 days. A failed backup raises an alert.
• Each deployment is installed as a separate release, so a faulty release can be rolled back.

6. Regular Testing and Review

• An automated test suite, including tests for tenant separation, access control, rate limits and security headers, must pass before each deployment and runs again on every push to our code repository.
• We regularly review the code for security issues and record each finding in a defect register until it is fixed.
• Dependencies are updated regularly and checked against published security advisories when they are updated.
• Sub-processors are selected with a review of their data protection terms and are engaged under contracts that meet Article 28 GDPR.
• We review this Annex at least once a year and whenever the processing changes materially.

7. AI Connector

• The AI Connector is off unless the Customer's Plan includes it and a team member connects an application. Owners and admins can set the organisation's AI access to off, read only, or read and change.
• Applications sign in through OAuth 2.1 with PKCE, after the team member approves the connection on our own consent screen, or with an AI key that expires and is stored only as a hash. Each connection is limited to one organisation, to the sites the team member chooses and to the access they choose.
• The team member's role and site access are checked on every request, so a removed member or a lowered role takes effect at once. Changing the password or turning off two-factor authentication ends the team member's connections.
• Text taken from scanned websites is cleaned and marked as coming from a third party before it is returned. Every change needs a preview of exactly that change first, and the tools that change settings are marked as modifying data so that applications ask the team member before using them, unless the application is set to approve tools on its own. An automation using an AI key asks no one. Every change is recorded with its previous values and, except starting a scan, can be undone in the Dashboard. Read-only access prevents changes altogether.
• Each request is rate-limited and logged without its content, and connecting, creating a key and disconnecting are recorded in the audit log. The team member and the organisation's owners and admins can end a connection at any time.

8. Public API

• The public API is off unless the Customer's Plan includes it, and we can switch it off for every customer at once.
• Only the owners and admins of an organisation can create API keys. A key is shown once and stored only as a hash and its last four characters, expires after at most 365 days, and is accepted only in a request's Authorization header; a request that carries a key in its query string is refused.
• Each key is limited to its organisation, to the permissions chosen for it and to all of the organisation's sites or the ones chosen for it, and this is checked on every request. A revoked or expired key stops working at once.
• Requests are rate-limited per key and per organisation and recorded without their content (Annex I, item 9). Creating, replacing and revoking a key are recorded in the audit log.

Annex III: Sub-processors

These Sub-processors process Customer Personal Data. Providers that process only our own customer and billing data (such as payment and newsletter providers) are listed in section 6.1 of our Privacy Policy.