Data Processing Agreement.

Preamble

This Data Processing Agreement (DPA) is the "Data Processing Agreement" defined in the Terms of Service published at chat.org.uk/terms.html, and forms part of those Terms. Order of precedence, per the Terms: the Order Form (commercial matters), then this DPA (matters relating to personal data), then the Terms (everything else).

Published documents referred to. The Privacy Notice, the Terms of Service, the Sub-processors list, the Price list, the Accessibility statement and this DPA are each published at chat.org.uk as Version 1.0, effective 6 September 2026, and are cited here by those identifiers. Annex C to this DPA reproduces the Sub-processors page as at the date of signature of the Order Form, and the Customer's general authorisation in clause 7.1 attaches to the list as so reproduced.

Parties

• Processor: CIaaS Limited, company number 14519311, registered office C/O Aardvark Accounting, 1 Cedar Office Park, Cobham Road, Wimborne BH21 7SB. ICO registration ZC181640. Contact: compliance@chat.org.uk. Trading as ComplyChat ("ComplyChat", "we", "us").
• Controller: the customer organisation named on the Order Form ("Customer", "you").

Scope and roles

1.1 You are the controller of personal data flowing through your Governed Channels – wherever a conversation comes from, whether our own secure web space or Microsoft Teams – and stored in the record on your behalf. You decide who joins, what is discussed, how long it is kept, and who is told.

1.2 We are your processor for that data and act strictly on your documented instructions. The lasting governed record rests in your own Microsoft 365 tenant, per organisation and never pooled, and we never become your system of record for it. Clause 1.5 states, separately and in full, what we do hold to run the live service, because the two copies are different and the difference matters.

