A GDPR compliant messaging app

Why no app is compliant on its own

The UK General Data Protection Regulation, UK GDPR, places its duties on the controller, the organisation that decides the purposes and means of processing, and the sentence that settles the question is Article 5(2): "The controller shall be responsible for, and be able to demonstrate compliance with, paragraph 1", the paragraph that lists the principles of lawfulness, fairness and transparency, purpose limitation, data minimisation, accuracy, storage limitation, and integrity and confidentiality. Every one of those is a decision your organisation makes about how it will handle personal data: why it is messaging, what it collects, how long it keeps it, who can see it. An app cannot make those decisions for you, so an app cannot be compliant for you. What it can do is make each decision possible to carry out and possible to prove, or make some of them impossible.

That is why this guide avoids the word certified. There is no UK GDPR certification that a messaging app can hold on your behalf, and a vendor that says its product "is GDPR compliant" is either describing its own obligations as a processor, which is a real and narrower thing covered in section 03, or using the phrase as a synonym for encrypted. There is no GDPR standard that a messaging platform can be tested against and no fixed list of GDPR requirements for a messaging solution; the requirements are the controller's, and they differ between a hospice, a primary school and a housing charity. A product is designed to support compliance, or it is not; the compliance is yours.

The vocabulary of the vendor pages is worth learning so that it can be translated. Secure messaging, encrypted messaging, business messaging, an internal communication or business communication platform, a messenger that gives you full control of your user data, data sovereignty, data security, GDPR-compliant messaging tools that let you ensure GDPR compliance or meet GDPR requirements: each of those phrases describes one property of a product, usually encryption or the location of a server, and none describes the organisation's own decisions about purpose, lawful basis, retention or rights. Security and compliance are different questions. A product can be entirely secure and still leave you unable to answer a subject access request, and it is that second kind of failure that attracts GDPR fines: the maximum penalty under UK GDPR is £17.5 million or 4% of annual worldwide turnover, whichever is higher, and the largest fines the ICO has issued have followed breaches of the principles and of security alike, never the absence of a particular product feature.

The most useful independent statement of what a secure messaging platform should be built to do is not from the ICO but from the National Cyber Security Centre, whose Secure communication principles were written for risk owners choosing communication tools for government and the public sector. There are seven: protect data in transit; protect network nodes with access to sensitive data; protect against unauthorised user access to the service; provision for secure audit of the service; allow administrators to securely manage users and systems, which the NCSC spells out as lifecycle management of joiners, movers and leavers, with two-factor authentication and logging; use metadata only for its necessary purpose, with "clear and transparent terms and conditions" about what is collected; and assess the supply chain for trust and resilience, including where the data is hosted. Notice how many of the seven are about the organisation's control of the service rather than the secrecy of a message. Sections 02 to 05 take the law's requirements in the same order, and the pattern holds: the difficult questions are all about control, and consumer apps fail them not because they are insecure but because the organisation is not their customer.

Encryption is required, and it is not the answer

Article 32(1) of the UK GDPR requires the controller and the processor to "implement appropriate technical and organisational measures to ensure a level of security appropriate to the risk", and it gives four examples, of which encryption is only the first: "(a) the pseudonymisation and encryption of personal data; (b) the ability to ensure the ongoing confidentiality, integrity, availability and resilience of processing systems and services; (c) the ability to restore the availability and access to personal data in a timely manner in the event of a physical or technical incident; (d) a process for regularly testing, assessing and evaluating the effectiveness of technical and organisational measures". The ICO's encryption guidance asks the two questions organisations should ask in that order, "Does this mean we must encrypt personal information?" and "Does encryption remove the risks?", and the shape of its answer is that the law does not name encryption as mandatory but expects it where it is appropriate to the risk, taking into account the state of the art and the cost of implementation, and that encrypting data does not remove the other risks, because a breach can be a loss of availability or of integrity as easily as a loss of confidentiality.

This is where the marketing of consumer messaging and the text of Article 32 part company. End-to-end encryption, the design in which a message is end-to-end encrypted between the sending and the receiving handset, is a strong answer to (a): nobody between the two handsets can read the message, including the provider. It is no answer at all to (b) and (c) as they apply to an organisation, because the organisation holds nothing. The messages exist on the phones of the people in the conversation. If a phone is lost, a member of staff leaves, a volunteer deletes the app or a family changes number, the organisation has lost availability of a record it was responsible for, and it cannot restore it. The NCSC's fourth and fifth principles, secure audit and the management of joiners, movers and leavers, fail for the same reason: there is nothing for the organisation to audit and no account for it to remove. A consumer app is secure against outsiders and unmanageable by the organisation, and UK GDPR requires both.

So the test of a messaging app's security is not whether it encrypts, since any serious product does, in transit and at rest, but who holds the keys and the record. Ask where a message exists once it has been delivered, whether the organisation can produce it without borrowing a member of staff's phone, what happens to it when that person leaves, and whether there are audit trails of who read and exported what. An app that cannot answer those has passed a test that is not the one the law sets.

The contract: Article 28, and what a vendor's page is not

