> Version 1.11 · published 2026-10-23 · in effect from 2026-10-29

# Processing and security description

**Version 1.11**, last changed 2026-10-22. Earlier versions are kept and provided on request. Each change is listed in the changelog at the end.

## 1. About this description

1.1 **What it is.** This description says how Maplith processes personal data on the controller's behalf: which kinds of data, from which kinds of sources, for which purposes, for how long, with which sub-processors, and which security measures apply. The [Data Processing Agreement](https://maplith.com/dpa) (DPA) refers to it in clause 6. The DPA states the purposes (Annex II) and the minimum security level (Annex III). This description states how Maplith meets them today. Where the two differ, the DPA prevails.

1.2 **Each feature, by the kind of processing it does.** This description states the processing of each feature of the service by the kind of processing it does (DPA clause 6.2): the kinds of personal data, the kinds of sources, the purposes, where and with which sub-processors the data is processed, how long it is kept, and the measures that apply. A feature whose processing adds no new kind of data, source, purpose or recipient and no longer retention is covered by what is stated here. The description does not say how the service is built, and does not name the individual systems a controller connects.

1.3 **How it changes.** When the service changes what this description states, the description changes with it, so that it stays accurate. Every change to it is published as a new version with a dated entry in the changelog (section 7), before or when the change takes effect. A change must stay within the DPA's purposes and must never take the measures below the DPA's floor (DPA clause 6.3). Changes that lengthen a retention period, add a category of personal data or data subjects, or add a kind of record that survives the deletion of a workspace are announced in advance, with a right to object (DPA clause 6.3(d)). Changes to sub-processors follow DPA clause 7.7 and the [sub-processor list](https://maplith.com/sub-processors).

1.4 **How it stays true.** Statements here that describe the product are tied, wherever a check can do so, to the code that makes them true, by checks that run on every change before it can be deployed. A daily control compares production with the published text. A statement that has become untrue is corrected in the next version, and the changelog says so.

1.5 **Earlier versions.** Every version is kept with its date. Each upload queued for a build records the version of this description in force at that moment, beside the version of the DPA (DPA Annex I).

1.6 **Words used.** "The controller" is the customer, as in the DPA. A "connected system" is a business system, file store or other service of the controller's that the controller connects to Maplith. "Masking" means that Maplith tries to replace an identifier with a token before the text is sent or stored. It is a safeguard that cannot guarantee that every identifier is caught.

1.7 **The service in brief.** Maplith keeps metadata about a company's data — which business objects exist, their fields, how they join across systems, processes, metrics and findings — and not copies of its records. Uploaded files are read for a build and then deleted. Hosting, database and file storage are in the EU. A language-model provider in the United States does the model inference. The controller's own agents and assistants use the map within the scope and policies the controller sets.

## 2. What Maplith processes

### 2.1 Sources

Maplith processes only what the controller, its users and its agents make available to it:

- (a) **Files the controller uploads:** exports and other files from its systems.
- (b) **Connected systems.** Maplith reads a connected system with the access the controller grants, read-only: it uses that access to read what the connection selects, joining what it must join to read it where the system requires that, and never to post, send, change or delete the controller's data there, except where the controller lets Maplith's hosted agent comment on and propose changes in the code repositories it connects (section 2.2). The controller decides which systems it connects and, through each connection's settings, what is read; what the settings leave out is not read, or is left out before anything is kept. Some exclusions Maplith keeps by default, such as mail and folders marked private or personal, can be added to by the controller but not removed, and mail and files from, to or owned by a domain the settings deny are left out before anything is written, with only how many were left out counted. In a chat system in which the controller's own people write to one another, Maplith reads only public channels, never private channels or direct or group messages, leaves out by default the channels whose names say they are about people rather than work, refuses access that reads what an individual person can read, and records who wrote a message by the system's identifier, never by name. In a mail system it never reads spam, trash or drafts, and it asks a mail or file system only for permission to read. A connection to such a chat system or to a mail system reads a recent period. A system that holds the controller's conversations with its own customers, such as a support system, is read whole: its conversations, whatever their age, and its contacts and companies. A read-only connection to code repositories is given no permission to their contents, so it never reads their code. Every connection reads a bounded amount. What a connection reads is handled as an uploaded file is. Maplith reads connected systems to build the map and to run the checks the controller sets up or connects a system for, when asked or on a schedule.
- (c) **Reports and events the controller's systems send.** The controller's own systems, tools and agents can send Maplith reports and event notifications: for example that a condition the controller watches holds, that something happened to an item in one of its systems, or what an agent did about a signal. A watch never has Maplith read the controller's systems: the controller's own tools check the watched condition there, with their own access, and report it. A report on a condition the controller watches carries only the identifiers and figures the controller's setup names for it, and one that carries anything else is refused, with nothing of it kept; the identifier such a report is grouped by is never taken from a field the map flags as personal data. Of an event notification, Maplith reads only identifiers, what happened and when, and one sent in Maplith's own format that carries anything else is refused in the same way. Maplith tries to mask such an identifier before it is kept in a signal, and if the workspace's masking terms cannot be read, the report or notification is refused, with nothing of it kept; checking such a report or notification uses no language model. The events of the code repositories the controller connects are the exception: Maplith keeps them as they were sent (section 3), and its hosted agent reads them where the controller lets it. What Maplith keeps of reports and events, sections 2.4 and 3 state.
- (d) **What people and agents write:** questions and messages to the service, notes, reasons and reviews, suggestions for the product, support requests, the facts people state about their systems, the automations the controller's agents register, and the records its agents keep of what they did.
- (e) **Account and usage data** of the controller's users (section 2.7).

Maplith does not select, filter or restrict what the controller's files and systems contain (DPA clause 7.5). The controller decides what it uploads, connects and reports.

### 2.2 Purposes

Maplith processes this data only to provide the service (DPA Annex II):

- to build and maintain the map of the controller's systems and data;
- to analyse the map and its sources: findings, processes, metrics, personal-data flags, signals, suggestions, and playbooks that Maplith writes or drafts from the documents and correspondence the controller shares, and the rules those documents state, restated in Maplith's words (section 2.4);
- to serve the map to the controller's users, to the in-app assistant acting for a member, and to the agents the controller authorises, within the scope the controller sets, including answers in plain language to questions about the map;
- to receive what the controller's systems, tools and agents report, and to raise signals from it;
- to propose changes, and to record and authorise actions by the controller's agents within the policies the controller sets, including the hosted agent a controller can let comment on and propose changes in the code repositories it connects;
- to email the controller's users about their workspace (section 2.6);
- to notify an endpoint the controller sets up that work has arrived for one of its agents (section 2.9);
- for support, security, the audit trail and the assistance of DPA clauses 8 and 9.

### 2.3 Language-model processing

Maplith uses a language-model provider (section 6) for these purposes: it builds the map and analyses it, writes playbooks from the documents and correspondence the controller shares and drafts proposed playbooks from the documents in an export, answers a question an agent asks about the map, answers a member's messages to the in-app assistant, and runs the hosted agent. For this it sends the provider samples and whole files of what Maplith reads (section 2.1), map metadata, and the questions and messages the controller's users and agents write. To answer a question or a message it sends map metadata within the asker's view, never rows from the controller's systems.

Before anything is sent, Maplith tries to mask email local parts, Danish CPR numbers, IBANs and payment card numbers and the masking terms the controller names, and it tries to mask them again in every text a model wrote before that text is stored, and in an answer to a question or a message before it is returned or shown. Mail is decoded first, so that encoded text is masked too, and a mail's attachments that are not text are not sent. It also tries to mask the names of people where the source or an admin marks them as people, and a phone number the source declares as a person's, in everything a build sends and stores except the documents it drafts proposed playbooks from; the names it reads to do so are not kept. A name that appears only in free text, company names and other identifiers are not masked unless the controller names them as masking terms. Masking is a safeguard: it cannot guarantee that every identifier is caught, and the controller decides what its files and systems contain and leaves out what must not be processed. Content from the controller's sources is marked to the model as data, never as instructions to follow. If the workspace's masking terms cannot be read, nothing is sent.

The controller can limit what is sent, under Settings → Privacy & masking: a workspace setting limits the analysis of whole files to samples (whole files are the default, and every build records the setting in force), and Maplith then writes no playbooks from the documents and correspondence the controller shares, although proposed playbooks can still be drafted from the documents in an export; masking terms add identifiers of the controller's own (for a format, the example it is taken from is not kept); and the masking of people's names, on by default, can be switched off. Maplith may suggest columns to mask: it suggests them from the map's names and descriptions, never from values, and keeps only the admin's decision on a suggestion.

The provider deletes what it receives within 30 days and does not use it to train models (section 6). There is no EU endpoint and no zero-retention arrangement in the system today.

### 2.4 What Maplith keeps

- **The map:** objects and their fields, relations, processes, metrics and findings, with a catalogue of what Maplith read — for each system and file its name, format, number of records, what was built from it and when it was read, never its content, with names and paths Maplith tries to mask as it does other stored text — and the facts people state about their systems: Maplith asks for a team or a role, not a person, as who owns or may access a system, and refuses such a fact if it holds an email address; where a fact is shown with its system, it says whether a person or Maplith stated it, never which person, unless it was the reader. A fact about a system is stated by a person, or by Maplith from what it observes, never by a language model or an agent key. The map is metadata about structure, but it is not free of personal data: descriptions a model writes can quote example values, findings quote evidence from the files, and file and folder names are kept as the source names them. Wherever Maplith stores the name of a file or folder, it tries to mask a Danish CPR number in it, and Maplith tells the controller when file names look as if they contain personal data, such as a CPR number, so that it can rename the files: a notice gives how many there are and never a name, and the finding about them gives how many and a few of the names, with what looks like personal data in them masked.
- **Characteristics of the data.** To build and maintain the map, Maplith derives and keeps characteristics of the customer's data, such as statistics, profiles and fingerprints. They hold no rows. Statistics and profiles summarise a column, such as how many of its cells are blank or distinct, the shape and length of its values and the range its numbers fall in; fingerprints are hashes. Fingerprints made with keys Maplith keeps apart from them are pseudonymised: without those keys they say nothing about any value; with them, Maplith can test whether a given value, or a given pair of values in one row, is among them. Some fingerprints, of names and of some values, are made without a key, so a name or a value that can be guessed could be confirmed against them; some of them are kept with signals and with the receipts of reports and events. The fingerprints of what each scan read and of a column's values are read only by Maplith's service; members see at most a summary, such as how many files a scan read.
- **Playbooks** Maplith writes, drafts or sets up, with a record of how each was made: the files it drew on, digests of their text that cannot be turned back into it, the model, the run, the decisions on it, and why one was refused. A playbook Maplith writes describes the process rather than quoting the correspondence: one that repeats a passage of a message word for word is refused. The text of a playbook Maplith drafts is served to no agent until a workspace admin puts it in use.
- **Rules restated from the controller's documents:** the rules the controller's own documents and the correspondence it shares state, restated in Maplith's words: each one short, with its reason and the conditions it applies under (when, for whom, with which exceptions) where the source gives them, the document and section it came from (for correspondence, the message's number and date, never its subject or sender), and where it applies on the map, and a digest of the source's text that cannot be turned back into it. A restated rule is never the source's text. Maplith tries to mask identifiers in what it writes, as it does in other stored text. The rules are served read-only to the controller's agents, within what each agent may see.
- **What the controller sets up, or Maplith sets up on its behalf:** connections and their settings, rules, conditions and schedules, playbooks, metrics, the operations and policies for agents' actions, integrations, the endpoints it sets up for notices (section 2.9), and the glossary of business terms and joins. What Maplith sets up on the controller's behalf is recorded as Maplith's; a person can change or remove it, and Maplith never overrides a person's change.
- **Signals and their history**; receipts of the reports and events the controller's systems send, never their content; the events of the code repositories the controller connects, kept as they were sent (section 3); and the records of what agents asked and did: requests, decisions, approvals, the grants issued for them, the outcomes and values agents state, and usage records. A signal raised from a security alert never carries the secret.
- **Formats Maplith cannot read yet:** where a file the controller shares is structured in a format Maplith cannot read yet, Maplith counts the file formats it cannot yet read, by format only, to decide which to support. With the workspace it keeps a fingerprint of each such format, which holds no name or value from the file, and when it was first met; across workspaces it keeps only how many workspaces met each format and whether Maplith has asked for a reader for it in its own issue tracker. The count holds no content and no identifier of the controller, and the workspace's own record is deleted with the workspace.
- **What people and agents write** (section 2.1(d)). Maplith tries to mask identifiers in what people write to the in-app assistant and to Maplith, in what agents send with their action requests and the automations they register, and in the suggestions they file; if the workspace's masking terms cannot be read, a message to the in-app assistant or to Maplith is neither sent nor stored. Maplith never runs an automation the controller's agents register, and keeps none of the records it handles. A suggestion an agent files for the product is feedback on the service (Terms, section 9.6): with the workspace, Maplith keeps its title, a fingerprint of the title, the agent key that filed it and where Maplith filed it (section 3), and it copies the suggestion into Maplith's own issue tracker, hosted by GitHub, with a reference that only Maplith's service can resolve and that goes with the workspace; Maplith adds no identifier of the workspace, the agent key, the controller or a person, and asks agents to describe the capability they want, never data. That copy is Maplith's own record of feedback on its product, for which Maplith is the controller in its own right, as for the account and usage data in section 2.7: it is not part of the processing on the controller's behalf that this description states, and it stays in the tracker until Maplith deletes it there (section 6.2).
- **Conversations with the in-app assistant** (section 2.5) and **support requests** a member files with Maplith, which Maplith's personnel read to answer them; Maplith's own records of a support request never carry its text. A question an agent asks about the map, with its context and answer, is not kept; only a usage record is.
- **Account and usage data** (section 2.7).