1.3 We are a separate, independent controller for our own business data (site visitors, enquiries, account administrators' contact details, billing) as described in our Privacy Notice; that processing is outside this DPA.

1.4 This DPA lasts as long as the Agreement, plus the wind-down period in clause 11.

1.5 Processor in the path, and the shared operational store.

For Governed Channels, ComplyChat acts as a processor in the path for message content. Content transits ComplyChat-operated Microsoft Azure in the UK South region (the channel service and Azure SignalR Service) in flight, and a working copy of message content is held in the operational store to run the live channel and its scrollback.

That operational store is a single Azure SQL database and a single media container in UK South, shared across customer organisations. Every organisation-scoped row carries the identifier of the organisation it belongs to, and isolation between organisations is enforced logically, by row-level security in the database engine, rather than physically: the database engine itself refuses to return or write another organisation's rows, whatever the application above it asks for. Objects in the media container are reached through the application, which resolves each one through an organisation-bound row, or, for a call recording sent for transcription, by a short-lived read-only signed link the application mints for Azure Speech in UK South. On the Enterprise tier the database working copy is held in a dedicated database instead (clause 6.2, Model C).

The system of record at rest remains the Customer's own Microsoft 365 tenant, where the governed record is held per organisation and never pooled, and to which the working copy is never a substitute.

The technical attestation behind the second paragraph is in Annex B, Part 3.

Your instructions

2.1 Our complete instructions are: capture Governed Channel conversations; deliver them into your own Microsoft 365 record; operate the live channels, relays, calls and notifications that make that possible, including holding the working copy described in clause 1.5 for the retention model recorded on the Order Form (clause 6.2); and make the record answerable (retention, search and export run in your tenant with your tools). Additional instructions require written agreement.

2.2 We will tell you without undue delay if, in our opinion, an instruction infringes UK GDPR or other UK data-protection law.

2.3 We do not mine, profile, sell, use for advertising, or use to train machine-learning models any personal data processed under this DPA, and we use it for no purpose beyond providing the contracted service. The machine transcription and AI-written summary of recorded calls (Annex A) are produced for you, by Microsoft services in the UK South region, and are not used to train any model.

Lawful basis and special category data (your determinations)

3.1 You are responsible for identifying and recording the Article 6 lawful basis for each Governed Channel and – where conversations include special category data, which is routine in care, school and charity settings (health, ethnicity, religious belief, sexual orientation, safeguarding concerns) – the Article 9 condition, typically a substantial-public-interest condition in Schedule 1 of the Data Protection Act 2018 relating to safeguarding, health or social care, or the protection of vulnerable adults, together with the appropriate policy document that Schedule 1 paragraph 5 requires.

3.2 Your recorded determination (complete at signature).

Worked examples, by sector, drawn from the trustee pack overlays. They are illustrations to help your DPO complete the grid; they are not our determination of your lawful basis, which is yours to record.

• Registered charity (care or community service). Staff channels: legitimate interests (Art. 6(1)(f)) for workplace record-keeping. Family and participant channels: legitimate interests, or public task (6(1)(e)) where the service is delivered under a statutory contract. Article 9: Schedule 1 Part 2 paragraph 18 (safeguarding of children and individuals at risk) where the channel supports safeguarding; Part 1 paragraph 2 (health or social care purposes) where care is delivered. Appropriate policy document: required for a Part 2 condition; the template in the trustee pack.
• Multi-academy trust. Staff channels: public task (6(1)(e)), the trust being a public authority for these purposes. Parent and pupil channels: public task, under the trust's statutory functions. Article 9: Schedule 1 Part 2 paragraph 18 (safeguarding), with paragraph 6 (statutory and government purposes) available for the trust's legal duties. Appropriate policy document: required.
• Maintained school (governing board). As for a multi-academy trust, with the governing board and the local authority sharing controller responsibilities per the school's own arrangements; record which entity is the controller for the channel.
• Council (cabinet or committee under the scheme of delegation). Staff channels: public task. Resident and service-user channels: public task under the council's statutory functions (Care Act 2014, Children Act 1989 and 2004, Housing Act 1996 as applicable). Article 9: Schedule 1 Part 2 paragraph 6 (statutory purposes) and paragraph 18 (safeguarding); Part 1 paragraph 2 for adult social care. Appropriate policy document: required and normally already held.
• Care provider (CQC-registered). Staff channels: legitimate interests, or contract where the channel is a term of employment. Resident and family channels: legitimate interests, or public task where the placement is local-authority funded. Article 9: Schedule 1 Part 1 paragraph 2 (health or social care purposes) is the natural route; paragraph 18 for safeguarding. Appropriate policy document: required for paragraph 18; recommended in any event.

3.3 Where a channel involves children under 18, you are responsible for the fairness and transparency measures that apply; our participant-notice copy and DPIA template are available to help.

Details of processing (Annex A summary)

• Subject matter: governed workplace and participant messaging and recorded calls, captured into your Microsoft 365 record, with a working copy held to run the live service (clause 1.5).
• Duration: the term of the Agreement plus the wind-down in clause 11.
• Data subjects: participants – staff, volunteers, family members, residents, pupils and parents, clients and others you admit to a channel; may include children under 18.
• Categories: participant identifiers (phone number verified by SMS, Microsoft 365 identity, or name and contact details); message content (text, images, voice notes, documents, polls, tasks, acknowledgements, location pins and other attachments); recorded voice and video calls with a machine transcript and an AI-written working summary, where you switch calls on for a channel or allow your own people to call one another; message metadata (timestamps, sender identity, delivery and read receipts, membership changes); administrative records (which staff member added or removed which participant, when, on whose authority).
• Special categories: as determined by you under clause 3.

Confidentiality

Persons we authorise to process the data are bound by contractual or statutory confidentiality obligations, on least-privilege access, with every human access to your content written to the transparency feed described in clause 9.4 and Annex D.

Security, retention of the working copy, and continuity (Annex B)

6.1 Technical and organisational measures. UK-region processing (Azure UK South); encryption in transit (TLS 1.2+); AES-256 encryption of the working copy at rest (the archive itself rests in your Microsoft 365 tenant under your encryption and access controls, including Microsoft 365 Customer Key where you run it); role-based access control with least-privilege defaults; comprehensive audit logging; multi-factor authentication on administrator and production access, with hardware-key requirements for production access; separation of duties between development and operations; regular vulnerability scanning; and an incident response plan with defined RTO and RPO targets that we make available to customers under NDA (clause 6.4). Our programme is designed to ISO/IEC 27001:2022 and we are pursuing certification under that standard and Cyber Essentials; we do not claim certification until held.

6.2 Retention of the working copy. Three models exist. The one in force for you is recorded on the Order Form and may be changed by your administrator in the client portal, with every change written to your transparency feed.

• Model A (default). We hold a working copy of message content for the life of the subscription, so that in-app history reaches back to the start. This is the default and it is what applies unless you opt into Model B or take the Enterprise tier's Model C.
• Model B (your purge window). Your administrator sets an organisation-wide working-copy window in the client portal (30 days, 90 days, six months, one, two or three years, or a custom number of days), with a per-channel window available beneath it. Nothing is purged until the message has been confirmed filed into your Microsoft 365 and its window has passed; then the message body is nulled, the media object is deleted and its pointer nulled, and the structured content of polls and events is cleared. The row is retained so that the record of filing survives. The archive in your tenant is never touched.
• Model C (dedicated, Enterprise only). On the Enterprise tier your working copy is held in a dedicated Azure SQL database of its own, in UK South, in a managed resource group: either in our Azure subscription, or in an Azure subscription we manage for you as an indirect reseller, as the Order Form records. The database working copy does not sit in the shared database described in clause 1.5; media objects (attachments and call recordings awaiting filing) continue to be held in the shared media container described in that clause, isolated in the same way. Every other property of this DPA – the record resting in your own tenant, the transparency feed, the access doors in Annex D – is unchanged. Model A or Model B retention applies within the dedicated database as you choose.

Under any model the working copy is deleted at termination on the schedule in clause 11.

6.3 Who at ComplyChat can read your content, and through which door. Annex D states this in full. In summary: an operator can render full message content for any organisation through the operator console's Replay view; each such access is written to your transparency feed as an operator_access event and, where written, sends a real-time alert to the recipients you have set (the write is attempted on every access; a failure to write it is logged on our side rather than blocking the view); direct database access by a human is sanctioned only through the break-glass procedure, which writes a break_glass event and alerts your recipients before the connection is handed over, and refuses to proceed if the event cannot be recorded. Microsoft Entra-only authentication is enforced on the database server, so every connection is a named Entra identity; row-level security runs in enforcing mode on every policy group, so a database principal that is not mapped to an organisation is denied by the engine; our operators' identities are unmapped by default, and the break-glass procedure is what maps one, for a stated window, and unmaps it at close. The break-glass record is therefore a precondition of the access, not evidence beside it.

6.4 Continuity and restoration (Article 32(1)(c)). Annex B, Part 2 sets out the recovery design, together with the recovery objectives the ComplyChat Incident Response Plan, Version 1.0, effective 6 September 2026 derives from the estate. That plan, by that name and version, is the document made available to customers under NDA. The strongest continuity property of the service is structural: the lasting record already sits in your own tenant and survives the total loss of our estate.

Sub-processors (Annex C)

7.1 You give general written authorisation to the sub-processors listed at chat.org.uk/sub-processors.html, reproduced at signature in Annex C. Each is engaged under a written contract imposing the same data-protection obligations as this DPA (Article 28(4) UK GDPR).

7.2 Current list, in the order the published page carries it (eleven entries):

1. Microsoft Corporation (Azure) – hosting and transient processing: compute, storage, networking, brief message processing and operational logging across every governed channel. United Kingdom only (UK South; backups of our operational database are replicated to UK West, Microsoft's paired UK region, and Annex B, Part 2 states the position on restore points). The working copy in clause 1.5 lives here. Where you answer from Microsoft Teams, the messages your staff post in a mapped Teams channel reach us through Azure Bot Service, a Microsoft Azure service under this same entry.
2. Microsoft Azure Communication Services – outbound email and, where an organisation has calls in use, the carriage and recording of voice and video calls, machine transcription (Azure Speech, UK South) and the AI-written call summary (Azure OpenAI Service, UK South, processing pinned to the region). UK data location; live media transient.
3. Microsoft Azure SignalR Service – real-time message fan-out. The one sub-processor that carries governed message content between the people in a channel while it is in flight. UK South; no persistent store.
4. Microsoft Azure Maps – draws the map picture on a shared location card. Coordinates only; outside the United Kingdom (West Europe account, global endpoint). See clause 8.2.
5. Microsoft 365 (Exchange Online) – our operational mailboxes (enquiries@, compliance@). EU Data Boundary.
6. Twilio – the one-time passcode text that verifies a phone number for our secure web space. In the data path only for that verification text; global infrastructure; UK Addendum to the EU SCCs.
7. Andrews & Arnold Ltd (A&A) – the published inbound SMS number (020 3095) and the outbound utility texts (invite, content-free nudge, leave confirmation). Where a person texts the published number, the words they send are captured as the first message of that governed conversation, so inbound texts to the published number are governed message content in flight and pass through A&A. Outbound, A&A carries utility texts only. United Kingdom.
8. Browser push services (Apple, Google, Mozilla) – the content-free "new message" nudge to a person's device. Payloads carry no message content; encrypted to the device under the Web Push standard; global infrastructure.
9. Stripe Payments UK Limited – card processing and direct debit for subscription fees, where you choose to pay by card rather than by invoice and bank transfer. Card details are entered directly into Stripe-hosted elements and are never seen or stored by us; the data that reaches Stripe is your billing contact's details and the payment itself, never Customer Data from a Governed Channel. Global infrastructure; UK Addendum to the EU SCCs.
10. Microsoft Azure Application Insights (Azure Monitor) – operational telemetry; message content stripped at source; some operational identifiers (such as phone numbers) may appear in transient diagnostic logs. United Kingdom only.
11. Google Ireland Limited (Google Ads / gtag.js) – conversion measurement on the public marketing site only, consent-gated. Plays no part in the product or any governed channel and never touches Customer Data. Listed because reviewers ask; excluded from the clause 8.2 count for that reason.

Two Azure services that carry your content sit under existing entries rather than as their own row, because they run under the same Microsoft Online Services DPA: Azure Speech and Azure OpenAI Service (entry 2). Azure Bot Service, through which Teams-channel messages reach us, is named within entry 1 on the published page for the same reason. The typefaces used by the client portal, the operator console and our emails are served from our own domain; no product surface fetches anything from a third party that is not on this list.

7.3 We will update the published list at least 30 days before any change takes effect, notify your account administrator by email, and give you the opportunity to object on reasonable data-protection grounds. If we cannot adequately address your objection, you may terminate the affected Order Form without penalty and we will refund fees paid in advance for the unexpired portion. Urgent security changes may be made immediately with notice as soon as reasonably possible.

International transfers

8.1 Customer content (messages and attachments) is processed in UK-region Microsoft Azure (UK South; backups of the operational database are replicated to UK West, Microsoft's paired UK region, as Annex B, Part 2 describes) and stored at rest in your own Microsoft 365 tenant. With the exceptions below it is not transferred outside the United Kingdom by us in the normal course of the service.

8.2 The five exceptions, in the order the Privacy Notice states them, each safeguarded as stated.

Counting rule. These are the exceptions to UK-only processing of Customer Data and of correspondence with us. Google Ireland Limited (entry 11) is excluded from the count because it processes marketing-site visitor data for which we are controller, never Customer Data.

1. Stripe Payments UK Limited – billing, where you pay by card. UK Addendum to the EU SCCs for any transfer outside the UK; card details entered directly into Stripe-hosted elements and never seen or stored by us.
2. Microsoft 365 Exchange Online – our operational mailboxes, within Microsoft's EU Data Boundary; correspondence you send us may be stored in the European Union as well as the United Kingdom. UK adequacy regulations for the EU.
3. Twilio – the one-time passcode text; global messaging infrastructure. Twilio Data Protection Addendum and the UK Addendum to the EU SCCs.
4. Browser push services (Apple, Google, Mozilla) – content-free routing metadata (a room id, a generic prompt and a link), encrypted to the device; global infrastructure.
5. Microsoft Azure Maps – the map picture on a shared location card. What is sent is the shared coordinates and nothing else (a latitude and longitude to six decimal places, as centre and as pin); no IP address, name, phone number, member, channel or organisation identity and no message text; fetched by our UK servers, never by the member's device; held in server memory for up to twelve hours and never written to a database of ours. Microsoft's Online Services DPA; UK adequacy for the West Europe account; UK Addendum to the EU SCCs beyond it. Moving the account to a UK region would not remove the transfer because the endpoint is global, so we disclose it rather than promise to fix it.

8.3 Our application telemetry is processed in a UK Azure region (Application Insights); no transfer arises in respect of it.

Assistance, data-subject rights and transparency

9.1 Access and export (Article 15), and what access we hold. Subject access requests touching the governed record are served via Microsoft Purview eDiscovery inside your own tenant; our team advises while your administrators run the searches, typically over a screen-share, and we take no copies of record content in doing so. For anything touching the live working copy – a full export, or erasure of a person's working-copy data – you email us and we action it under your instruction; every export or erasure we perform is recorded to your transparency feed. As to standing access: the archive application holds one application-level grant into your tenant, scoped to write on the single site you chose, visible to you in the client portal and revocable by you; our operators hold the doors described in clause 6.3 and Annex D, each of which writes to your feed. We do not hold standing human access to your Microsoft 365 environment.

9.2 Erasure (Article 17). On your instruction we erase a named subject from the working copy: identity columns are overwritten with a tombstone, rows are retained for referential integrity and audit, staged media objects are hard-deleted, and an erasure certificate is issued only when a durable ledger confirms that every captured object has been erased or written off with a reason. The certificate names the planes the run reached, is retained by us for six years after the end of the customer relationship in a form that carries no plaintext identifier, and a copy is filed into your Transparency folder in your own Microsoft 365, never into the Archive. The archive in your tenant is out of scope of our erasure and is retained or deleted under your own Purview policies; where the archive holds a sealed acknowledgement or task summary naming the subject, we queue an amendment record into your archive rather than editing the filed document.

9.3 DPIA assistance (Articles 35 and 36): our DPIA template and reasonable assistance, at no charge.

9.4 Transparency feed. A content-free, hash-chained access feed records each time the service or an operator touches your data, in eight categories, with a monthly heartbeat filed into your own Microsoft 365 and posted to your compliance channel confirming the chain is unbroken. Each night the feed's new events are also mirrored to a second, append-only copy held under a locked 395-day immutability policy, so a copy exists that we cannot edit or delete. Alert-grade events – an operator access, a break-glass entry, an export, a change to retention, an administrative change or a sign-in anomaly – also send an immediate email to the recipients you set. The feed records that something happened, never what was said. Annex D describes it.

9.5 Audit – documentary. We will make available to you the information reasonably necessary to demonstrate compliance with Article 28 UK GDPR. All of our infrastructure runs in Microsoft data centres, which do not admit customer inspections, and the operational store is shared with other customers whose data we must not expose; the audit under this DPA is therefore documentary. Your right under Article 28(3)(h) to audit, including inspection, is discharged through the documentary bundle below, which is the evidence Microsoft's own audit regime makes available to us; nothing in this clause limits the powers of a supervisory authority. On request, no more than once in any twelve months (and at any time after a personal-data breach affecting you), we will provide: our written attestations of the measures in Annex B; an export of your transparency feed (clause 9.4), which you can verify against the hash chain without our help; confirmation of the WORM mirror's immutability policy; and Microsoft's own SOC 2 and ISO 27001 audit reports for the Azure services in Annex C, under the terms on which Microsoft makes them available. Where those documents show a defect, we will answer your written questions about it within ten working days and agree a remediation plan. You may share the documents with your auditor under NDA, and with a supervisory authority without restriction.

Personal-data breach

We will notify you without undue delay after becoming aware of a personal-data breach affecting your data – in practice, within 24 hours of confirmation – with the information you need to discharge your own Article 33 obligations, and will cooperate in your investigation, mitigation and remediation. Confirmation means the moment the Incident Lead (as defined in the incident response plan) concludes, on the evidence then available, that personal data for which you are controller has been, or is more likely than not to have been, accessed, disclosed, altered, lost or made unavailable without authority; it is defined in the incident response plan and the 24-hour clock runs from it. You will notify us promptly of incidents on your side that affect the service.

Return and deletion on termination (Article 28(3)(g)) – the no-hostage clause, operationalised

11.1 The record is the return. Your governed record already sits in your own Microsoft 365 tenant, under your own Preservation Lock and retention policies, and is unaffected by termination. There is nothing we need to hand back for you to keep it, and nothing we could withhold. A documented read-back renders the filed record from your tenant without any database of ours, so the return under Article 28(3)(g) is a capability you already hold rather than an export we generate. The same capability is the substance of the continuity position in Annex B, Part 2.

11.2 What we do hold, and its export. On termination – and at any point during the subscription, on request – we provide a full export of any Customer Data we do hold (account records, configuration, routing metadata, and the working copy and any in-flight transient data) in open, machine-readable formats within 14 days of your written request, keep the export available at least 60 days after termination, and – once you confirm your export is complete – delete that data from our active systems within 30 days with written confirmation. The working copy is deleted on that same schedule; it was never the system of record. Residual copies in encrypted backups are overwritten within the standard backup-retention cycle (typically not exceeding 90 further days) and remain protected by the same controls until they are; the written confirmation says so explicitly. These obligations do not apply to data we must retain by law.

11.3 There are no fees to exit, end, export or leave. Where we operated a published number for you, we will, where the phone provider allows, help you port it to your own account, or otherwise release and close it.

Liability, law and precedence

Liability for breaches of this DPA is as set out in the Terms (data-protection breaches sit outside the standard 125% cap; a higher, separately negotiated cap may be set on the Order Form). Governing law: England and Wales; exclusive jurisdiction England and Wales. Precedence: Order Form, then this DPA, then Terms.

Publication of this DPA

This DPA is published at chat.org.uk/dpa.html, Version 1.0, effective 6 September 2026, with the same Version and Effective identifiers as the other published legal documents. The Terms of Service link to it, the Order Form incorporates it by that URL together with a dated snapshot taken on the order date, and a signed copy is not required for it to bind: accepting the Terms accepts this DPA. Changes to it follow the same notice rules as changes to the Terms.

Details of processing

As clause 4, and in addition:

• Recorded calls. Every call in a governed channel is recorded; there is no unrecorded option. Both participants are told before the call connects and must accept a recorded call; a recording indicator stays on screen; a spoken notice at the start is captured on the recording by default. The recording (audio, and video when a camera is on) and a machine transcript land in your Microsoft 365 alongside the message record under the same retention rules; the accepted-recording taps of both participants are kept on the record. A short AI-written summary is produced for staff as a clearly labelled working aid and is never filed into the record.
• Location cards. Where a member shares a location, the coordinates are message content and rest in your Microsoft 365; the map picture is drawn by Azure Maps as clause 8.2(5) describes.
• Calls between your own people. Where you leave the organisation-wide setting on (its default), your own staff may call one another from the people directory whether or not they share a channel; such calls are recorded and filed on the same terms.

Technical and organisational measures

Part 1 – Measures in place

As clause 6.1. In addition: row-level security in the operational database, in enforcing mode on every policy group (Part 3); a tamper-evident transparency feed with a WORM mirror (Annex D); a fail-closed break-glass door for human database access that maps and unmaps the operator's identity for the window it records (Annex D); an Article 17 erasure engine whose certificate is refused until a durable ledger says nothing is left (clause 9.2); an archive delivery health monitor with content-free error classification; and a residency check that refuses to accept a message while no archive target is configured for the deployment.

Part 2 – Continuity and restoration (Article 32(1)(c))

The recovery design of record is the ComplyChat Incident Response Plan, Version 1.0, effective 6 September 2026, whose section 8 states the recovery objectives per data class and whose section 13 is the test schedule. Its properties, layer by layer:

The plan also mandates, as the first action after any recovery, disabling the retention, erasure and organisation-purge timers before they can walk pointers to media that no longer exists and certify erasure of records that were merely lost.

Part 3 – Organisation isolation attestation

Every organisation-scoped table in the operational store carries the organisation identifier. Row-level security policies enforced by the database engine, covering the content, roster, authentication and operator planes, confine each database statement on a policed table to the one organisation bound to its session context. The application's own SQL additionally carries an explicit organisation predicate on every organisation-keyed statement, so a statement must satisfy both the application's predicate and the engine's. Operator-plane reads that legitimately span organisations run under a separate ambient-organisation sweep rather than by disabling the policies.

A row-level predicate narrows what a statement sees; it does not change what a unique index enforces, which remains database-wide. ComplyChat maintains a live-execution check against a real database engine for that class of defect.

Microsoft Entra-only authentication is enforced on the production database server, so there is no SQL-authentication path into the estate and every connection is a named Entra identity. Every policy group runs in enforcing mode, so the engine denies any database principal that is not mapped to an organisation. The application's own database principal is mapped and is bound to one organisation per batch. ComplyChat's operators' Entra identities are unmapped by default, so an operator who connects outside the break-glass procedure is refused by the engine; the break-glass procedure inserts a time-boxed mapping for the named operator after it has recorded the access on the organisation's feed and alerted its recipients, and removes the mapping when the window closes. The record is a precondition of the access.

Sub-processor snapshot at signature

Reproduce the live sub-processors.html page verbatim at the date of signature and record the date of reproduction and the Version and Effective identifiers the page carried on that date. The eleven entries and their order as at Version 1.0 are in clause 7.2.

Access and transparency

Who can read message content, and through which door.

What you can verify without trusting us. The feed is hash-chained event to event from a genesis derived from your organisation's identifier; the whole chain is re-verified nightly and whenever an administrator opens the feed; one button exports the entire content-free ledger as JSONL for your auditor; each night the new events are mirrored to an append-only copy under a locked 395-day immutability policy; a monthly heartbeat, filed into your Microsoft 365 and posted to your compliance channel, states how many human accesses happened in the month just ended and that the chain is unbroken.

What is a technical gate. Microsoft Entra-only authentication is enforced on the database server, so no SQL-authentication path exists and every production connection is a named Entra identity. Row-level security runs in enforcing mode on every policy group, and our operators' identities are unmapped by default, so a connection made outside the break-glass procedure sees no organisation's rows. The break-glass procedure is the only door, and it records the access and alerts you before it maps the operator's identity for the window; the record on your feed is therefore a precondition of the access, and its close event marks the moment the mapping was removed.