When a messaging service holds your messages, the vendor is a processor and you are the controller, and Article 28 says what must exist between you. Paragraph 1: the controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures in such a manner that processing will meet the requirements of this Regulation". Paragraph 3: the processing is "governed by a contract or other legal act" that stipulates, at least, that the processor:

1. processes the personal data "only on documented instructions from the controller, including with regard to transfers of personal data to a third country";
2. ensures that the people it authorises to process the data "have committed themselves to confidentiality or are under an appropriate statutory obligation of confidentiality";
3. takes "all measures required pursuant to Article 32";
4. respects the conditions for engaging another processor;
5. assists the controller, by appropriate technical and organisational measures, in responding to requests from individuals exercising their rights;
6. assists the controller in meeting its obligations on security, breach notification and impact assessments under Articles 32 to 36;
7. at the end of the service, "deletes or returns all the personal data to the controller" and deletes existing copies unless the law requires storage;
8. makes available "all information necessary to demonstrate compliance" and "allows for and contributes to audits, including inspections".

Paragraph 2 covers the vendor's own suppliers: the processor "shall not engage another processor without prior specific or general written authorisation of the controller", and under a general authorisation it "shall inform the controller of any intended changes concerning the addition or replacement of other processors, thereby giving the controller the opportunity to object". In practice that means a published sub-processor list and a notice mechanism with a period in which you can object, which is why the ICO's guidance on contracts between controllers and processors treats "Using sub-processors" as one of the minimum terms alongside documented instructions, the duty of confidence, security, individuals' rights, assistance, end-of-contract provisions and audits.

Now put a consumer messaging app beside that list. Its terms of service are a contract between the app and the individual user who installed it; your organisation is not a party, gives no documented instructions, receives no notice of sub-processors, has no right to have the data returned or deleted at the end, and no audit right. It is not that the contract is inadequate: there is no Article 28 contract at all, and the organisation is using a processor it has never engaged. The same test applies to any business product. If the vendor cannot show you a data processing agreement that covers (a) to (h), a sub-processor list and the notice mechanism, and the deletion-or-return commitment, then the product's GDPR page is a description, not a contract. The same applies, with a twist, to an open source messenger you host yourself on a private cloud or your own server: the Article 28 contract disappears because there is no processor, and every obligation under Article 32, from patching to backups to restoring availability, lands on the organisation instead. That can be the right choice for an organisation with an IT team; it is not a way of avoiding the questions.

The vendor's own obligations are real, and this is the one sense in which a vendor can truthfully speak of its GDPR compliance: a processor must keep its own record of processing, secure the data under Article 32, tell the controller about breaches without undue delay, and act only on instructions. Ask to see those commitments in writing, dated, and signed or accepted by your organisation, not by an employee's tap on an install screen.

Where the messages go: transfers and the record of processing

The next question is geography, and it is one that the ICO reset in January 2026 with a brief guide to international transfers. A transfer of personal data from the UK to a receiver outside it is a "restricted transfer", identified by a three-step test that begins with whether UK GDPR applies to the processing at all. "Every restricted transfer must be covered by one of the following transfer mechanisms": UK adequacy regulations, appropriate safeguards, or an exception; the appropriate safeguards most organisations will meet are the International data transfer agreement, the IDTA, and the International data transfer addendum to the EU standard clauses. "If you initiate a restricted transfer, you're responsible for complying with the transfer rules." A messaging app decides, in its architecture and its supply chain, whether you are initiating one every time a message is sent.

The honest way to answer that is to ask a vendor where each part of the service processes data, because the answer is rarely one country. Message content at rest and in processing; backups; the delivery network at the edge; push notifications, which on every phone platform pass through the platform owner's infrastructure; the one-time code sent by SMS when a person signs in; call media if the app makes calls; and the support staff who can see the system. Each is a line in the vendor's sub-processor list, each has a location, and together they are the answer to the question a vendor page means by data sovereignty. If the list is not published, the transfer question cannot be answered and neither can the sub-processor notice in section 03.

Whatever the answers, they belong in your own record of processing. Article 30 requires controllers to keep a written record of their processing activities, and the ICO's documentation guidance lists what it must contain: the name and contact details of your organisation and, where applicable, other controllers and your data protection officer; "The purposes of your processing"; "A description of the categories of individuals and categories of personal data"; "The categories of recipients of personal data"; "Details of your transfers to third countries including documenting the transfer mechanism safeguards in place"; "Retention schedules"; and "A description of your technical and organisational security measures". Organisations with fewer than 250 employees are exempt for processing that is occasional, not risky and does not involve special category data; staff and service-user messaging is none of those, and a school's or care provider's messages will contain special category data by their nature. The ICO's best-practice list adds that the record should link to "controller-processor contracts" and "the location of personal data", which is exactly the material sections 03 and 04 have asked the vendor for.

Lawful basis, individual rights, retention and the 72 hour clock

