The RNLI supporter-data breach is not simply another cyber-security story. It exposes a weakness extending across charities, churches, schools and safeguarding bodies: an organisation may entrust personal information to somebody else’s servers, but it cannot entrust away responsibility for possessing it.
The Royal National Lifeboat Institution has warned supporters that information entrusted to the charity may have been taken after unauthorised access to Beacon CRM, the third-party customer-management platform through which the RNLI processed some supporter data.
Beacon informed the RNLI on 3 August that it was investigating unauthorised access to its systems. The RNLI subsequently said that affected organisations had been advised to proceed on the assumption that information stored there had been accessed and taken. Analysis indicated that a significant volume of information was probably downloaded, although investigators could not establish precisely which individual records were involved.¹
Depending upon the supporter, that information may include names, postal and email addresses, telephone numbers, dates of birth, records of interactions with the charity, incomplete bank-account details and personal information supplied when people contacted the RNLI about its services and activities. There is presently no evidence that RNLI supporter information has been published, shared online or otherwise misused.¹
The distinction between the RNLI and its supplier matters. The charity says its own IT systems were not compromised; Beacon’s were. The Metropolitan Police investigation concerns the unauthorised access to Beacon’s systems, and the RNLI says there is no indication that it was specifically targeted.¹ That deserves emphasis because the incident follows a period in which RNLI volunteers have faced threats, abuse and protests connected with rescues of migrants in the Channel. Police have investigated threatening material directed at volunteers, while the charity has increased security precautions. Nothing presently establishes that the Beacon intrusion had anything to do with that hostility. The coincidence is noteworthy; a causal connection is not established.²
The more important question is considerably less dramatic: who remains responsible when an organisation hands somebody else the keys to its database? The answer cannot simply be the supplier. A charity may outsource hosting, software development, payment processing, email distribution, database administration and technical security, but none of those arrangements extinguishes its own responsibility for the information it chose to collect.
Under UK data-protection law, an organisation determining the purposes and essential means of processing will ordinarily be the controller, while a supplier processing information on its instructions may be the processor. The Information Commissioner’s Office states that a controller must use processors capable of providing sufficient guarantees that their processing will comply with the UK GDPR and protect individuals’ rights.³ That duty does not end when somebody signs a contract. Controllers remain responsible for overall compliance, while processors have direct obligations of their own, including requirements concerning security, instructions, sub-processors and breach notification.³ There is therefore a fundamental difference between transferring a function and transferring responsibility. The first is routine; the second is impossible.
One detail makes the Beacon incident particularly instructive. On 1 July, barely a month before customers were informed of the intrusion, Beacon announced the result of its annual ISO 27001 surveillance audit. It reported another “perfect score”, saying that auditors had found no major or minor non-conformities in its security systems and practices.⁴ There is no contradiction in that. ISO 27001 certification is not an assurance that an organisation can never be breached. It concerns the management of information-security risks and controls. Serious organisations should want suppliers to maintain recognised security standards. The mistake begins when certification is treated as the end of scrutiny rather than one part of it.
Beacon’s own Chief Technology Officer, David Simpson, subsequently supplied the most striking commentary. In 2025 he had written an article drawing lessons for charities from another company’s £3 million data-breach penalty. After Beacon suffered its own incident, he added a note saying that he had deliberately left the article online partly as a “warning about hubris”. An organisation, he observed, may believe it is doing everything correctly, possess a security position it regards as strong and receive praise from auditors, yet still suffer the event it had worked to prevent.⁵ That is not an argument against security standards. It is an argument against complacency.
The issue reaches much further than Beacon or the RNLI. Charities increasingly depend upon systems capable of storing almost everything they know about the people with whom they deal. Churches keep membership and pastoral records. Schools hold extensive information about children and families. Voluntary organisations record donors, volunteers and beneficiaries. Safeguarding partnerships may handle information whose exposure could cause considerable distress or harm. In all of these contexts, the central question is therefore not merely whether the server is encrypted, but why the information is there in the first place.
Data minimisation is often reduced to one more expression in the vocabulary of GDPR compliance. It is better understood as custodianship. An organisation should not accumulate information about human beings merely because contemporary software makes accumulation almost effortless. Every additional field creates another thing that can be wrongly accessed, copied, exported, retained or disclosed. If an organisation cannot explain why it needs to possess a piece of personal information, there is a serious question whether it should possess it at all.
That principle becomes particularly important in pastoral and safeguarding work. Information need not be marked “sensitive” to become revealing. A record of repeated contact with a support organisation can disclose vulnerability. Notes from a pastoral conversation may disclose religion, family circumstances or distress. Attendance at a particular service or group can say something about a person which his employer, neighbour or acquaintances do not know. Separate scraps of information which appear harmless can reveal considerably more when combined. The proper discipline is therefore not to ask how much information a system can store, but how little an organisation genuinely needs to retain.
The same principle applies to access. If twelve people can view information which only three need for their work, the difficulty is not principally technological but one of governance. If former staff retain accounts, permissions have not been reviewed for years, bulk exports are scarcely monitored or nobody on the board knows which subcontractors receive the information, an ISO certificate on the supplier’s website does not answer the underlying problem.
Nor is this an issue which trustees can simply delegate to “IT”. Trustees need not become penetration testers or database engineers, but they do need to know what information their organisation possesses, why it possesses it, where it is processed, who can reach it, how long it is retained and what evidence exists that the organisations handling it remain suitable to do so. They should know which organisations process their records, which sub-processors can access them, what information an administrator could export in a single operation, whether those exports are logged, when permissions were last reviewed and what remains in backups after deletion. Most importantly, they should know what an intruder would obtain if their principal supplier were compromised tomorrow. Those are not technical curiosities. They are questions about stewardship.
The Charity Commission’s response to the Beacon incident underlines the point. On 7 August it confirmed that it was monitoring the incident, was in contact with the ICO and had already received serious-incident reports from affected charities.⁶ The RNLI says that after learning of the incident it brought in independent cyber-security specialists, reviewed potentially affected information, notified relevant regulators, suspended further transfers to Beacon and began contacting supporters whose information might place them at greater risk.¹ Those are responses to an incident already suffered. The harder work for every other organisation is to ask the necessary questions before its own name appears in such a statement.
The digital revolution has given small organisations powers which once belonged only to governments, banks and large corporations. A modest charity can now maintain searchable records on thousands of people, correlate their donations and communications, retain years of correspondence and retrieve an individual’s history almost instantaneously. Yet capability is not entitlement. The fact that information can be collected cheaply does not mean it should be collected; the fact that storage costs almost nothing does not mean records should be kept indefinitely; the fact that access can be granted at the click of a mouse does not mean access should be broad; and the fact that somebody else owns the server does not turn somebody else into the custodian of the relationship.
People give charities more than money. They give their names, addresses and telephone numbers. Sometimes they disclose family problems, beliefs, vulnerabilities, financial circumstances or things said because they believed they were speaking to an organisation they could trust. A database converts that trust into data, which makes every unnecessary record an unnecessary risk, every excessive permission an unnecessary exposure, and every unexamined supplier relationship a governance question waiting to be asked.
The RNLI did not cease to owe duties to its supporters because their information happened to sit inside Beacon. No church ceases to owe duties to its parishioners because its records sit in the cloud. No school ceases to owe duties to a child because a commercial platform processes the record. No safeguarding organisation can answer an injured person by saying that the compromised computer belonged to somebody else. The technology may belong to the contractor, but the confidence belongs to the institution, and the information still concerns a human being whose trust made its possession possible. An organisation may outsource its database, its hosting and much of its technical security, but it cannot outsource the duty of care.
¹ Royal National Lifeboat Institution, RNLI affected by Beacon CRM cyber security incident, updated 8 September 2026.
² Steven Morris, The Guardian, Police working to protect RNLI in Dorset amid opposition to small boat rescues, 9 September 2026; Suha Kidwai, The Independent, Police launch probe after RNLI volunteers called ‘traitors’ and addresses leaked online in wake of anti-migrant protests, 9 September 2026.
³ Information Commissioner’s Office, What responsibilities and liabilities do controllers have when using a processor?; A guide to controllers and processors.
⁴ David Simpson, Beacon CRM, Product Update — July 2026, 1 July 2026.
⁵ David Simpson, Beacon CRM, What can charities learn from a recent £3 million data breach?, 8 July 2025, note added 11 August 2026.
⁶ Charity Commission, Guidance for charities affected by the Beacon cyber security incident, 7 August 2026.
Leave a Reply