DRAFT — for lawyer review before publishing

This is a draft, not legal advice. Every [TO VERIFY: …] placeholder must be checked, filled in or removed before publishing.

Published at: /dpa. [TO VERIFY: how and when the DPA is accepted; payments are not live yet.]

Data processing agreement

Version: [VERSION] · Last updated: [DATE]

Parties

The Customer, the company that holds a nicelookingdata account and has accepted this agreement. The Customer is the controller.
Ludvig Nyström, sole trader (enskild firma), [ADDRESS], [CONTACT EMAIL: suggested privacy@nicelookingdata.com] (the "Processor" or "we"). The Processor is the processor.

1. Background and roles

The Customer uses nicelookingdata to review its accounts in Google Analytics 4 and Google Tag Manager. To do this, the Processor reads data in those accounts under the Customer's own login. The Processor will update this agreement before adding other sources, such as Search Console, Google Ads or Meta.

For the data read in the Customer's accounts, the Customer is the controller and the Processor is the processor. This agreement meets the requirements of Article 28 of the General Data Protection Regulation (GDPR).

This agreement does not cover data about the person who signs in, payment, or our own product analytics. For those, the Processor is itself the controller under the privacy policy at /privacy. Once payments open, Paddle will be an independent controller for payment.

Terms in this agreement have the meaning given to them in the GDPR.

2. Subject matter, duration, nature and purpose

Subject matter. Reading and analysing data in the accounts the Customer connects, and producing findings, scores, reports, questions for the Customer's agency and, if the Customer turns on monitoring, a weekly email.

Duration. For as long as the Customer has a nicelookingdata account, and then for the time needed for deletion under section 10.

Nature of processing. Retrieval via APIs with read-only access, storage, compilation, analysis and deletion. The Processor never changes anything in the Customer's accounts.

Purpose. Solely to deliver the service to the Customer. The data is not used for advertising, is not sold, and is not used to train general-purpose AI models.

3. Categories of personal data and data subjects

The Processor mainly reads settings and aggregated figures. Aggregated figures are usually not personal data. Some parts do contain personal data, or can, depending on how the Customer has set up its accounts and website. The table describes this as precisely as possible.

Source	What the Processor reads	May contain personal data
GA4 (`analytics.readonly`)	Settings, data streams, event names, conversions, custom definitions, reports, mostly aggregated	If the Customer's website sends personal data to GA4, such as email in URLs or IDs in custom dimensions, it can appear as values in reports.
GA4 users (`analytics.manage.users.readonly`)	The list of people with access to a GA4 property, with their roles	Yes. Email addresses of the people with access. Used for access-governance findings, such as a personal Gmail address with admin rights.
GTM (`tagmanager.readonly`)	The published container version (tags, triggers, variables and custom code), and the account's user permissions	Yes. The user permissions contain email addresses. Containers often hold tracking and advertising IDs. They can also hold hard-coded email addresses, phone numbers, customer IDs, API keys and names in notes.

What is stored. For each audit, the Processor stores the owner's email address, the GA4 property ID and name, the GTM container ID and name, and the findings. Findings can include email addresses of GA4 and GTM users. Only the owner can open an audit.

Categories of data subjects.

Visitors and users of the Customer's websites and apps, indirectly and mainly in aggregate.
The Customer's employees, consultants and agencies with access to the accounts, through the user lists and to the extent their names or email addresses appear in account metadata.
People whose data the Customer has placed in its GTM container.

Special categories of personal data. The Processor does not intentionally process special categories of personal data under Article 9. If such data exists in the Customer's accounts, for example in URLs on a healthcare provider's website, the Customer is responsible for its lawfulness. The Processor shows such cases as findings when they are detected.

4. The Customer's instructions

The Processor processes personal data only on the Customer's documented instructions. This agreement, the terms of service and the settings the Customer makes in the service are the complete instructions.

If the Processor considers that an instruction infringes the GDPR, the Processor informs the Customer without delay.

If the law requires the Processor to process data otherwise, the Processor informs the Customer beforehand, unless the law prohibits this.

5. The Processor's obligations

The Processor shall:

only allow people bound by confidentiality to process the data. Today only Ludvig Nyström has access. [TO VERIFY: whether consultants or employees will be given access.]
take the security measures set out in Annex 2 and in Article 32.
follow the rules on sub-processors in section 6.
help the Customer respond when data subjects exercise their rights. If a request reaches the Processor directly, the Processor forwards it to the Customer without delay.
help the Customer with data protection impact assessments and prior consultations, to the extent they concern the service.
keep a record of processing under Article 30(2).
give the Customer the information needed to show compliance with this agreement.

6. Sub-processors

The Customer gives general authorisation for the Processor to engage sub-processors. The current list is at /subprocessors and in Annex 1.