Before any of the above, the ICO's guide to lawful basis is blunt: "You must have a valid lawful basis to handle personal information", "You must determine your lawful basis before you start using the personal information and you must document it", and "you can't usually swap from consent to a different basis". For internal communication with staff and volunteers about the work, consent is the wrong basis, because a person who depends on the organisation for a job or a role is not freely choosing; the ICO has long warned that an imbalance of power, as between an employer and an employee, makes consent hard to rely on. Legitimate interests, or public task for a public authority such as a maintained school, is the usual answer, with the safeguarding lawful bases for the messages that carry a concern. What the app has to allow is not the basis itself but the transparency that goes with it: the people in a conversation, including the parents, residents and families who are not your staff, told at the point of joining that the conversation is held by the organisation and why.

Then the rights. A subject access request under Article 15 is the one that tests a messaging app most sharply: an individual is entitled to their personal data, which includes the messages about them, across every channel they appear in, and the SAR guide on this site describes how far that reaches into WhatsApp threads on staff phones. The app has to let you search and export by person, redact third parties, and do it within a month. Erasure and rectification need the same reach. Storage limitation needs retention policies the app can actually apply: a retention setting that governs the record the organisation holds, not to what happens to be left on a handset, so that a message kept for the period your retention policy sets is deleted at the end of it, and one the law requires you to keep is not deleted by a member of staff clearing space.

Finally the breach clock. Article 33(1) requires the controller to notify the ICO "without undue delay and, where feasible, not later than 72 hours after having become aware" of a personal data breach that is likely to result in a risk to individuals, and Article 33(2) requires that "The processor shall notify the controller without undue delay after becoming aware of a personal data breach." Two consequences follow for a messaging app. Your vendor must be contractually bound to tell you, promptly, with enough detail to assess risk; a consumer app has no such duty to your organisation because your organisation is not its customer. And a lost phone with a year of unencrypted-at-rest work conversations on it is a breach the organisation may have to notify, which is the availability and confidentiality point from section 02 arriving as a deadline.

Put together, the questions to ask any vendor are short, and a good vendor will have answered them on a page before you ask:

• Where is the Article 28 data processing agreement, and does it cover (a) to (h), sub-processor notice and deletion at the end?
• Where is the sub-processor list, with the location of each, and how are changes notified?
• Where does message content, its backups, and each supporting service process data, and which transfer mechanism covers anything outside the UK?
• Can the organisation, not the individual user, produce, search, export and delete messages by person and by channel, and is there an access and export log?
• What is the retention control, and does it govern the record the organisation holds?
• Are all participants told, at the point of joining, that the conversation is held by the organisation?
• How, and how quickly, will the vendor tell you about a breach?

What we built, and where it is not the answer

ComplyChat exists because the conversation that decides something, the safeguarding concern raised at nine on a Friday, the rota change, the message to a parent who has no account on anything, almost never happens inside the systems an organisation controls, and every requirement in this guide assumes it does. It is designed so that the organisation is the customer and the controller: everyone added to a channel is told it is on the record and can object or leave at any time; messages are recorded on the server as they are sent, not gathered from handsets afterwards; a mobile number verified by SMS is an identity on the platform, so a volunteer, an agency worker or a parent can be in a channel without an account on your systems; and on the paid plans the lasting record files into the customer's own Microsoft 365, under the customer's retention rules, where a subject access search already reaches. Messages are stored and processed in the United Kingdom, and the published sub-processor list says where each supporting service, from the SMS code to push notifications, processes data, with the data processing agreement beside it, because section 03 says that is where a vendor's compliance claims have to live.

It is not the answer for everyone. If every person who needs to be in the conversation already has an account on the organisation's Microsoft 365 or Google Workspace and nothing said there ever has to be produced, the product those accounts came with will serve you better and costs you nothing more. The Free tier is personal messaging, one private group, direct messages and up to 25 staff members, with three calendar months of history and no Microsoft 365 archive, which is an honest way to try the experience and not a way to meet a statutory retention duty. And no messaging app is a record-keeping policy: the lawful basis, the retention schedule and the Article 30 entry are still yours to write.

The question this guide leaves with a leadership team is the one section 04's card asked, made concrete. Take the last message in which something was decided about a person your organisation is responsible for. Which app carried it, who is the controller of that app's copy, and could you produce it tomorrow without asking to borrow a phone?

Official guidance and your next step

The primary sources are the UK GDPR itself on legislation.gov.uk, in particular Article 5, Article 28, Article 30, Article 32 and Article 33; the ICO's guides to lawful basis, contracts and liabilities between controllers and processors, international transfers, documentation and encryption; and the NCSC's Secure communication principles. The ICO notes that its guidance is under review following the Data (Use and Access) Act, so check the date on each page.

This guide is a practical starting point for organisations in the United Kingdom, not legal advice about any particular product or contract. Your data protection officer, or the person who holds that role in a small organisation, comes first, and so does the vendor's own documentation, which this guide has told you where to look for.

Then do one thing: write the Article 30 record entry for messaging, the nearest thing there is to a statement of your own GDPR compliance, with the app you actually use today in the recipients line, and see which of the seven fields you can complete from documents you hold. The blanks are the decision.