Data processing agreement

1. Parties and how this agreement is made

1.1 This agreement is between the agency (“you”, the controller) and Autodash AS, organisation number 937 911 203, Kalfarveien 78C, 5022 Bergen (“we”, the processor).

1.2 It is part of the terms of service for agencies and is accepted with them, electronically, when the agency’s account is created. We keep which version was accepted, and when. GDPR Article 28(9) allows a written agreement “including in electronic form”.

1.3 If this agreement and the terms disagree about the personal data in Annex 1, this agreement wins.

2. What we process for you

2.1 Annex 1 describes the subject matter, duration, nature and purpose of the processing, the types of personal data and the categories of data subjects.

2.2 The processing starts when your agency creates its first link and lasts until the data is deleted under clause 10.

3. Your instructions

3.1 We process the personal data in Annex 1 only on your documented instructions. Your instructions are:

• this agreement and the terms of service;
• what you do in Adcato: the links you create, what you ask for, archiving and moving back, revoking a link, the export, deleting the agency, your settings;
• what an owner of your agency asks us in writing at support@adcato.com, where we agree it is possible.

3.2 If the law of the EEA or of Norway requires us to process the data in another way, we tell you before we do, unless that law forbids telling you.

3.3 You accept that we also use the data in Annex 1 for purposes of our own: counting active clients for billing (the count holds no personal data); security and preventing misuse (our staff see a link and your agency’s name beside a report from a client, and can turn the link off for good); and legal duties, such as an order from an authority. For those uses we are the controller.

3.4 If we think an instruction breaks GDPR or other data protection law, we tell you at once.

