Data Processing Agreement

This Data Processing Agreement (“DPA”) forms part of the Terms of Service (the “Agreement”) between Muhammed Miraç Berk (“invisit”, “Processor”) and the customer that accepted the Agreement (“Customer”, “Controller”). It applies whenever invisit processes Customer Personal Data in providing the Service, and takes effect when the Customer accepts the Agreement. No signature is needed. Customers who want a countersigned copy can request one at legal@invisit.dev.

If this DPA and the Agreement conflict, this DPA prevails on the processing of personal data. If the Standard Contractual Clauses apply and conflict with this DPA, the Clauses prevail.

1. Definitions

• Data Protection Law means all laws on the protection of personal data that apply to the processing under the Agreement, including the EU General Data Protection Regulation 2016/679 (“GDPR”), the GDPR as it forms part of UK law with the UK Data Protection Act 2018 (“UK GDPR”), the Swiss Federal Act on Data Protection (“FADP”), the California Consumer Privacy Act as amended (“CCPA”), and the Turkish Personal Data Protection Law No. 6698 (“KVKK”), in each case where applicable.
• Customer Personal Data means personal data in the Customer Data (as defined in the Agreement) that invisit processes on the Customer’s behalf.
• Subprocessor means a third party that invisit engages to process Customer Personal Data.
• Security Incident 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 or SCCs means the clauses annexed to Commission Implementing Decision (EU) 2021/914 of 4 June 2021.
• “Controller”, “processor”, “data subject”, “personal data”, “processing” and “supervisory authority” have the meanings given in the GDPR; “business”, “service provider”, “sell” and “share” have the meanings given in the CCPA.

2. Roles and scope

2.1 For Customer Personal Data, the Customer is the controller (or a processor acting for its own controller) and invisit is a processor (or subprocessor). The details of the processing are in Annex I.

2.2 For personal data about the Customer’s own account users, billing and use of the Service, invisit is an independent controller and the Privacy Policy applies, not this DPA.

3. Customer’s obligations

3.1 The Customer is responsible for the lawfulness of the processing it instructs, including having a valid legal basis, giving data subjects the required information, and obtaining consent where Data Protection Law or ePrivacy law requires it.

3.2 The Customer will not send invisit special categories of personal data, data about criminal convictions, government identifiers, payment card data, credentials, or personal data of children under 16, and will configure custom events, properties, identify calls and feedback forms accordingly.

3.3 The Customer’s instructions must comply with Data Protection Law.

4. invisit’s obligations

4.1 Instructions. invisit processes Customer Personal Data only on the Customer’s documented instructions, including for transfers to third countries, unless Union or Member State law to which invisit is subject requires otherwise, in which case invisit informs the Customer before processing unless that law prohibits it. The Agreement, this DPA and the Customer’s use and configuration of the Service are the Customer’s complete instructions. invisit will tell the Customer at once if, in its opinion, an instruction infringes Data Protection Law.

4.2 Confidentiality. invisit ensures that everyone it authorises to process Customer Personal Data is bound by confidentiality.

4.3 Security. invisit implements and maintains the technical and organisational measures in Annex II. invisit may update them as long as the overall level of protection does not decrease.

4.4 Assistance. Taking into account the nature of the processing, invisit assists the Customer with appropriate measures in responding to data subject requests, and with the Customer’s obligations under Articles 32 to 36 GDPR (security, breach notification, data protection impact assessments and prior consultation), using the information available to it.

4.5 Data subject requests. If invisit receives a request from a data subject about Customer Personal Data, it will refer the data subject to the Customer and will not respond itself, except to confirm the referral. The Service lets the Customer export and delete data by site.

4.6 No other use. invisit will not sell or share Customer Personal Data, retain, use or disclose it for any purpose other than providing the Service, or outside the direct business relationship with the Customer, or combine it with personal data it receives from or on behalf of anyone else, except as Data Protection Law permits a service provider or processor to do. invisit will not attempt to re-identify data subjects from pseudonymous data. invisit certifies that it understands and will comply with these restrictions.

4.7 Aggregated statistics. invisit may derive aggregated statistics about the operation of the Service that do not identify the Customer, its sites or any data subject, as described in the Agreement.

5. Security Incidents

