Team memory: data protection impact assessment (DPIA) template

DRAFT. NOT LEGAL ADVICE. This template describes how the AUGMTD team memory feature works so that your organisation can carry out its own assessment. It is not a completed DPIA and it does not state that any use of the feature is lawful or compliant. Review it with your data protection officer or legal adviser, and with your works council where you have one, before you turn team memory on.

Fill in every section marked [to complete]. The descriptions of the feature are ours; the assessment is yours.

1. Who is assessing

2. Description of the processing

2.1 What team memory does

When two or more colleagues in your workspace work on the same piece of work (a client, project, matter, deal, hire, supplier or internal initiative), team memory shows each of them where that work stands across the team: open promises, next steps, when it was last touched, and meeting titles. Each person keeps their own account; team memory does not copy anyone's mailbox, calendar or files into anyone else's.

2.2 How your organisation chooses the sharing mode

An owner or admin of the workspace turns team memory on and chooses one of two modes. The choice (who, when, which mode) is recorded.

Mode chosen by your organisation: [to complete]. Reason for that choice: [to complete].

2.3 Data categories shown to colleagues (state only)

Colleagues who are members of the same shared work see only the following, about that work:

• Promise text: the one-line description of an open promise (who owes it, to or from which outside party), and its status.
• Due dates of those promises.
• Next-step titles: the short title of the next step on the work.
• Touch type and date: that there was an email or a meeting, and when (for example "Email, Tue"), with which colleague it was.
• Meeting titles and their start and end times.
• Names of the colleagues who are members of the shared work.

2.4 Data that is never shown to colleagues

• Email bodies, email subjects and attachments.
• Meeting transcripts, notes and recordings.
• Files and documents.
• The source quotes a promise was found in.

A line that repeats the subject of one of the owner's emails is withheld rather than shown.

2.5 Data subjects

• Your employees and other workspace members (whose work state is shown to colleagues).
• Outside parties named in promise text, counterparty names or meeting titles (clients, suppliers, candidates).

2.6 Where the data is processed

Team memory reads data that is already held in each member's own AUGMTD account; it adds no new copy. Hosting and the AI processing tier follow your workspace's tier: [to complete: your tier, for example EU hosting, and the sub-processor list that applies to it].

3. Purposes

[to complete, in your own words.] Typical purposes customers state:

• Colleagues on the same client or project see what has been promised and what is due, so promises are not missed.
• Hand-overs (holiday, illness, a change of role) do not lose open work.
• Fewer internal status emails and meetings.

Purposes team memory is not designed for, and which you should state you will not pursue: measuring, rating or ranking individual employees; monitoring working time or activity; disciplinary evidence.

4. Necessity and proportionality

[to complete.] Questions to answer:

• Could the purposes be met with less data? (Team memory shows state only: see 2.3 and 2.4.)
• Which mode is proportionate for your organisation, and why? ("Each person chooses" relies on each person's own action; "Shared by default" relies on a clear notice and each person's own off switch.)
• What is your lawful basis for each data subject group? [to complete with your adviser]
• How are staff informed? (See the staff and works council notice provided with this template.)
• How long is the data kept? Team memory holds no copy: the state is read from each member's own account at the moment it is shown, and stops showing when the member hides the work, switches sharing off, leaves, or is removed.

5. Risks to the people concerned

Assess each risk for likelihood and severity in your context. [to complete]

6. Mitigations built into the feature

These describe how the product behaves. Whether they are sufficient for your organisation is part of your assessment.

• No per-person metrics. Team memory shows the work, not the worker: nothing counts, rates or ranks individual members (our internal rule "the work, not the worker").
• Aggregate floor for process patterns. Where patterns across a company process are shown, they appear only once there are at least 5 runs from at least 3 members.
• Each member's own controls. Every member can hide any piece of work from the team, switch sharing off for all of their work, unlink their work, or leave a shared record, at any time. These controls work even if billing has lapsed or team memory has been turned off.
• Staff informed before turn-on. Team memory is turned on only after an owner or admin confirms the staff (and the works council, where there is one) were told; sharing then starts for every member at once. Each member is also shown a short notice in the app, for information; it does not hold sharing back. Turning team memory off and on again, or switching from "Each person chooses" to "Shared by default", shows the notice again.
• An admin cannot opt anyone in. No admin, owner or support path switches a member's sharing on, unhides their work, or links their work. Admins are not readers by rank: an admin sees a shared record only if they are a member of it themselves.
• Strong evidence for automatic joins. In "Shared by default", a member's work joins a shared record without a click only on strong evidence (the same external domain, email thread, calendar series or process case). A name-only match is only ever a suggestion the member confirms. In "Each person chooses", nothing joins automatically for a member who has not switched sharing on.
• Hosting and AI tier follow your workspace's tier (see 2.6).

Additional organisational measures you will take: [to complete]

7. Residual risk

[to complete: the risk that remains after the mitigations, and whether it is acceptable. If a high residual risk remains, consider whether prior consultation with your supervisory authority is required.]

8. Sign-off