3.5 You are responsible for having a lawful basis for the processing, and for telling your clients and their people what they need to know about it. [LAWYER: WHO INFORMS THE CLIENT'S PEOPLE: THE AGENCY, OR OUR PRIVACY NOTICE FOR CLIENTS ON ITS BEHALF]

4. Confidentiality and who has access

4.1 Everyone we let process the personal data has committed to keep it confidential in writing, or is bound by a duty of confidentiality in law. The commitment lasts after the work for you has ended. [OWNER: LIST WHO HAS ACCESS TO PRODUCTION DATA (THE SERVER, THE DATABASE, THE STAFF PAGES); A WRITTEN UNDERTAKING MUST EXIST FOR EACH PERSON BEFORE THEY GET ACCESS]

4.2 Only people who need it for their work get access, and we take it away when they no longer need it.

4.3 Our staff pages open only to a signed-in account with a confirmed staff address, on our main domain.

4.4 We look at the data we keep for you only when you ask us to (for support), to investigate a security problem or misuse, or when the law requires it. Data that came from a client’s Google sign-in (the names and IDs of the Google accounts, properties and containers the client chose) we look at only to investigate a fault or misuse, or when the law requires it, unless the client has agreed. [LAWYER: WHETHER THE AGENCY'S SUPPORT REQUEST IS ENOUGH FOR GOOGLE DATA]

5. Security

5.1 We take the technical and organisational measures that GDPR Article 32 requires, given the risk. Annex 2 lists the measures in place today, and the ones that are not.

5.2 We may change the measures, but not to a lower level of protection.

5.3 We tell you about the measures on request, and keep our security page (/security) up to date with what is and is not in place.

6. Personal data breaches

6.1 We tell the owners of your agency by email without undue delay after we become aware of a personal data breach affecting the data in Annex 1, and aim to do so within [48] hours. [LAWYER/OWNER: THE HOUR TARGET]

6.2 We give you what you need to notify Datatilsynet and, where needed, the people concerned: what happened, the kinds and rough numbers of people and records concerned, the likely consequences, what we have done and will do, and a contact. If we do not know everything at once, we give it in steps without further undue delay.

6.3 We document every breach, its effects and what we did.

6.4 Where the breach involves data from Meta, we must also report it to Meta under its Platform Terms; we tell you when we have.

6.5 You decide whether to notify Datatilsynet and the people concerned about data in Annex 1. We do not notify them on your behalf unless you ask us to.

7. Sub-processors

7.1 You give us a general written authorisation to use the sub-processors listed at /legal/subprocessors.

7.2 Before we add or replace a sub-processor that will process the data in Annex 1, we tell the owners of your agency by email, and update the list, at least [30] days before the change takes effect.

7.3 You may object on reasonable grounds within those days. We then try to find a solution with you.

7.4 If we cannot, you may end the agreement before the change takes effect, and we refund what you paid for the part of the period after it. [OWNER: CONFIRM THE REFUND]

7.5 We put the same data protection obligations on each sub-processor, in a written contract, as this agreement puts on us, including sufficient guarantees for security.

7.6 We remain fully liable to you for a sub-processor’s performance of those obligations.

8. Helping you with the rights of the people concerned

8.1 Adcato lets you meet most requests yourself:

• access and portability: the owner’s export, one JSON file with every client’s record (section 13.3 of the terms);
• erasure: an owner or admin deletes one client’s record from its page (Delete client), and deleting the agency deletes every client record at once;
• restriction: archiving a client, and revoking its link.

8.2 For a request the product cannot handle, we help you within [10] working days, as far as the nature of the processing allows.

8.3 If a person asks us about data in Annex 1, we pass the request to the owners of your agency within [5] working days and do not answer it ourselves, except to say we have passed it on.

8.4 If Meta tells us about a person’s request concerning their Meta data, we tell you promptly.

9. Helping you with security, breaches and impact assessments

9.1 We help you meet GDPR Articles 32 to 36, as far as the nature of the processing and the information we have allow: with Annex 2 and the security page, with the breach information in clause 6, and with information you need for a data protection impact assessment or a consultation with Datatilsynet.

9.2 Help that the product and this agreement already give costs nothing extra. For other work we may charge [REASONABLE COSTS, AGREED IN ADVANCE]. [LAWYER]

10. When the processing ends: return or delete

10.1 Return. While your agency exists, the owner can download the record of every client at any time with the export (section 13.3 of the terms lists what it holds).

10.2 Delete. The owner can delete the agency at any time. That deletes the data in Annex 1 in one step, for everyone in the agency, and cannot be undone.

10.3 When the agreement ends and the agency has not been deleted, the owner can still export for [30] days. After that our staff close the agency, which deletes it in the same way.

10.4 Backups. [NO AUTOMATED BACKUP EXISTS YET. WHEN IT DOES: COPIES ARE OVERWRITTEN WITHIN N DAYS, AND ARE NOT RESTORED EXCEPT AFTER AN INCIDENT]

10.5 What we keep as controller. Our log of what was done stays, detached from the agency: a random reference replaces it, and it holds IDs, action names and counts, not names, addresses or tokens. Reports from clients stay for 180 days after staff handled them. Paid invoices stay for bookkeeping, without the agency and the card’s fingerprint, until the end of the fifth year after the year they were paid [TO BE CONFIRMED WITH THE ACCOUNTANT]. These are ours, as controller, not data we process for you.

10.6 On request we confirm in writing that the deletion is done.

10.7 Unless the law of the EEA or Norway requires us to keep it, nothing of Annex 1 is kept after 10.2 or 10.3. [LAWYER: NO SUCH LAW IS KNOWN FOR ANNEX 1 DATA]

11. Information and audits

11.1 We give you the information you need to show that this agreement is kept: this agreement, Annex 2, the security page, the list of sub-processors, and written answers to a reasonable questionnaire once a year.

11.2 You, or an auditor you appoint who is bound by confidentiality, may audit our compliance with this agreement, including by inspection. We take part and help.

11.3 To keep audits proportionate to a small company:

• tell us at least [30] days before, unless a breach or an authority makes it urgent;
• an audit is done remotely by documents and interviews first, and on site only if that is not enough;
• at most once in 12 months, unless there has been a breach, an authority asks, or you have concrete reason to think we break this agreement;
• you pay your own costs and the auditor’s; we may charge [OUR REASONABLE COSTS] for more than [ONE WORKING DAY] of our time;
• the auditor sees only what concerns your data, never another agency’s.

11.4 We keep a record of the processing we carry out for you, as GDPR Article 30(2) requires.

12. Where the data is, and transfers

12.1 We store and process the data in Annex 1 on servers in Finland, in the EU.

12.2 We do not transfer it outside the EEA, except through a sub-processor in the list of clause 7 that names the country and the legal basis: an adequacy decision (GDPR Article 45) or the European Commission’s standard contractual clauses (Article 46(2)(c)).

12.3 When the client or your agency signs in, the service calls Meta’s and Google’s systems, which process data worldwide under their own terms. These calls carry what is needed to read the client’s assets and to give you access (asset IDs, your business ID or receiving Google address). They are made at the direction of whoever signed in (the client, or your agency on Connections), to the platforms where the access lives; Meta and Google are not our sub-processors. [LAWYER: CONFIRM THAT THESE CALLS ARE NOT TRANSFERS BY US THAT NEED A CHAPTER V TOOL]

13. Liability

13.1 Liability between us follows section 16 of the terms of service. [LAWYER: WHETHER BREACHES OF THIS AGREEMENT HAVE THEIR OWN, HIGHER CAP]

13.2 Nothing here limits the rights of the people concerned. GDPR Article 82 lets them claim from the controller or the processor; whoever pays more than their share can claim it back from the other (Article 82(5)).

14. Duration and end

14.1 This agreement lasts as long as we process data in Annex 1 for you, and ends when it has been deleted under clause 10.

14.2 You may end the terms of service, and with them this agreement, if we no longer meet GDPR Article 28 (for example if we cannot give sufficient guarantees under Article 28(1)), with the effect in section 18 of the terms.

14.3 Clauses 4.1, 6, 10, 11 and 13 apply as long as we hold any of the data.

15. Law and courts

As in section 19 of the terms of service.

Annex 1. Description of the processing

Annex 2. Technical and organisational measures

What is in place, as the code and the security page describe it. Nothing here has been checked by an outside auditor.

Sign-ins and tokens:

• People sign in on Meta’s and Google’s own pages. We never see a password, a two-factor code or a passkey.
• Tokens are encrypted with AES-256-GCM before they are stored. Each stored value is tied to the session and purpose it belongs to, so a value copied onto another record cannot be opened.
• A client’s token lives at most 30 minutes; the database enforces the limit itself, with one minute of slack. At the end of the session it is revoked at Meta or Google and deleted. A background job sweeps for anything left every 5 minutes.
• We ask for no key that outlives a client’s session.
• An agency’s own platform sign-ins are encrypted the same way. The owner can disconnect them (they are deleted and revoked); one that stops working is deleted 30 days later.
• Tokens are never written to logs, job data, the audit log, error messages or analytics.

Links and sessions:

• A request link carries 128 random bits and is found by its SHA-256 hash; the link itself is stored encrypted, only so that the agency can copy it again.
• A browser proves it owns a client session with a signed cookie that scripts cannot read; we store only a hash of its secret.
• Each round trip to Meta or Google carries a single-use value, stored as a hash.
• Link pages send no referrer, are never cached and are closed to search engines.

Keeping data small:

• Our code writes no names, email addresses, tokens or raw IP addresses to logs, job data, audit entries or error messages. Where an IP is needed to limit misuse, a keyed hash is stored, not the address; on the log of what was done it is cleared after 30 days.
• One exception, outside our code: the sign-in service (GoTrue) keeps the email address and IP address of each agency sign-in and sign-up in its own log for 90 days, and the IP address and browser of each signed-in agency session until it ends, at the latest after 30 days without use or 90 days after the sign-in. None of this is Annex 1 data.
• The identity of the person who signed in is cleared when the session ends; accounts the client did not choose are not stored.
• Retention periods are in one table and a job applies them every 15 minutes.

Keeping agencies apart:

• Every record that belongs to an agency carries that agency’s ID, and the database itself enforces that a signed-in user reads only the records of agencies they belong to. An automated test proves that one agency cannot read another’s.
• The browser never talks to the database. Every read and write goes through our server.
• Secrets, encrypted tokens and hashes sit in a part of the database that only the server can reach.
• An agency cannot change its own verification level, limits or status.
• The export is read with the owner’s own access, so no other agency’s rows can be in it, and it never holds a token, a sealed value, a secret or a hash.

Integrity and proof:

• The log of who did what cannot be changed or deleted by the application, whichever role it acts as; it can only forget a deleted agency, client or person, and clear its IP hashes.

The web application:

• A strict Content-Security-Policy with a fresh nonce on every request: no inline scripts, no scripts from third parties, fonts and images from our own server only. No page can be framed by another site.
• No analytics, no advertising cookies, no third-party trackers.
• Rate limits keyed on a hash of the IP address.

Hosting and operations:

• Servers at Hetzner in Finland. The application, the database and the sign-in service run there, operated by us. The database is not reachable from the internet; only the web application is.
• The service runs as its own set of containers on a server that also runs another product of the same owner. [OWNER: WHETHER TO MOVE TO A SERVER OF ITS OWN BEFORE LAUNCH]
• Staff pages open only to a signed-in, confirmed staff address on the main domain; anyone else gets an ordinary “not found”.
• Security reports go to abuse@adcato.com, also in /.well-known/security.txt.
• Meta’s data-deletion and deauthorize callbacks remove or revoke what came from Facebook for one person.

Not in place yet:

• No SOC 2 or ISO 27001 report.
• No penetration test by an outside firm. One is planned before agencies use the product with real clients.
• Meta and Google have not reviewed or approved the app.
• The key that encrypts stored tokens is held in the server’s environment, not in a key management service or a hardware module.
• No automated off-site backup, and no tested restore.
• This agreement and the list of sub-processors are published as drafts; a lawyer has not reviewed them.
• No public status page, and no uptime commitment.
• Not known, so not claimed: whether the server’s disks are encrypted at rest. [TO BE CONFIRMED]
• Written confidentiality undertakings (clause 4.1) and the processing record (clause 11.4) do not exist yet.

Annex 3. Sub-processors

The list is at /legal/subprocessors. It says, for each provider, what it does, what personal data it handles, where, and the transfer basis if it is outside the EEA.