Before engaging a new sub-processor or replacing an existing one, the Processor notifies the Customer by email at least 30 days in advance. The list is updated at the same time. [TO VERIFY: 30 days as the notice period.]

The Customer may object within the notice period. If the parties cannot find a solution, the Customer may terminate the service at no cost, effective from the change. Prepaid fees for time after termination are refunded. [TO VERIFY: how refunds are made through Paddle.]

The Processor shall impose the same obligations as in this agreement on each sub-processor by written contract. The Processor remains liable to the Customer for the sub-processor's processing.

7. Security

The Processor takes technical and organisational measures that give a level of security appropriate to the risk. The measures are set out in Annex 2. The Processor may improve the measures but not lower the overall level of protection.

8. Personal data breaches

The Processor notifies the Customer without undue delay after becoming aware of a personal data breach affecting the Customer's data. [TO VERIFY: fixed deadline, suggested no later than 48 hours.]

The notice shall, as far as possible, contain:

what happened and when,
the categories and approximate number of data subjects and records concerned,
likely consequences,
what the Processor has done and proposes to limit the harm,
contact details.

Information not available at once may be provided in stages. The Processor helps the Customer report the breach to the Swedish Authority for Privacy Protection (IMY) and, where needed, inform the data subjects.

9. Transfers to third countries

The Processor stores and processes the data within the EU/EEA. The database is in Google Cloud region europe-west1 (Belgium). Servers run in Vercel region arn1 (Stockholm).

Some sub-processors are US companies, such as Vercel Inc. Data may therefore in some cases be accessed from the United States, for example for support or operations. Such transfers take place only on a basis under Chapter V of the GDPR:

the sub-processor's certification under the EU–US Data Privacy Framework, or
the European Commission's standard contractual clauses (2021/914), Module 3, with any supplementary measures needed.

The basis for each sub-processor is set out in Annex 1.

10. Deletion and return

When the Customer removes the Processor's access at Google, the Processor can no longer read the Customer's accounts, and weekly monitoring stops.

When this agreement ends, or when the Customer deletes its account, the Processor deletes all personal data processed for the Customer within 30 days. Before deletion, the Customer can save its reports as PDF. [TO VERIFY: whether export in another format, such as JSON, should be offered.]

Backups are overwritten after [TO VERIFY: retention]. Until then they are protected under Annex 2 and used only to restore the system.

Data may be kept longer only where the law requires it.

11. Audits

The Customer may verify that the Processor complies with this agreement. In the first instance this is done by the Processor providing written information and answering questions.

If that is not enough, the Customer, or an independent auditor bound by confidentiality, may carry out an audit. It shall be announced at least 30 days in advance, take place at most once a year unless a breach justifies more, and disrupt operations as little as possible. The Customer bears its own costs. [TO VERIFY: audit terms.]

12. Liability

The limitation of liability in the terms of service at /terms also applies to this agreement. The limitation does not affect data subjects' right to compensation under Article 82, or administrative fines imposed by an authority.

13. Term and changes

This agreement applies from the Customer's acceptance and for as long as the Processor processes personal data for the Customer.

The Processor may change this agreement where the law, a regulator's decision or the service requires it. Changes are notified by email at least 30 days before they take effect. If this agreement and the terms of service say different things about personal data, this agreement prevails.

14. Governing law and disputes

Swedish law applies. Disputes are settled by the Swedish general courts. [TO VERIFY: venue, same as in the terms of service.]

Annex 1. Sub-processors

See web/content/legal/subprocessors.md, published at /subprocessors. The list forms part of this agreement.

Annex 2. Security measures

Access and permissions

The Customer's accounts are read only under the Customer's own OAuth login. No service accounts, no shared logins, no intermediary API services.
Only read-only scopes are requested.
Only Ludvig Nyström has access to the production environment. [TO VERIFY: two-factor authentication on every admin account at Google Cloud, Vercel and Resend, and at Paddle once payments open.]

Encryption

Google refresh tokens are stored encrypted with AES-256-GCM. The key is kept as a secret environment variable, separate from the database.
All traffic is encrypted with TLS.
Google Cloud encrypts data at rest.

Database and operations

The database can only be reached from the server. Database rules deny all access from browsers.
Storage in Google Cloud europe-west1, servers in Vercel arn1.
Backups: a nightly export of the whole database to Google Cloud Storage. [TO VERIFY: bucket region and retention.]

Minimisation

Most data read is aggregated.
Results of domain scans are deleted 30 days after the scan.
IP addresses are never stored. Scan rate limits use a shortened hash of the IP address, deleted after 2 days.

Safeguards in code

SSRF protection when websites are fetched: addresses that are not public are refused.
Rate limits per IP address.
Secrets are kept as environment variables, not in code.

Incidents and continuity

Server error logs at Vercel.
A procedure for handling and reporting breaches. [TO VERIFY: that the procedure exists in writing.]