Nothing Maplith stores is shown to a member or an agent key beyond what its role and its view of the map allow. Some records are narrower still: a conversation with the in-app assistant and a support request can be read in the product only by the member who wrote it, and masking terms, each build's record of the columns it took people's names from and the records of how Maplith wrote a playbook only by the workspace's admins whose view covers the whole map. Section 3 says how long each kind of data is kept.

### 2.5 The in-app assistant

A member can write to an assistant in the app. The assistant acts as that member: it reads only what that member may see, holds no agent key, and cannot change anything itself. It may propose a change for the member. It proposes only a change the member's own role allows, and never a change to a term, join or mark a person has already confirmed; a proposal changes nothing until a member whose role allows that change applies it with a click, as that member, and the change is recorded as theirs. A proposal no one has decided expires after 7 days. A proposal can be read by the member it was made for and by the workspace's admins, each within their view of the map; it records what it concerns and the decision on it, never the conversation. The conversation is kept for the member, masked as section 2.3 says, and no admin, agent key or Maplith staff member working under an access grant can read it.

### 2.6 Email to the controller's users

Maplith emails the controller's users about their workspace through the mail provider in section 6: sign-in links, and notices about builds and rules, approvals, access (among them notices to a person added to a workspace or given another role in it), keys, legal documents, sub-processors and the account, and workspace and account deletion confirmations. An owner or admin whose view covers the whole map can also receive the monthly value report: the workspace's counts and the totals of the values its agents and people stated, nothing else from the map. Each recipient switches it on or off, every report carries a link that switches it off at once, and the report goes only to a confirmed address, never to Maplith staff.