5.1 invisit notifies the Customer without undue delay, and in any event within 48 hours, after becoming aware of a Security Incident affecting Customer Personal Data.

5.2 The notice describes, as far as then known, the nature of the incident, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. invisit provides further information as it becomes available.

5.3 invisit takes reasonable steps to contain and remedy the incident. Notifying a Security Incident is not an admission of fault.

6. Subprocessors

6.1 The Customer gives invisit general authorisation to engage Subprocessors. The current list is at invisit.dev/legal/subprocessors.

6.2 invisit imposes on each Subprocessor, by written contract, data protection obligations that offer at least the same level of protection as this DPA, and remains liable to the Customer for each Subprocessor’s performance.

6.3 invisit gives at least 30 days’ notice before a new Subprocessor begins processing Customer Personal Data, by updating the list and by email to Customers who have subscribed to updates.

6.4 The Customer may object to a new Subprocessor on reasonable data protection grounds within that period by writing to privacy@invisit.dev. The parties will discuss the objection in good faith. If invisit cannot reasonably avoid using the Subprocessor for the Customer, the Customer may terminate the affected part of the Service and receive a refund of prepaid fees for the period after termination.

6.5 In an emergency (for example to keep the Service secure or available), invisit may replace a Subprocessor at once and will notify the Customer as soon as possible afterwards, with the same right to object.

7. International transfers

7.1 invisit hosts Customer Personal Data in the European Union. Transfers may occur to invisit itself, based in Türkiye, and to Subprocessors located outside the EEA, as listed on the subprocessors page.

7.2 EEA. Where Customer Personal Data is transferred from the EEA to a country that is not subject to an adequacy decision, the SCCs are incorporated into this DPA by reference and apply as follows:

• Module Two (controller to processor) applies where the Customer is a controller, and Module Three (processor to processor) where the Customer is a processor;
• in Clause 7, the docking clause applies;
• in Clause 9, option 2 (general written authorisation) applies, with the notice period in section 6.3;
• in Clause 11, the optional language does not apply;
• in Clause 13, the competent supervisory authority is the one determined under Clause 13(a);
• in Clauses 17 and 18, the governing law and courts are those of Ireland;
• Annexes I, II and III of the SCCs are completed by Annexes I and II of this DPA and the subprocessors page.

7.3 United Kingdom. For transfers from the UK, the International Data Transfer Addendum to the EU SCCs issued by the UK Information Commissioner (version B1.0) applies, completed with the information in this DPA; either party may end it as set out in its Section 19.

7.4 Switzerland. For transfers from Switzerland, the SCCs apply with these changes: the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority; references to the GDPR include the FADP; and “Member State” includes Switzerland, so that data subjects there can enforce their rights in their place of habitual residence.

7.5 Where invisit’s Subprocessors receive transfers, invisit ensures a valid transfer mechanism is in place, such as the SCCs or certification under the EU-US Data Privacy Framework.

7.6 Government access. If invisit receives a request from a public authority for Customer Personal Data, it will, unless legally prohibited, notify the Customer, try to redirect the authority to the Customer, and challenge the request if it believes it to be unlawful. invisit discloses only the minimum the request lawfully requires.

8. Audits

8.1 invisit makes available to the Customer the information reasonably necessary to demonstrate compliance with this DPA, including written answers to reasonable security questionnaires, no more than once a year unless a Security Incident or a supervisory authority requires more.

8.2 Where that information is not sufficient, the Customer may conduct an audit, itself or through an independent auditor bound by confidentiality, with at least 30 days’ notice, during business hours, without unreasonably disrupting the Service, and at its own cost. Audits of Subprocessors are satisfied by their own certifications and reports.

9. Deletion and return

9.1 During the term, the Customer can export and delete Customer Personal Data through the Service.

9.2 When the Agreement ends, or when the Customer deletes a site, workspace or account, invisit deletes the relevant Customer Personal Data from its live systems, and from backups as they are rotated within 30 days, unless Union or Member State law requires its storage.

10. Liability

Each party’s liability under this DPA is subject to the limitations of the Agreement, except where Data Protection Law or the SCCs do not allow a limitation.

11. Term

This DPA lasts as long as invisit processes Customer Personal Data under the Agreement.

Annex I: Description of the processing

A. Parties

