Data processing addendum

1. Whether you need this at all

Start here, because for most readers the answer is no.

• You self-host and measure your own sites. You are the controller, there is no processor, and there is nobody to sign a DPA with. Micaforge's authors are not a processor: the build makes no outbound call at runtime, so no data reaches them by any path.
• You rent the server it runs on. Your hosting provider is your processor for the infrastructure. Use their DPA, not this one.
• You measure other people's sites for them. Now you are a processor and they are the controller, and this is the document that belongs between you.
• You are an agency reading a client's install. Same as above, in the same direction.

2. Roles

[CUSTOMER] is the controller. [OPERATOR NAME] is the processor. This addendum forms part of [THE AGREEMENT] between them and takes precedence over it on data protection matters.

Where the processor determines its own purposes for any processing, it is a controller for that processing and this addendum does not cover it.

3. Subject matter, duration and purpose

The processor operates a Micaforge installation that measures traffic to the controller's websites, and provides the controller access to the resulting reports. Processing lasts for the term of the agreement plus the deletion period in section 12. The details are in Annex I.

4. Instructions

The processor processes personal data only on the controller's documented instructions, which include the configuration the controller sets: which sites are measured, the retention period, whether session replay is on, and whether the site's own code calls identify().

If an instruction appears to breach data protection law, the processor tells the controller and may pause that processing until it is resolved.

5. Confidentiality

Everyone the processor allows near the data is bound by confidentiality and is given access only where their work requires it. [Name how you enforce that: named accounts, roles, review cadence.]

6. Security

The processor keeps appropriate technical and organisational measures under Article 32. What the software provides is listed in Annex II. What the deployment provides is the processor's responsibility, and Annex II is where you write it down.

7. Sub-processors

The controller gives general authorisation for the sub-processors listed in Annex I. The processor gives [NUMBER] days' notice before adding or replacing one, and the controller may object on reasonable data protection grounds.

On a single-machine install the list is usually short: the hosting provider, and an email relay if one is configured. It is not zero, and writing “none” when a server is rented from somebody would be false.

8. International transfers

Personal data is processed in [COUNTRY]. Where data leaves the UK or the EEA, the transfer relies on [ADEQUACY DECISION, STANDARD CONTRACTUAL CLAUSES OR UK ADDENDUM], with a transfer risk assessment on file.

Micaforge itself transfers nothing: geolocation reads a database on disk precisely so that resolving an address does not become an international transfer.

9. Helping with data subject requests

The processor passes on any request it receives and helps the controller answer it, taking account of the nature of the processing.

One honest limit, which matters here more than in most DPAs. Micaforge stores no cookie, no raw address and no identifier that survives the day, so in the ordinary case neither party can locate a given person's records at all. Under Article 11 neither is required to collect additional data purely to make that possible. Where the controller's own site attaches an account identifier through identify(), records can be found and deleted by that identifier, and the processor will do so on instruction.

10. Breach notification

The processor notifies the controller without undue delay, and in any case within [HOURS] hours of becoming aware of a personal data breach, with what is known at the time and updates as more is learnt.

11. Audit

The processor makes available the information needed to demonstrate compliance and allows audits by the controller or an auditor it mandates, on reasonable notice, no more than [NUMBER] times a year unless a supervisory authority or a breach requires otherwise.

Because the software is AGPL-3.0, part of the audit is unusually cheap: the controller can read exactly what the code stores rather than take anyone's word for it.

12. Deletion and return

On the end of the agreement, the processor deletes or returns the personal data at the controller's choice within [NUMBER] days, except where law requires it to be kept. Reports export as CSV, and a self-hosted install can be read directly from ClickHouse, so a return is a real option rather than a formality.

Annex I. Details of the processing

Categories of data subject

Visitors to the controller's websites. [Add signed-in users if the site calls identify().]

Categories of personal data

Page addresses and titles, referrer, campaign parameters, browser, operating system, device type, screen and window size, language, time zone, country, region and city, network operator, engagement time, scroll depth, custom event properties chosen by the controller, and a visitor identifier that is a one-way hash of a daily secret, the site, the address and the browser string.

Data not processed

No raw IP address and no browser string is stored on a visitor's record. No cookie is set or read.

Special category data

None by design. The controller must not send it in event properties or in page addresses. [If the controller's site addresses reveal health, beliefs or similar, say so and treat it accordingly.]

Frequency

Continuous, for as long as the tracking script is installed.

Retention

[PERIOD]. Micaforge defaults to keeping event history indefinitely and session replays for thirty days. The daily secret is never kept beyond forty-eight hours.

Sub-processors

[HOSTING PROVIDER, COUNTRY]. [EMAIL RELAY, IF CONFIGURED].

Annex II. Technical and organisational measures

What the software does, which you may state as fact:

Data minimisation at collection

The address is resolved to country, region, city and network operator and then discarded. The browser string is resolved to categories and discarded. Neither is written to a visitor's record.

Pseudonymisation that expires

Visitor identifiers are keyed on a salt that rotates at local midnight and is never kept beyond forty-eight hours, so records cannot be linked across days.

Encryption of stored secrets

Credentials at rest are sealed with XChaCha20-Poly1305, derived from a single operator key held in a file with restricted permissions.

Access control

Organisations, teams, roles and per-site access, with API keys that are scoped and expirable, and share links that can carry a password and an expiry.

No external egress

A self-hosted build makes no outbound network call at runtime, including for geolocation and for update checks.

Transport security

The shipped stack terminates TLS with automatic certificates and publishes no store port outside the machine.

What the deployment must add, which only you can state:

• [Backups: what, where, how often, tested when.]
• [Patching: how the host and the images are kept current.]
• [Access: who can reach the machine, and how that is authenticated.]
• [Monitoring and incident response, including who is called.]
• [Physical security of the hosting environment, usually your provider's.]