### 2.7 Account and usage data

(personal data of the controller's users, processed to operate the service): email address and name through authentication; workspace membership and roles; each member's choice of the mail they receive; sign-in events; funnel events; AI-exposure signals on the marketing site, kept 90 days; records of agents' calls and actions; the audit trail of privileged changes (identifiers and event kinds only); billing data at the payment provider (section 6) once payments are live. For this account and usage data Maplith acts as a controller in its own right and the [privacy policy](https://maplith.com/privacy) governs it; it is listed here for completeness.

### 2.8 Sign-in and account security

2.8.1 **Ways to sign in.** A member signs in with a one-time link sent by email or, if they choose, with a Google, Microsoft or GitHub account. With single sign-on, the identity provider returns the member's email address, name and its own user identifier to Maplith (section 6.4).

2.8.2 **Two-factor authentication.** A member can add two-factor authentication to their account by registering an authenticator app. The authentication provider (Supabase, on the sub-processor list) then keeps, for each authenticator registered, the name the member gives it, its type, when it was added and the shared secret the app uses to make codes, until the member removes it or the account is deleted.

2.8.3 **The bot check on sign-in.** Where Maplith has switched it on, the sign-in and sign-up page runs Cloudflare Turnstile, a check that tells a person from an automated script. The check is loaded from Cloudflare (on the sub-processor list) and receives the visitor's IP address and signals from the browser. The authentication provider verifies the check's result before it sends a sign-in link or signs the person in. Maplith does not store the result.

### 2.9 Notices to an endpoint the controller sets up

Maplith can send a notice to an endpoint the controller sets up, so that one of its agents learns that work has arrived for it, or that a person has decided a request the agent made. The controller chooses the endpoint and can pause or remove it at any time. A notice names only what that agent may see, and only as identifiers, a kind, a severity or a decision, times and counts, never content: the agent reads what it is about from the map. Maplith keeps a record of the notices it sent and what became of each, never the content of an answer (section 3.1).

## 3. Retention

### 3.1 The retention schedule

The retention schedule Maplith applies to data processed on the controller's behalf. A longer period is announced in advance (DPA clause 6.3(d)); a shorter one takes effect with its changelog entry.

| Data | Retained | Deleted |
|---|---|---|
| Uploaded files | During the build only | After the build, success or failure; anything left after one day (automated) |
| Working copies of what Maplith reads for a build or a scheduled check | During the build or the check | When it ends, success or failure (automated); if the service stops mid-way, by its sweep or when its container is replaced |
| The map: runs (with the record of each rollback of the map to an earlier scan and the reason given for it), objects, fields with their personal-data flags and the controller's corrections, relations, processes, metrics, findings, the catalogue of what Maplith read, the automations the controller's agents register, and playbooks with their schedules | While the workspace exists | On deletion request, on termination (DPA clause 10.4), or when a workspace has had no sign-in for 12 months after reminders to its admins (Terms, section 8) |
| Characteristics of the data: statistics, profiles and fingerprints Maplith derives to build and maintain the map, which hold no rows, the fingerprints pseudonymised or, some, made without a key (kept so that the map stays consistent from one build to the next) | While the workspace exists: some with the scan they were derived from, others until later uploads of the same source replace them | With the workspace (automated) |
| Masking settings: the masking terms an admin names, the admin's decisions on suggested masking, and counts of what masking matched and where, never a value | While the workspace exists; a term's match counts until the next scan replaces them; each build's record of the columns it took people's names from, kept with that build | With the workspace (automated); a term and its counts also when an admin deletes the term |
| Records of how Maplith wrote or drafted a playbook: the files it drew on, digests of their text that cannot be turned back into it, the model, the run, the decisions on it, and why one was refused | 12 months from drafting or, for a playbook Maplith wrote, from the last scan that found its process or kept a person's decision on it; or until the workspace is deleted, whichever is earlier | Daily control; deletion switched on by the operator |
| Records of Maplith staff access: who, the written reason, when it opened, was first used and ended, and whom the notice went to | While the workspace exists | With the workspace (automated) |
| Rules restated from the controller's documents and correspondence: each rule in Maplith's words, with its reason and conditions, the document and section or the message it came from, where it applies on the map, and a digest of the source's text that cannot be turned back into it, never the source's text | While the workspace exists; each scan keeps its own set, with its run | On deletion request, on termination (DPA clause 10.4), or when a workspace has had no sign-in for 12 months after reminders to its admins (Terms, section 8); with the workspace (automated) |
| Workspace configuration: connections (their settings and encrypted credentials), the facts stated about each system and the corrections made to how systems are recognised, rules, conditions and schedules with their history, the operations and policies for agents' actions, metrics the controller defines, integrations it installs, the endpoints it sets up for notices (section 2.9) with their credentials (encrypted), the credentials its systems send reports with (a hash, or encrypted), and who created or changed each, a person or Maplith (kept so that the workspace works as it was set up) | While the workspace exists, unless an admin removes the item sooner | With the workspace (automated) |
| Receipts of reports and events: which report or event arrived, from which sender, when, and what became of it, never its content, only fingerprints of the identifiers it names (kept so that the workspace's admins can see that reports arrive and why one was refused) | 30 days; a receipt of a report older than that is removed by the next report or event Maplith receives, and a receipt of an event by the daily control | By later reports and events, and by the daily control (automated); with the workspace (automated) |
| Records of notices sent to an endpoint: what queued a notice, the notice with the identifiers it named, whether it arrived and why one did not, never the content of an answer (kept so that the workspace's admins can see that notices arrive) | 30 days | Daily control; deletion switched on by the operator; with the workspace (automated) |
| Rule notices: a notice to the person who set up a rule that the rule could not be checked, whether they read it and whether the mail was sent; the mail goes only to that person, while they are a member of the workspace whose view covers the whole map and not Maplith staff, and their address is looked up when the mail is sent, never kept (kept so that the person who set up the rule is told once, by email and in the app) | 12 months from when the rule could be checked again, or until the workspace is deleted, whichever is earlier; a notice for a rule that still cannot be checked is kept until it can be | Daily control; deletion switched on by the operator; with the workspace or the rule (automated) |
| In-app assistant conversations: a member's messages and the assistant's replies, masked, with the map items a reply cited and when each message was written, never what the tools returned (kept so that the member can continue a conversation) | Until the member's membership or the workspace is deleted; a conversation whose last message is more than 30 days old is deleted by the daily control once Maplith's operator has switched its deletions on, and until then it is counted, not deleted | With the membership or the workspace (automated); daily control, deletion switched on by the operator |
| Support requests: what a member wrote to Maplith from the app, masked, with the section of the app they were in, never the page's address, the kind of error it showed, the app's version and Maplith's answer (kept so that Maplith can help and the member can follow their request) | 12 months from the request, or until the member's membership or the workspace is deleted, whichever is earlier | Daily control; deletion switched on by the operator; with the membership or the workspace (automated) |
| Glossary: business terms, joins between them, proposals and every decision on them, by a member or by Maplith on its own evidence, and reviews of joins with their notes (kept so that confirmed business terms stay stable across scans) | While the workspace exists | With the workspace (automated) |
| Access changes to members and agent keys: who changed whose role, scope or key, or that Maplith made the change with no person behind it, with the value before and after, and the notice to a person added to a workspace or given another role in it, with whether they read it and whether the mail was sent (kept so that the workspace's admins can see how access came to be what it is, and so that the person is told) | While the workspace exists; the audit trail of privileged changes keeps its own entries (section 3.3) | With the workspace (automated) |
| Feature suggestions an agent files: the title, a fingerprint of it, the agent key that filed it and where Maplith filed it (kept so that the same suggestion is not filed twice). The copy in Maplith's own issue tracker is Maplith's own feedback, not data processed on the controller's behalf (section 2.4) | While the workspace exists | With the workspace (automated) |
| Authorisation codes from a person's consent to an assistant's connection: the user who consented, the client and the key the code was exchanged for (kept so that a code used twice revokes the key it gave) | While the workspace exists at the longest; a code more than an hour past its expiry is removed when a later code is exchanged | With the workspace (automated); by a later exchange |
| Signals and their history (who took, planned, handed over or closed it and when, with the notes left; a signal can quote a finding or carry the identifiers and figures a report brought), events from the code repositories the controller connects, kept as they were sent (which can include the user names, names and email addresses of the people who acted, and the text of the item concerned), and records of approval notices sent (the recipient's user id) (kept so that the controller's agents and admins can see what changed, who acted on it and what was sent) | 12 months from the event, or until the workspace is deleted, whichever is earlier; the history of a signal's current episode stays as long as the signal does | Daily control; deletion switched on by the operator |
| Agent keys, and for a key made at a person's consent to an assistant's connection, who that person is (kept so that the controller's agents can reach the map, and so that a person's connections end when they leave; the key itself is stored only as a hash) | 12 months without use, or 12 months from its revocation for a revoked key, or until the workspace is deleted, whichever is earlier. Keys in Maplith's own demonstration and internal workspaces, the public demonstration key among them, are exempt | Daily control; deletion switched on by the operator. A key that was never revoked is deleted only after a warning to the workspace's admins at least 30 days before the date — by email, once, and as a notice in the app — and only if it has not been used since; any use cancels the deletion, and a workspace with no admin to warn keeps its keys |
| Agent activity records: action requests, their decisions and approvals, the in-app assistant's proposals and the decisions on them, the signed grants issued for them, the outcomes and values agents state, records of the calls agents make, and usage records (one per model call: time, model, tokens, cost, and for the in-app assistant the member it answered) | 12 months from the event, or until the workspace is deleted, whichever is earlier; a grant is deleted with its request | Daily control; deletion switched on by the operator |
| Application logs | 30 days | Automated once implemented |
| Audit trail of privileged changes (section 3.3) | 5 years from the event, or until the organisation is deleted, whichever is earlier; a workspace's deletion does not remove its entries | At the end of the period, from the oldest entry; within it, not altered or erased on request (section 3.3) |

### 3.2 How the schedule is enforced

The schedule is checked by the product every day: rows past their period are found and, once Maplith's operator has switched deletion on after checking the first reports, deleted — until then they are counted and reported, not deleted. Today one switch turns deletion on for every row in the schedule that names the daily control. Inactive workspaces are reminded at 9 and 11 months and 14 days before the date, and deleted on it only when that rule is on and the final reminder was delivered; no workspace is deleted for inactivity without written notice to its admins, whatever the switch. Every run of the control is logged.

### 3.3 The audit trail of privileged changes

One entry for every privileged change to the account: agent keys; members, their roles and their access; connections, masking terms, rules, playbooks and the glossary, including what Maplith sets up or decides on the controller's behalf; the facts stated about systems; the in-app assistant's proposals and the decisions on them; reviews of joins; the pausing and resuming of a workspace's agents; the organisation profile; legal documents accepted; consent to an assistant's connection; integrations; the endpoints for notices (section 2.9); Maplith staff access; workspaces created and deleted; and rows removed by the retention control. Each entry holds the kind of event, the time, where it came from (the app, an agent, Maplith's service or Maplith's operator), the identifier of the user or agent key that made it, the identifier of what was changed, and for changed settings the old and new value — except for a field that could hold personal data (a name, an address, an email address, a login), for which the entry records only that the field changed. Some entries hold less: for a fact stated about a system, the field, never the answer; for the in-app assistant's proposals, their kind and counts; for reviews of joins, identifiers and the effect; for a playbook Maplith writes from the controller's documents and correspondence, identifiers and counts, never a path or a title; and for the pausing of a workspace's agents, whether a reason was given, never its words. The trail holds identifiers, never contact details or IP addresses; the names and addresses shown beside an entry are looked up from the live account at the time of reading. It is kept for security and accountability: so that the organisation can establish who changed what and when, and so that a tampered trail is detectable. Because the trail is evidence, an entry is not altered or erased on request within the period — the identifiers it holds are retained under Article 17(3)(e) GDPR (the establishment, exercise or defence of legal claims) and, in support, Article 17(3)(b) (compliance with the legal obligation to keep records of the security of processing, Articles 5(2) and 32); what a person can be identified by from the account itself (name, email address) is erased with the account, and the entry then names only an identifier of a former member.

## 4. Deletion, return and data subject requests

- **Deletion.** An owner or admin of the organisation deletes a workspace — its map and everything kept with it, files still in storage, its configuration, masking settings, glossary, signals, records, conversations, support requests, agent keys, integrations and memberships — under Settings → Data, with a typed confirmation; the workspace's admins are told in writing, to at most three confirmed addresses, and a log row records the deletion: counts, the user id of the person who asked, and — only while a written confirmation is still owed — the user ids of up to three admins it is owed to, which are removed once it has been sent. The row is kept as a record. The organisation's audit trail of privileged changes (above) also keeps its entries about the workspace, the deletion itself among them; they name the workspace and the requester by identifier only. Deletion of an organisation or of an account is not yet self-service: Maplith's operator performs it within 30 days of the request and confirms it in writing. A request concerning one named person in the map is handled by the operator within 30 days. Copies in the provider's database backups expire with the provider's backup retention. Billing records survive deletion where the law requires them to.
- **Return.** On request, Maplith provides the map — objects, fields, relations, processes, metrics and findings — in a machine-readable form (JSON). A workspace admin exports it under Settings → Data, as JSON in the shape agents are served; take it before deleting a workspace. Uploaded files cannot be returned: they no longer exist once the build has read them.
- **Access, rectification and erasure for a named person.** The controller supplies the identifiers; Maplith's operator searches the stored map — descriptions, findings and their evidence, playbooks and their drafts — and the in-app assistant's conversations for them, reports the matches, and on instruction removes or masks them, within 30 days, and in any case in time for the controller to meet its own one-month deadline under Article 12(3) where the controller forwards the request within 5 working days of receiving it. The written reason in a record of Maplith staff access cannot be changed once the record is opened and is kept as written for as long as the record is kept (section 3.1); where a request concerning a named person reaches it, Maplith's operator tells the controller and handles the request under the same procedure, within the same time limits.

## 5. Security measures in force

This section states what exists today, above the floor in DPA Annex III. Planned measures are labelled as planned. Nothing here is aspirational.

### 5.1 Personnel and confidentiality

Maplith is operated by one person, its founder, who has administrative access to every system as the processor's sole personnel and is bound by the confidentiality obligations of the DPA. There are no employees and no contractors with access. Staff presence in a customer workspace is visible: a member type "Maplith staff" that only Maplith can set. For a support case, Maplith staff may open read-only access to a workspace's map without the controller's prior approval, stating a written reason. The organisation's owners, and the privacy or data-protection contact the controller may register in the organisation profile, are told by email the moment it opens — which workspace, who, the reason, when it opened and until when — and it is shown in the app to every member of the workspace; if that email cannot be sent, the access is closed again at once. The access covers what a read-only member who sees the whole map sees; it never reaches uploaded files, masking terms, agent keys, connections or settings, and it allows no change. It ends by itself after four hours and cannot be extended; any admin of the workspace, and the staff member, can end it sooner. The opening, the notice, the first use and the end are recorded on the access itself, which the workspace's members can read, and in the audit trail of privileged changes. Any future personnel or contractor with access signs a written confidentiality undertaking before access is granted.

### 5.2 Access control in the product

- Row-level security on every table. A caller who is not signed in holds no privilege on Maplith's own tables, and a daily check reports any change to what a caller who is not signed in, or a signed-in user, may do there. A signed-in user sees only the workspaces they are a member of; per-user grants narrow access further, to domains or to single objects. Tenant isolation is tested end to end.
- Sign-in: one-time links by email or single sign-on with Google, Microsoft or GitHub; two-factor authentication with an authenticator app, which any member can add; and, where Maplith has switched it on, a bot check on the sign-in page (section 2.8).
- Roles in two dimensions — organisation roles (owner, admin, member) and workspace roles (admin, builder, viewer) — enforced server-side on every change.
- Server-side credentials never reach the browser.
- Every privileged change to an account is recorded in an append-only, tamper-evident audit trail that the organisation's owners and admins can read, filter, export and verify at any time; it holds identifiers and event kinds, never secrets, contact details or customer data (section 3.3).
- Agent access: keys stored only as hashes and shown once; scope enforced on every call; a key is read-only unless an admin chooses otherwise; what a read-only key may still send — a report it is bound to, a question about a join of the map, a suggestion — changes nothing on the map until a person decides; revocation immediate; rate limits per key and per workspace protect the service, and a call over a limit is refused with an answer that says so; every agent action logged with actor, target and change; the hosted agent never merges a change it proposes. An allowed action is answered with a short-lived, single-use grant signed by Maplith, which the controller's own systems can verify against the keys Maplith publishes before they act; the grant binds the action's target and parameters, and revoking an agent key, or changing the key's own policy or the action policy that decides the action, revokes the grants not yet used.
- The emergency brake: a workspace admin can pause every agent of the workspace at once, and the agents run again only when an admin resumes them. While the workspace is paused, nothing its agent keys ask is done, the hosted agent does not act, and no approved action can be carried out.
- Assistant connections: the agent key made when a person consents to an assistant's connection is that person's own. It is revoked when they leave the workspace, including when an admin removes them or their account is deleted, and connecting the same assistant again replaces at most their own earlier key, never another person's. A key an admin creates in Settings belongs to the workspace and is not revoked when that admin leaves. A key made before Maplith recorded who consented, and that can no longer be traced to that person, is not revoked this way; an admin revokes it in Settings.
- The in-app assistant acts as the signed-in member and reads only what that member may see (section 2.5); its replies are shown as restricted text, with no images and links only within the workspace; each member and each workspace has a daily limit, and Maplith can switch the assistant off for every workspace at once.
- Reports and events: the credentials the controller's systems send them with are shown once and stored only as a hash or encrypted; a sender can report only to what it is bound to, and an agent key only within its scope; a signed report whose signature is missing, wrong or stale is refused; reports are rate-limited. A customer workspace receives reports of a condition it watches only once Maplith staff have switched them on for it, and each switch is recorded in that workspace's audit trail.

### 5.3 Encryption and transport

TLS on every connection, with HSTS. Every request passes through the edge provider (section 6), and the application refuses one that did not. Credentials the controller gives Maplith are encrypted at the application layer with AES-256-GCM, the key held only in the hosting environment and in Maplith's EU-hosted secrets manager, and no signed-in user can read them. Encryption at rest of the database and the file storage is the hosting provider's.

### 5.4 Application hardening

A content security policy and the usual security headers. Protection against server-side request forgery and path traversal wherever a connection, an endpoint for notices or an upload names a location. Uploads are limited in the number of files, the size of each file, the size of each upload and what an upload holds once its compressed files are unpacked, and scans are limited per workspace per day; the limits in force are stated in the documentation and, for uploads, on the upload page. Event deliveries from connected systems are authenticated before anything else happens.

### 5.5 Source-file handling

Uploaded files are kept in private storage under names that reveal nothing, read for the build and deleted after it, whether it succeeded or failed; a sweep removes anything older than a day. Working copies exist only during a build or a scheduled check and are removed when it ends, or by a sweep if the service stopped mid-way. A scheduled check of the controller's rules reads its connected systems again to check the rules against the map; it calls no model and keeps nothing from what it read except the signals it raises and a record of each rule it checked.

### 5.6 Personal data in the map and in what is sent for inference

Maplith tries to mask identifiers before content is sent to the model provider and again before model-written text is stored (section 2.3). Masking is a safeguard: it cannot guarantee that every identifier is caught, and the controller decides what its files and systems contain. Every field of the map carries a personal-data flag, set by Maplith as a best-effort label that can be wrong; the controller corrects it, and a correction is kept across scans. The flags feed the export of the record of processing (DPA clause 7.6.4).

### 5.7 Secrets and change control

No secrets in the source code, verified across its history. The keys that give access to customer data or protect it are held only in the hosting environment and in Maplith's EU-hosted secrets manager, except one, used by Maplith's own quality checks and held as an encrypted secret at the code host; there are no other copies, apart from the shared secrets a provider holds by design to verify Maplith or to be verified by it, and keys are rotated on any doubt. The main branch is protected, and every deploy waits for the CI check suite (typecheck and tests); a failing change never deploys. Dependencies are pinned, kept current and scanned for known vulnerabilities; a push that would expose a secret in the code is blocked, and alerts of secrets exposed in the code, or pushed past that block, are checked daily.

### 5.8 Monitoring and incident handling

Application alerts reach Maplith's operator. Incident response: a one-page written runbook (detection, containment, assessment, notification under DPA clause 9 within 48 hours, documentation) kept with the security document. There is no on-call rota, no external penetration test and no certification (ISO 27001, SOC 2). A controls framework and a compliance export are planned. Keys and integrations can be revoked immediately from the app.

### 5.9 Backups and availability

The database is backed up daily by the provider (Supabase), and the backups are retained for seven days; point-in-time recovery is not switched on. Uploaded files are not backed up by design: they are read once for the build and then deleted, and the controller holds the originals. A restore has not yet been rehearsed, so no recovery time is stated. No availability commitment is made (Terms, section 11).

### 5.10 Assistance measures (DPA clause 8.4)

For an impact assessment or a prior consultation, Maplith provides this description and the sub-processor list, and answers written questions within 30 days. A transfer impact assessment for the model provider is in preparation and is provided on request once it is complete. Data subject requests: section 4. Breaches: DPA clause 9.

## 6. What each sub-processor receives

The [sub-processor list](https://maplith.com/sub-processors) names each sub-processor, its purpose, where it processes and on what basis (DPA Annex IV). This section says what each one receives today for each feature, by kind of data.

### 6.1 Per provider

- **Supabase**. **Purpose:** Database, authentication and file storage. **Receives:** Account data (email address, name, workspace membership, sign-in events); uploaded files until they are deleted after the build; the map and what is kept with it (section 2.4); usage and audit records. **Where:** Frankfurt, Germany (AWS eu-central-1). **Basis:** None: processing in the EU.
- **Railway**. **Purpose:** Hosting of the application and the build service. **Receives:** Everything in transit through the application and the build service; application logs. **Where:** EU West (Amsterdam, Netherlands); both the application and the build service, verified from the provider's deployment records on 2026-09-09. **Basis:** None: processing in the EU.
- **Anthropic**. **Purpose:** Model inference: builds the map and analyses it, writes playbooks from the documents and correspondence a controller shares and drafts proposed playbooks from the documents in an export, runs the hosted agent, answers an agent's question about the map and answers a member's messages to the in-app assistant (section 2.3); and Maplith's own work tools on Anthropic's commercial plans (Claude for Work, including Claude Code), which Maplith's personnel use for support, diagnosis and development. **Receives:** Customer file content: during a build, samples and whole files of what Maplith reads from the controller's sources, among them the documents and correspondence the controller shares, with map metadata; for the hosted agent, the text of the item it works on and map context; to answer an agent's question or a member's message, the question or message with map metadata within the asker's view, never rows; in Maplith's work tools, the parts of a workspace's map, run records and files that a support, diagnosis or development task in that workspace requires. **Where:** United States (api.anthropic.com); contracting entity for EEA customers: Anthropic Ireland, Limited. **Basis:** The Commission's standard contractual clauses (Decision (EU) 2021/914) under the provider's Data Processing Addendum, which its Commercial Terms of Service incorporate by reference, so it binds through Maplith's acceptance of those terms and no separately signed copy exists (Commercial Terms, read 2026-09-09 and again on 2026-09-24). Maplith does not rely on the EU-US Data Privacy Framework for this transfer. It deletes inputs and outputs within 30 days of receipt (longer only where its trust-and-safety or legal obligations require it); there is no zero-data-retention arrangement yet, and one is being requested. Its commercial terms exclude training on customer content. Read from the provider's published terms on 2026-09-09.
- **Cloudflare**. **Purpose:** DNS, TLS termination, reverse proxy and DDoS protection; cookieless web analytics on maplith.com, where switched on, with your consent; and, where Maplith has switched it on, the Turnstile bot check on the app's sign-in and sign-up page (section 2.8.3). **Receives:** Request metadata and IP addresses for every request; page views on the marketing site, where the analytics are switched on and the visitor consented; for the bot check, the IP address and browser signals of the person signing in. **Where:** Global edge network. **Basis:** Provider's Data Processing Addendum with standard contractual clauses. Maplith is on the provider's self-serve plan, so the contracting entity is Cloudflare, Inc. Read from the provider's published terms on 2026-09-09.
- **Resend**. **Purpose:** Transactional email: sign-in links, build notifications, the acceptance record, notices to a person added to a workspace or given another role in it, workspace and account deletion confirmations, approval notices, legal-version reminders, inactivity reminders, broken-rule notices, agent-key deletion notices, staff-access notices, sub-processor notices, material-change notices and the monthly value report (section 2.6). **Receives:** Recipient email address and message content. **Where:** Mail is delivered through the provider's EU infrastructure (Amazon SES eu-west-1, Ireland; evidenced by the sending and bounce records for send.mail.maplith.com, read 2026-09-09). The provider states in its own data processing addendum that its primary processing operations take place in the United States, so its own handling of the message is not confined to the EU. **Basis:** Provider's data processing addendum with standard contractual clauses. Read from the provider's published terms on 2026-09-09.
- **Stripe** (not live). **Purpose:** Payments and the customer register. **Receives:** Billing identity and payment data. **Where:** European Union and United States. **Basis:** Provider's Data Processing Agreement with standard contractual clauses. Read from the provider's published terms on 2026-09-09.
- **Dinero** (not live). **Purpose:** Bookkeeping and invoicing. **Receives:** The billing identity an invoice carries — legal name, address, VAT number and billing email — with the invoice lines, amounts and payment status. No uploaded content and no part of the map. **Where:** European Union. The provider is Visma Dinero ApS (CVR 34731543, Copenhagen), and it states that the application and its database servers run on Google Cloud Platform and Microsoft Azure in Germany, the Netherlands, Finland and Sweden. Read from the provider's published sub-processor register on 2026-09-09. **Basis:** None for this data: it is processed in the EU. The provider names one sub-processor of its own outside the EU (Mailchimp, United States, for the provider's own mail) and states that it uses the Commission's standard contractual clauses wherever a sub-processor sits outside the EU. Read from the provider's published terms on 2026-09-09.
- **GitHub** (optional). **Purpose:** Code hosting for the private repositories in which a controller lets Maplith's hosted agent comment on issues and propose changes. **Receives:** What the hosted agent writes in those repositories (its comments and proposed changes) and the issue text it works on. **Where:** United States. **Basis:** Provider's Data Protection Agreement with standard contractual clauses. Read from the provider's published terms on 2026-09-09.

A provider marked **announced, from a date** is inside its notice period (DPA clause 7.7.2): it is on the list so that the notice is public, and it receives nothing until that date. A provider marked **not live** receives nothing until it goes live.

### 6.2 Transfers outside the EEA, as they take place today

- **Anthropic (United States).** Model inference during a build, for writing playbooks and drafting proposed ones, for the hosted agent, to answer an agent's question about the map and to answer a member's messages to the in-app assistant, and Maplith's own work tools on Anthropic's commercial plans (Claude for Work, including Claude Code), used by Maplith's personnel for support, diagnosis and development. Customer file content is sent, with map metadata and the questions and messages the controller's users and agents write; section 2.3 says what. Consumer plans are not used for customer data. Maplith's contract is Anthropic's Commercial Terms of Service, which incorporate Anthropic's Data Processing Addendum by reference and identify Anthropic Ireland, Limited as the contracting entity for customers in the EEA (Commercial Terms, read 2026-09-09). Maplith relies on the Commission's standard contractual clauses under that addendum, which binds through Maplith's acceptance of the Commercial Terms; no separately signed copy exists (confirmed 2026-09-24). Maplith does not rely on the EU-US Data Privacy Framework for this transfer (the Data Privacy Framework list was checked on 2026-09-09). Under its terms the provider deletes API inputs and outputs within 30 days of receipt (longer only where its trust-and-safety or legal obligations require it) and does not use them to train models. Maplith has no zero-data-retention arrangement today and has an open action to request one. Read from the provider's published terms on 2026-09-09.
- **Resend (United States, delivering through EU infrastructure).** Email addresses and the contents of the mail Maplith sends: sign-in links, build notifications, the acceptance record, notices to a person added to a workspace or given another role in it, workspace and account deletion confirmations, approval notices, legal-version reminders, inactivity reminders, broken-rule notices, agent-key deletion notices, staff-access notices, sub-processor notices, material-change notices and the monthly value report (section 2.6). Delivery runs through the provider's EU infrastructure (Amazon SES eu-west-1), and the provider states that its own processing operations take place in the United States. Basis: the provider's data processing addendum with standard contractual clauses. Read from the provider's published terms on 2026-09-09.
- **Cloudflare (global edge network).** Request metadata and IP addresses, and, where the sign-in bot check is switched on, the browser signals it reads (section 2.8.3). Basis: the provider's Data Processing Addendum with standard contractual clauses. Maplith is on the provider's self-serve plan, so the contracting entity is Cloudflare, Inc. Read from the provider's published terms on 2026-09-09.
- **GitHub (United States).** Only for controllers who let Maplith's hosted agent work in their code repositories: what the hosted agent writes there and the issue text it works on. Basis: the provider's Data Protection Agreement with standard contractual clauses. Read from the provider's published terms on 2026-09-09. GitHub also hosts Maplith's own issue tracker, into which Maplith copies the feature suggestions agents file. Maplith treats that copy as its own feedback on its product (section 2.4; Terms, section 9.6), not as a transfer of the controller's data: it adds no identifier of the workspace, the agent key, the controller or a person, asks agents to describe the capability they want and never data, and tries to mask identifiers in the text (section 2.3).
- **Stripe (United States and EU).** Not live; no customer data is sent today. Listed so that going live needs no further notice; basis on going live: the provider's Data Processing Agreement with standard contractual clauses.

### 6.3 Notes on individual providers

- **Supabase:** The primary store. The region was verified through the provider's management API.
- **Anthropic:** The single most important row. Maplith tries to mask identifiers before content is sent and before model-written text is stored (section 2.3), as a safeguard that cannot guarantee that every identifier is caught, and the controller can limit the analysis of whole files to samples. There is no EU endpoint in the system today; an EU-resident endpoint with zero retention is a later track.
- **Cloudflare:** Terminates TLS. The analytics beacon, when it is switched on, runs on the marketing site only, never in the app, and loads only after the visitor consents on the cookie banner; it is switched off today. The Turnstile bot check, where switched on, runs on the app's sign-in and sign-up page only.
- **Resend:** Sends from mail.maplith.com with tracking deliberately turned off.
- **Stripe:** Payments are in sandbox mode; no customer has been charged. Listed now so that going live needs no further notice.
- **Dinero:** Added to the list with effect from 2026-10-09, after notice was given on 2026-09-09 to every address on the notice list (DPA clause 7.7). It receives nothing until Maplith issues its first invoice: no customer has been invoiced, and the only account that exists today is a test account holding no customer data.
- **GitHub:** Only for workspaces that let the hosted agent work in their repositories. GitHub also hosts Maplith's own issue tracker, which holds the feature suggestions agents file. Maplith treats them as its own feedback on its product (section 2.4), not as a transfer of the controller's data: it adds no identifier of the workspace, the agent key, the controller or a person, asks agents to describe the capability they want and never data, and tries to mask identifiers in the text (section 2.3).

### 6.4 Independent third parties that are not sub-processors

Google, GitHub and Microsoft, when a user chooses to sign in with an existing account, act as identity providers under the user's own relationship with them: they receive the sign-in request and return an authentication assertion (email address, name and the provider's user identifier) to Maplith. They do not process data on Maplith's instructions and are therefore not sub-processors; they are disclosed here for transparency and in the privacy policy.

## 7. Changelog

Each earlier entry is summarised here; each earlier version is kept with its own changelog and provided on request.

| Version | Date | Kind | Change |
|---|---|---|---|
| 1.0 | 2026-10-07 | First version | Carries over the processing the DPA, version 1.12, described, with sign-in and account security added: single sign-on, two-factor authentication and a bot check on sign-in. |
| 1.1 | 2026-10-12 | Recorded here only | Names records kept with drafted playbooks, reviews of the map's joins, a summary of what each scan read, and the control with which an admin pauses a workspace's agents. |
| 1.2 | 2026-10-13 | Recorded here only | Names more map metadata sent for drafting playbooks and records already kept under existing retention rows, and says how a request that reaches a record of staff access is handled. |
| 1.3 | 2026-10-13 | Recorded here only | States the rate limits on agent access without a number. |
| 1.4 | 2026-10-14 | Recorded here only | Names the playbooks Maplith writes from the documents and correspondence the controller shares, and the decisions Maplith makes on its own evidence, which people can correct. |
| 1.5 | 2026-10-14 | Recorded here only | Names support requests, kept 12 months, and events from connected code repositories; states the upload limits without numbers. |
| 1.6 | 2026-10-15 | Recorded here only | Names connected systems read as uploaded files are, facts Maplith states about systems from what it observes, what Maplith sets up on the controller's behalf, the monthly value report and plans on a signal. |
| 1.7 | 2026-10-18 | Recorded here only | Restated in categories: each feature's processing by the kind of processing it does, with the kinds of data, sources, purposes and retention, the sub-processors and the security measures in force (section 1.2). It no longer says how features are built or names the systems a controller connects, and it keeps every protection earlier versions stated. Stated in general words: the characteristics Maplith derives from the data, which hold no rows, whose fingerprints are pseudonymised or, some, made without a key, and which are kept while the workspace exists; and the reports and events the controller's systems send, whose receipts are kept 30 days. Corrected: a feature suggestion is also copied to Maplith's own issue tracker, hosted by GitHub, as Maplith's own feedback on its product, and from this version Maplith adds no identifier of the workspace, the key or a person to the copy; and the keys that give access to customer data or protect it are also held in an EU-hosted secrets manager and, one of them, at the code host. Takes effect when published. No category of personal data or of data subjects is added, no retention period is longer, no new sub-processor, purpose, location or transfer basis is used, and no new kind of record survives the deletion of a workspace, so nothing here needs advance notice (DPA clause 6.3(d)). |
| 1.8 | 2026-10-19 | Recorded here only | Names the notices Maplith can send to an endpoint the controller sets up, so that one of its agents learns that work has arrived for it: identifiers, never content, with a record of them kept 30 days (sections 2.9 and 3.1), and the endpoint among the workspace's configuration. No category of personal data or of data subjects is added, no retention period is longer, no new sub-processor, location or transfer basis is used, the purpose is one the DPA's Annex II states, and no new kind of record survives the deletion of a workspace, so nothing here needs advance notice (DPA clause 6.3(d)). |
| 1.9 | 2026-10-19 | Recorded here only | Names the rules Maplith keeps from the documents the controller shares: restated in Maplith's words, short, tied to where they apply on the map and served read-only to the controller's agents, never the document's text, with their retention (sections 2.4 and 3.1). They are derived from documents Maplith already reads and kept like the map, so no category of personal data or of data subjects is added, no retention period is longer, no new sub-processor, location or transfer basis is used, the purpose is one the DPA's Annex II states, and no new kind of record survives the deletion of a workspace, so nothing here needs advance notice (DPA clause 6.3(d)). |
| 1.10 | 2026-10-21 | Recorded here only | The rules Maplith restates now also come from the correspondence the controller shares, a source this description already names, and keep the conditions they apply under (when, for whom, with which exceptions) where the source gives them; a rule from correspondence cites the message's number and date, never its subject or sender (sections 2.4 and 3.1). No category of personal data or of data subjects is added, no retention period is longer, no new source, purpose, sub-processor, location or transfer basis is used, and no new kind of record survives the deletion of a workspace, so nothing here needs advance notice (DPA clause 6.3(d)). |
| 1.11 | 2026-10-22 | Recorded here only | Maplith counts the file formats it cannot yet read, by format only, to decide which to support: with the workspace it keeps a fingerprint of each such format and when it was first met, and across workspaces only how many met each format (section 2.4). The count holds no content and no identifier of the controller, so it is no personal data processed on the controller's behalf, and the per-workspace record is metadata about formats, kept like the map. No category of personal data or of data subjects is added, no retention period is longer, no new source, sub-processor, location or transfer basis is used, and no new kind of record survives the deletion of a workspace, so nothing here needs advance notice (DPA clause 6.3(d)). |

Each later entry states the date, whether the change was announced in advance (DPA clause 6.3(d) or 7.7.2) or recorded here only, and what changed.

---

*Generated from app/lib/legal-content.ts — edit the source, then run `node scripts/export-legal.mts` from app/. The HTML page is at https://maplith.com/processing.*