My Work Here Is _ — Workplace Diagnostic
Data Processing Agreement
Version v0.9-draft · draft, not in force
Passages shown [in brackets] are facts fixed when the document is published, and are not yet set. The draft is here so it can be read and challenged before it is used; when it is settled, this page carries the final text, its version and the date it takes effect.
1. Parties, scope and incorporation
1.1 This Data Processing Agreement ("DPA") is between:
[My Work Here Is _ — full legal / trading entity name], [legal form] of [registered or principal business address, Dublin, Ireland], [registration number: _____] ("we", "us", "the Processor")
and the organisation that purchased the Workplace Diagnostic ("you", "the Client", "the Controller").
1.2 This DPA forms part of, and is incorporated into, the Terms & Conditions of Sale ("the Terms") and any written subscription or Enterprise agreement between us. It applies for as long as we process personal data on your behalf.
1.3 Precedence. On any data-protection matter, this DPA prevails over the Terms. On matters this DPA does not address, the Terms apply. A written subscription or Enterprise agreement prevails over both on the commercial matters it addresses, but not on data protection.
1.4 Definitions. "GDPR" means Regulation (EU) 2016/679 and the Irish Data Protection Acts 1988–2018, together with any successor or implementing legislation. "Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in the GDPR. "Diagnostic", "Report", "Commissioner", "Leader", "Employee" and "Wave" have the meanings given in the Terms.
2. Roles and subject-matter
2.1 For the personal data of your leaders and employees processed through the Diagnostic, you are the controller and we are your processor. You decide the purpose — assessing your own workplace — and you determine who is invited.
2.2 We process that personal data only for the purposes set out in Annex 1, and only on your documented instructions (§3).
2.3 Data we control ourselves, which this DPA does not cover. We are the controller, not your processor, in respect of:
- the account and billing data of the individual who purchased — their name, email address and payment details, which we hold to operate our own customer relationship and meet our own legal obligations; and
- the de-identified aggregate results retained for benchmarking and calibration under Terms §7 and Annex A, which are not personal data (§13).
Our handling of that data is described in our own privacy notice, not here. The processors we use for it — the payment processor and the debrief booking tool — are our processors, not sub-processors under this DPA (§6.6).
2.4 The anonymity architecture is part of what you bought. Certain features of the Diagnostic are fixed and cannot be varied by either of us: the five-respondent floor, the severance of employee responses from any identifier, the one-time survey token, and the practitioner's review of every free-text comment before any is quoted (Terms §6).
These are not restrictions we impose on you. They are the specification of the instrument you purchased. An employee who believes their answers can be attributed to them does not answer the question asked: the scores migrate to the acceptable middle and the free text largely disappears. The anonymity guarantee is what makes the measurement valid, and therefore what makes the Report worth having — in our own methodology it is an anti-bias control before it is anything else. In that respect it is like the blinding of a double-blind study — a specification of the method, which the party commissioning it cannot lift without destroying the result they commissioned.
We therefore determine these features as a means of achieving the purpose you set, and this DPA treats the practitioner's review as processing on your instructions.
2.5 Annex 1 sets out the subject-matter, duration, nature and purpose of the processing, the types of personal data, and the categories of data subject, as required by Article 28(3).
3. Your instructions
3.1 We process personal data only on your documented instructions, including as to international transfers, unless required to do otherwise by law — in which case we will tell you before processing, unless the law prohibits that on important grounds of public interest.
3.2 Your documented instructions comprise: this DPA, the Terms, any written subscription or Enterprise agreement, and the configuration choices you make in the commissioner hub — who you invite, which tiers and features you enable, when you open and close survey windows, and whether segmented reporting (Terms §6a) is in use.
3.3 We will tell you if, in our opinion, an instruction infringes the GDPR. We may suspend the affected processing until it is resolved.
3.4 What we cannot do, whatever you instruct. The following are outside the scope of any instruction you can give — not because we decline, but because the product is built so that they are not possible, and because doing them would invalidate the measurement you commissioned (§2.4):
- We will not disclose an individual employee's responses to you, or to anyone. We cannot — no retained link exists between an employee and their answers (Annex 1 §5, Annex 2 §2).
- We will not disclose employee results below the anonymity floor, or defeat the segment suppression rules, at your request or ours.
- We will not re-identify, or attempt to re-identify, an anonymous respondent.
3.5 You warrant that you have a lawful basis for the processing you instruct, and you are responsible for the lawfulness of the personal data you supply to us.
3.5a You will invite to the employee survey only your own people within the scope you set, one address per person, and will not invite addresses you control, share or hold on someone else's behalf. The anonymity floor (Annex 2 §3) assumes the people in a group are separate individuals independent of you; it cannot protect a respondent whose group you have filled with addresses you can answer from.
3.6 Transparency — we deliver the participant notice on your behalf. Your Article 13 obligation to inform your leaders and employees remains yours, but the delivery mechanism is ours: every participant we invite receives a link to the notice in their invitation and is shown it on the survey page before they answer. We do this because the participant's first contact with the processing is our email, and a notice that depends on internal distribution may never reach them.
You warrant that the information you give us for that notice is accurate, and that the notice reflects your processing. Where the notice requires a detail only you hold — your data-protection contact, and the lawful basis you rely on — it identifies you as controller and directs participants to you until you supply it; it is to that extent not a complete Article 13 notice, and you remain responsible for anything further your own processing requires. The served text is the notice linked from every invitation we send and shown on the survey page itself before anyone answers; we will provide the current wording on request.
4. Confidentiality
4.1 We ensure that every person authorised to process personal data under this DPA — employees, practitioners, and contractors — is bound by an appropriate contractual obligation of confidentiality or is under a statutory obligation of confidentiality, and is trained on their obligations.
4.2 Access is limited to those who need it for the purposes in Annex 1, and is enforced technically as well as contractually (Annex 2 §2).
5. Security
5.1 We implement and maintain the technical and organisational measures set out in Annex 2, taking account of the state of the art, the costs of implementation, and the nature, scope, context and purposes of the processing, as required by Article 32.
5.2 The measures in Annex 2 are not merely policy commitments. The central ones are properties of the database and are verified by an automated test suite that blocks release if it fails (Annex 2 §7). We will provide evidence of that on request under §10.
5.3 We may update the measures in Annex 2 provided the level of security is not reduced.
6. Sub-processors
6.1 General authorisation. You give us general authorisation to engage sub-processors, subject to this §6.
6.2 Current sub-processors are listed in Annex 3.
6.3 Changes. We will give you at least [30] days' written notice before adding or replacing a sub-processor. You may object on reasonable data-protection grounds within that period. If we cannot resolve your objection, you may terminate the affected part of the Diagnostic; we will refund fees for anything not yet delivered.
6.4 We impose on every sub-processor, by written contract, data-protection obligations no less protective than those in this DPA, and we remain fully liable to you for a sub-processor's performance.
6.5 The boundary. There is exactly one sub-processor with any access to employee personal data, and it is EU-resident. This is a deliberate design property, not a current coincidence (Annex 3 §1).
6.6 Not sub-processors. The payment processor and the debrief booking tool process only the account and billing data we control under §2.3. They never receive employee personal data, survey responses, or report content. They are listed in Annex 3 §3 for transparency, not because this DPA governs them.
7. Data subject rights
7.1 Taking into account the nature of the processing, we assist you by appropriate technical and organisational measures, insofar as possible, to respond to requests to exercise data-subject rights under Chapter III of the GDPR.
7.2 If a data subject contacts us directly. We publish a contact address to respondents in the notice we serve on your behalf (§3.6), so requests will reach us as well as you. We will:
- acknowledge the request directly and without undue delay, rather than leaving it unanswered;
- tell them, at the level of the categories in §7.3, what can and cannot be done — including, where it applies, that no individual response can be retrieved by us, by you, or by anyone. This describes how the system is built, not the requester's personal data, and is not a substantive response to their request;
- notify you promptly, with what we hold that is capable of relating to them, so that you can decide as controller; and
- act on your instruction — within one calendar month of our receipt of the request, or such other period as you direct — on the data we hold as processor.
We will not decide the request, and we will not disclose response-level data — none exists to disclose. Referring the requester to you is the route for the decision; it is not, by itself, the answer, because on the two categories capable of being acted on (the invitation address and a free-text comment) we are the only party holding them.
7.3 What we can honour, and what we cannot — stated plainly. This is a real limitation of the design and is disclosed rather than discovered:
| Data | Access / rectification / erasure |
|---|---|
| Leader name, email, responses | Can be honoured individually. The data is named and attributed by design |
| Employee invitation email address | Can be honoured while it exists — on your instruction, and also on the data subject's own request made directly to us, which we act on without waiting for you. We hold a per-address erasure path built for exactly this. The address is replaced, not the record deleted, so your response and coverage counts are unaffected by an erasure. It is removed automatically at survey window close in any event (Annex 1 §4 — on a Continuous engagement, at the closing message or ninety days after close, whichever is first), so a request arriving after that has nothing to act on, and most will. Removal does not withdraw a survey link already issued — the link does not contain the address — but the person will receive no further reminder |
| Employee free-text comment | Can be honoured only if the data subject can identify it to us by quoting it — the comment carries no identifier of any kind, so their own words are the only means of finding it. We cannot verify that the quoted words are theirs. Where we cannot verify, we will act rather than refuse. We hold a per-comment erasure path built for exactly this, and it removes both the original and the copy held for the Report, so a comment erased on request stops appearing in the Report from that point. It cannot recall a Report already delivered to you. Comments exist for ninety days from the first Report (Annex 1 §4), so a request arriving after that has nothing to act on, and we will say so plainly |
| "Do not invite me again" | Yours, not ours, and we say so rather than appear to refuse. We could only suppress future invitations by retaining the person's address indefinitely — the opposite of the minimisation the rest of this table describes. You build the invitation list, so exclusion is exercised there |
| Employee scored answers | Cannot be honoured individually, and this is structural. No identifier exists to search, delete or correct by. There is no retained link between a person and their answers — which is the promise the product makes to the employee and the reason the data is anonymous. Erasure is possible only at the level of the whole diagnostic |
7.4 We will make the limitation in §7.3 clear to you, and it is disclosed in the employee-facing privacy notice. It is a consequence of the anonymity guarantee, not a refusal to assist: the same property that prevents us identifying a respondent for you (§3.4) prevents us identifying them for themselves. It applies to you exactly as it applies to us — on the scored answers you are not better placed than we are, and a request you forward to us cannot be answered at response level either. We would rather a requester were told that plainly than be passed between us.
7.5 Where erasure is requested and can only be honoured at diagnostic level, we will discuss the consequences with you before acting — deleting a diagnostic deletes it for everyone in it.
8. Personal data breaches
8.1 We notify you without undue delay and in any event within [24] hours of becoming aware of a personal data breach affecting personal data processed on your behalf.
8.2 Our notification will describe, to the extent known: the nature of the breach, the categories and approximate number of data subjects and records affected, the likely consequences, the measures taken or proposed, and a contact point for further information. We will supplement it as more becomes known.
8.3 We assist you in meeting your obligations under Articles 33 and 34, including by providing the information you reasonably need to notify a supervisory authority or affected data subjects.
8.4 We will not make any public statement or notify a supervisory authority about a breach affecting your data without consulting you first, unless we are legally required to.
9. DPIAs and prior consultation
We provide reasonable assistance with your data protection impact assessments and any prior consultation with a supervisory authority, taking into account the nature of the processing and the information available to us. To that end we maintain and will share on request: the description of the processing in Annex 1, our Article 30 record of processing, the measures in Annex 2, and the evidence pack recording how the anonymity controls are tested.
10. Information and audit
10.1 We make available to you the information necessary to demonstrate compliance with Article 28 and this DPA.
10.2 We will respond to a reasonable written information request within [30] days. In the first instance we will provide our own documentation — the security specification, the processing description, and the results of the automated verification in Annex 2 §7.
10.3 Where that is not sufficient, you may conduct an audit or inspection, on [30] days' written notice, not more than once in any 12-month period (unless required by a supervisory authority or following a personal data breach), during business hours, without unreasonable disruption, and subject to confidentiality. You bear your own costs and, where an audit requires significant effort on our part, our reasonable costs.
10.4 An audit may not extend to anything that would require us to disclose another client's data, or to defeat the anonymity controls in Annex 2.
11. International transfers
11.1 We do not transfer personal data processed on your behalf outside the European Economic Area. All processing under this DPA — hosting, database, backups, email — takes place in France (Annex 3 §2).
11.2 We will not begin any such transfer without your prior written instruction and an appropriate Article 46 transfer mechanism.
11.3 For completeness: our own processing of account and billing data under §2.3 involves a transfer to the United States by the payment processor, under its own transfer safeguards. That is outside this DPA and is described in our own privacy notice.
12. Deletion and return
12.1 Personal data is deleted during the engagement, not only at the end of it, on the schedule in Annex 1 §4 — employee invitation addresses at survey window close, and employee free-text comments when the Report is released. Those deletions are automatic and are not waivable by either of us.
12.2 At the end of our provision of services, we will, at your choice, delete or return the personal data processed on your behalf, and delete existing copies, unless we are required by law to retain it.
12.3 Your choice must be exercised within [30] days of the end of the engagement. Absent a choice, we retain the data for the period stated in Terms §5b and then delete it.
12.4 Backups — the honest limitation. Deleted data may persist in database backups until those backups age out on their normal rotation, currently 7 days. Those automated backups are logical exports and are not encrypted at rest — see Annex 2 §5, which states the position in full. Backups are not restored except for disaster recovery, and any data restored is re-deleted. We do not regard the engagement's data as fully deleted until that window has passed.
12.5 §12.2 does not apply to the de-identified aggregate data retained under §13, which is not personal data and is governed by Terms §7.
13. Anonymous data and the benchmark
13.1 The Diagnostic produces anonymous, aggregate results — data relating to no identified or identifiable person. We retain those results and pool them with other clients' for benchmarking and calibration, as set out in Terms §7 and Annex A, and we do so as controller of that data, not as your processor.
13.2 This is not a route around this DPA. The retained record contains no organisation name, no individual's identity, no email address, no free-text comment and no individual response; employee figures enter only as aggregates above the anonymity floor, and a result withheld from your Report is not retained either (Terms Annex A §2). The record carries an internal reference to the engagement, disclosed in Terms §7, which is what makes withdrawal possible.
13.3 Your right to withdraw your organisation's contribution at any time is in Terms §7 and is unaffected by this DPA.
13.4
14. Liability
14.1 Each party's liability under this DPA is subject to the limitations and exclusions in the Terms, except where those limitations cannot lawfully be applied to liability arising under the GDPR.
14.2 Nothing in this DPA limits either party's liability to a data subject or a supervisory authority, or affects the allocation of liability under Article 82.
15. Term, and general
15.1 This DPA takes effect when you accept the Terms and continues for as long as we process personal data on your behalf, and thereafter for any obligation that by its nature survives — including §4 (confidentiality), §10 (audit, for 12 months), §12 (deletion) and §14 (liability).
15.2 We may update this DPA where necessary to reflect a change in law, a supervisory authority's guidance, or a change in the processing, provided the protection afforded to data subjects is not reduced. We will notify you of any material change.
15.3 This DPA is governed by the laws of Ireland, and the courts of Ireland have exclusive jurisdiction. Our lead supervisory authority is the Irish Data Protection Commission.
15.4 Contact for data-protection matters:
Liam Muldowney, Founder hello@myworkhereis.com [postal address, Dublin, Ireland]
Annex 1Details of the processing
(Article 28(3). The same facts, stated for a supervisory authority rather than for you, are in our Article 30(2) record of processing. The two are kept in sync; neither may be silently more accurate than the other.)
1. Subject-matter and duration
Subject-matter. Provision of the My_Alt Workplace Diagnostic: a two-stage assessment of how the Client's organisation operates against how its workplace was built to support it, delivered as a scored gap-analysis Report and a live debrief.
Duration. For the duration of the engagement, and thereafter as set out in §4 below and Terms §5b. On a Continuous subscription, for the duration of the subscription across successive Waves.
2. Nature and purpose of the processing
| Purpose | What is processed |
|---|---|
| Inviting participants | Sending survey invitations and reminders to the leader and employee email addresses the Client supplies |
| Collecting responses | Receiving leader survey responses (attributed) and employee survey responses (anonymous), and employee free-text comments (severed from responses) |
| Scoring | Computing aggregate results. Automated, and about the organisation and groups within it — never about an identified individual. No employee is scored, ranked or profiled individually |
| Practitioner review | Reviewing free-text comments before any is quoted, removing identifying content or withholding the comment; preparing and approving the Report |
| Delivering the Report | Making the Report available to the Client in the commissioner hub and as a PDF, generated within our own application |
| Segmented reporting (only where the Client defines reporting units) | Grouping employee responses into Client-defined reporting units, from the employee's own optional selection — which the Client may pre-fill with a suggestion the employee keeps, changes or declines — and applying the suppression and combination rules in Terms §6a |
| The closure message (Continuous subscriptions only) | Sending one practitioner-drafted, Client-approved message to everyone invited |
| Support and administration | Operating accounts, resolving support issues, and maintaining the service |
Not a purpose of this processing: marketing to your leaders or employees; profiling any individual; training any machine-learning or generative AI system. No AI or machine-learning service is used in the Diagnostic (Terms §5a).
3. Categories of data subject
- Commissioners — the individual purchasing and administering the Diagnostic (note: their account and billing data is under our own controllership — §2.3 of the DPA. They appear here where they also participate as a leader)
- Leaders — members of the Client's leadership group invited to the leader survey (up to 12)
- Employees — members of the Client's workforce invited to the employee survey (up to 50 or 250 by tier)
4. Types of personal data, and retention
| Personal data | Whose | Retention |
|---|---|---|
| Name, email address, job title | Leader | Retained with the Report for seven years after the engagement ends (Terms §5b) |
| Survey responses and notes, attributed | Leader | Retained with the Report for seven years after the engagement ends (Terms §5b) |
| Email address, for invitation and reminders only | Employee | Deleted when the survey window closes. Never linked to any response. Continuous subscriptions only: where the closure message applies, retained solely to send it, and deleted once it has been delivered — at the latest 72 hours after it is sent — or 90 days after window close if it is not sent, whichever is first (the period after sending exists only to re-send a message a mail server refused) — enforced in the system, capped, and verifiable in its compliance checks |
| Free-text comment | Employee | Deleted within ninety days of the first Report, and sooner where the practitioner has cleared them. Held for that period solely so a revised Report can be corrected against the original wording. Measured from the first Report; a reissue does not extend it. The practitioner's review decisions, and any comment approved for quotation, survive by design |
| Reporting-unit tag (segmented reporting only) | Employee | Held with the anonymous response; carries no identifier. The selection is optional, declining is always available, and the employee's answer governs over any Client suggestion |
| Name and email address | Commissioner | Under our own controllership — §2.3 |
| A note to the practitioner on a context-intake event | Any individual the Commissioner chooses to mention in it — most likely a leader (for example, a senior leadership change) | Retained with the context intake for seven years after the engagement ends, as the Report is. Seen only by the practitioner; never shown in the Report, never quoted, and never included in the benchmark. It may carry business information the Client has asked us to keep from its own leaders; we treat it as confidential under §4 |
No special categories of personal data (Article 9) are requested or required by the Diagnostic. The Client must not supply them, and the employee free-text field carries a notice not to include information identifying anyone.
5. The anonymity of employee scored answers
Employee scored answers are stored with no identifying information and no retained link to the respondent. The invitation token is one-time, consumed at submission, and stored only as a hash; no foreign key survives it. The free-text comment is severed from the scored answers with no key joining them.
Consequently: no individual employee's responses can be produced — by the Client, by us, by a practitioner, or in response to a legal demand. This is the basis on which those answers are treated as anonymous and outside the scope of this DPA, and it is the reason for the limitation in §7.3.
Employee results are released only in aggregate, subject to a minimum group-size floor of five respondents, enforced in the database.
We state the status of that characterisation rather than assert the conclusion. It is our determination, reached by documented assessment against the design described above and recorded in writing. It has not been confirmed by an independent data-protection specialist, and no such review is planned — we say so plainly rather than leave a confirmation implied. If we later conclude, or are advised, that the scored answers are pseudonymous rather than anonymous, those answers fall within the scope of this DPA, and we will issue an updated version under §15.2 — the description of the processing in Annex 1 §2, the retention entry in Annex 1 §4 and the limitation in §7.3 would each change accordingly.
What would not change is how the data is held. The severance of response from respondent, the one-time token, and the aggregate floor described above are properties of the system rather than of the label put on it, and they apply either way.
Annex 2Technical and organisational measures
(Articles 28(3)(c) and 32. Drawn from our internal security specification; that document is the fuller statement and this annex the contractual one.)
1. Data residency
All personal data — application, database, backups and email — is hosted on EU-sovereign infrastructure in France. No personal data processed under this DPA leaves the EEA.
2. Access control — the anonymity backbone
Access is separated at the database level, not in application code. The data is divided into severed schemas and each is reachable only by a role that cannot read the others:
| Role | Reads | Cannot read |
|---|---|---|
| Application | Named data; employee scores only through aggregate views that enforce the five-respondent floor | Raw employee answers; any free-text comment |
| Scoring engine | Raw employee answers (which carry no identity); named data | Any free-text comment |
| Free-text review | Free-text comments only (which carry no identity) | Employee scored answers; identifiers |
| Benchmark reader | De-identified pooled data only | Every other world |
| Migration | Schema changes only | Not used to serve requests |
Two invariants follow, and they are the ones that matter:
- No single role can read both an employee's scored answer and any identifier.
- No single role can read both a scored answer and a free-text comment, and no key joins them — so a comment can never be used to identify someone and then read their scores.
One limit, stated rather than left to be found. The database records which transaction wrote each row, and one employee's response, comment and used invitation are written by the same one. Someone holding the database itself (not an application role used as designed) could therefore have joined them by that record. We remove it: each employee's rows are rewritten, in random order, every hour while the survey is open and once more when it closes, so the record no longer distinguishes one person's rows from another's. For up to an hour after a response is submitted, and for anyone watching the database live as rows are written, the link exists; after the survey closes, it does not.
Row-level security additionally confines each Client's data to that Client, and each practitioner to the engagements assigned to them.
3. The suppression floor
The five-respondent floor is implemented in the database view definitions and in the scoring engine, not in the user interface. A below-floor group produces no row — there is nothing for a bug in a screen to leak. Where segmented reporting is enabled, a further anti-differencing rule withholds a group that would otherwise let a smaller group's result be derived by subtraction.
What the floor assumes. Five respondents protect each other only if they are five separate people. The Client chooses who is invited, so a group could be filled with addresses the Client controls, and the remaining respondent's answers worked out by subtraction. No technical control can rule that out, because the invitation list is legitimately the Client's. What we do: addresses that reach the same mailbox (name+tag@) count as one person; the practitioner is shown, as counts only, how many invited addresses were outside the Client's main email domain or on personal-mail services; and the Client undertakes in §3.5a not to do it.
4. Authentication
| Population | Method |
|---|---|
| Practitioner | Email, password and mandatory two-factor authentication (TOTP). Five failed attempts for one address within fifteen minutes refuse further attempts until they age out, and each authenticator code is accepted once |
| Administrative operator | Three-factor authentication, with the same attempt limit and single-use codes; a separate principal from any practitioner |
| Commissioner | Single-use magic link by email, then a session cookie |
| Leader | Tokenised link, valid for the survey window only |
| Employee | One-time anonymous token, consumed at submission, carrying no identity |
All tokens are stored as hashes only; the raw token exists solely in the email. A database leak cannot reissue or impersonate a link. Sessions are HttpOnly, Secure and SameSite cookies, held server-side as hashes. Practitioner and operator sessions last twelve hours and end at once when the account is deactivated. Commissioner sessions last up to thirty days, can be signed out from the hub on one device or all, and are closed by us, together with any sign-in link not yet opened, when access is withdrawn.
5. Transmission and storage
Encryption in transit throughout (HTTPS with HSTS; CA-verified TLS to the database over a private network). Encryption at rest for the database volume — enabled 2026-08-18, AES-XTS-plain64 with a 512-bit key, managed by the infrastructure provider — covering all databases, data including logs, and volume snapshots. Automated backups are logical exports and are not encrypted at rest; the provider does not currently offer encryption for them. Secrets are held server-side only, in a dedicated secrets store, never in client-side code. Security headers and a content security policy are applied; respondent-facing pages carry no third-party scripts and fonts are self-hosted.
6. Deletion
Employee invitation addresses are deleted inline, in the same operation that closes the survey window, so that purge cannot be missed by a job that failed to run. Free-text comments are kept for up to ninety days from the first Report (Annex 1 §4) and then deleted by the practitioner or by a sweep that runs daily, at start-up and whenever the comments are opened, whichever comes first. The closure-message variant is likewise enforced by a periodic sweep. Both are verified by an in-product compliance check. Backups age out on a 7-day rotation (§12.4).
7. Verification — how these measures are tested
The measures in §2, §3 and §6 are not assertions. They are asserted by an automated test suite that runs against a real database on every change and blocks release if it fails, including a dedicated anonymity suite that attempts, as each role in turn, the reads that must be denied — and fails the build if any of them succeeds. Results are available to you under §10.
8. Organisational measures
Confidentiality obligations on all personnel (§4); least-privilege access; separation of the administrative operator from the practitioner principal; change control through version-controlled migrations and reviewed releases; an operations handbook governing production access and incident response; and no production database access from personal devices except through the documented administrative path.
Annex 3Sub-processors
(Article 28(2) and (3)(d). This annex is the contractual sub-processor list. We maintain it, and any change to it is notified to you under §6.3.)
1. The boundary
There is exactly one sub-processor with access to employee personal data, and it is EU-resident. The Report PDF is rendered inside our own application, email is sent by the same vendor that hosts the database, and no analytics, tag manager, session-recording tool or third-party font service runs on any respondent-facing page.
2. Sub-processors under this DPA
| Sub-processor | Service | Personal data | Location | Transfer |
|---|---|---|---|---|
| Scaleway [confirm legal entity] | Application hosting, managed PostgreSQL and backups, transactional email, platform logging, image registry | All personal data processed under this DPA | France | None — EU-resident |
3. Not sub-processors under this DPA
Listed for transparency. These process the account and billing data we control under §2.3, and never employee personal data, survey responses or Report content:
| Provider | Service | Data | Location |
|---|---|---|---|
| Stripe [confirm entities] | Hosted checkout and payment processing | Purchaser name, email, billing and card data (card data handled entirely by Stripe) | Ireland / USA |
| Brevo [confirm legal entity] | Brevo Meetings — booking the debrief | Commissioner or designated leader name, email, scheduling data | France |
4. Not processors of personal data at all
Our secrets store and our source-control and build system hold configuration secrets and application code respectively, and process no personal data.
This agreement sits under the Terms & Conditions of Sale, which govern the purchase itself.