The parties’ acceptance of the Agreement is their signature of this Annex.

B. Categories of data subjects

• Visitors of the Customer’s websites and apps where the invisit tracker or SDKs are installed.
• People who follow the Customer’s short links.
• People who submit the Customer’s feedback forms.
• The Customer’s own customers, where the Customer connects a payment provider for revenue analytics or identifies its users with identify.

C. Categories of personal data

• Usage data: pages and screens viewed, referrer, UTM and campaign parameters, events and their properties as configured by the Customer, clicks and scroll depth for heatmaps, engagement time, web performance measurements.
• Device and location data: browser, operating system, device type, screen size, language, and country, region and city derived from the IP address.
• Network data: IP address, processed transiently to derive the pseudonymous visitor identifier and location and for rate-limiting and abuse prevention; not stored with the analytics. User agents of identified crawlers and bots are stored.
• Pseudonymous identifiers: a daily visitor identifier (a keyed hash of site, date, coarse device class and IP address, mixed with a random daily salt that is deleted about a day after that day ends), session identifiers, and a keyed hash of any user id the Customer passes to identify.
• Feedback data: messages visitors submit and, if they choose to give it, their email address.
• Revenue data: from payment providers the Customer connects: transaction amounts, currency, products, subscription and customer identifiers, and timestamps.

D. Special categories of data

None. The Customer must not send any (section 3.2).

E. Frequency of the transfer

Continuous, for as long as the Customer uses the Service.

F. Nature and purpose of the processing

Collecting, storing, aggregating, analysing and displaying web analytics, short-link click analytics, visitor feedback and revenue attribution for the Customer; serving short-link redirects; sending alerts and exports the Customer configures; and the security, support and operation of the Service.

G. Retention

Customer Personal Data is kept until the Customer deletes it or the site, workspace or account that holds it, or the Agreement ends, and is then deleted as set out in section 9. Free-plan sites that receive no events for about six months may be deleted after notice to the Customer, as described in the Agreement.

H. Transfers to Subprocessors

As listed at invisit.dev/legal/subprocessors, for the subject matter, nature and duration described there and in this Annex.

I. Competent supervisory authority

As determined under Clause 13 of the SCCs.

Annex II: Technical and organisational measures

Pseudonymisation and minimisation

• No cookies or persistent device identifiers are set by the tracker. Visitors are counted with a keyed HMAC-SHA256 identifier that includes the UTC date and the site, so it changes daily and differs between sites.
• IP addresses are not stored with analytics data. User ids passed to identify are stored only as keyed hashes.
• The tracker can honour Global Privacy Control and Do Not Track if the Customer turns either on, and supports a consent-required mode.
• Path exclusions let the Customer stop collection on pages they choose.

Encryption

• All traffic to and from the Service is encrypted in transit with TLS.
• Credentials for connected payment providers and alert channels are encrypted at rest with versioned keys.
• Passwords are stored only as salted, slow hashes.

Access control

• Production access is limited to invisit personnel who need it, over authenticated, encrypted channels.
• Each service holds only the secrets it needs; a service refuses to start if it is given secrets outside its boundary.
• The analytics database uses separate least-privilege accounts for ingestion, reads and maintenance.
• Inside the Service, access to each workspace is role-based (owner, member, viewer), and API keys and MCP tokens are scoped.

Logging and accountability

• Security-relevant actions by users, API keys, AI assistants and administrators, including administrative access to customer workspaces, are recorded in an audit trail kept for 2 years.
• Application logs are kept for 60 days.

Availability and resilience

• Analytics ingestion goes through a durable queue, so events survive a datastore outage.
• Data is backed up regularly, and backups are protected with the same access controls as production. Backups are taken every few hours, encrypted before they leave the server, and stored in a separate EU location.
• Rate limiting and bot protection guard against abuse and denial-of-service.

Secure development

• Code changes must pass automated tests, type checks and linting before they are deployed.
• Dependencies are pinned through a lockfile and updated deliberately.
• Short-link destinations are checked against threat-intelligence feeds.

Incident response

• invisit monitors the Service for errors and anomalies, investigates suspected incidents, and notifies Customers as set out in section 5.

Subprocessors

• Subprocessors are bound by written data protection terms, and their security is reviewed before they are engaged.