Responsible disclosure

1. In short

There is no charge, no contract, and no account required to report something. You do not need to be a customer. You do not need to be a professional security researcher. If you noticed something that looks wrong, that is enough of a reason to send it.

2. Why we publish this

Most security problems in a system like ours are found by someone outside it. A developer notices a file that should not be public. A charity administrator sees a record that belongs to a different organisation. Somebody idly opens the browser console and finds something that should never have been sent to a browser.

In every one of those cases the question that decides what happens next is not technical. It is who do I tell, and what happens to me if I do? If the answer is a generic contact form and an unclear legal position, a good number of people close the tab. The finding does not go away when they do — it just stays available to whoever finds it next.

In the UK that hesitation has a specific cause. The Computer Misuse Act 1990 turns on whether access was authorised, and it has no general defence for acting in the public interest. A researcher poking at a service with no published policy is relying on the goodwill of the company they are about to embarrass. Publishing this page is how we remove that risk, in writing, in advance.

What the Beacon incident showed

In July 2026 Beacon CRM, another CRM used widely across the UK charity sector, suffered a serious breach. Beacon published a detailed public report about it, which is more than many companies do and which we would encourage anyone in the sector to read. Their report states that the probable root cause was an AWS access key exposed in public JavaScript build artefacts, which was then used by an unauthorised third party to copy their database.

The detail that matters here is that a credential in a public build artefact is externally findable. It is not buried in a private system. It is served to every visitor's browser, and it is exactly the kind of thing an ordinary developer stumbles over. Someone outside the company could plausibly have found it first — and if they had, they would have needed somewhere to send it.

Beacon's report describes many improvements made after the incident, including secret scanning, build artefact scanning, short-lived credentials in place of static keys, and continuous testing by a vetted community of ethical hackers. Those are good measures and we are not critical of them. But a vetted, paid community is an invitation list. It is not a front door. Nothing we can find in Beacon's public material, then or now, tells an uninvited passer-by where to send a finding or what protection they have if they do.

So this page exists, and it exists before we have an incident rather than after one. That is the whole point of it.

3. Safe harbour

If you make a good-faith effort to follow this policy while researching and reporting an issue, we commit to the following. This is a public, binding statement of how Alder CRM Limited will behave, and you may rely on it.

• We will not bring or support legal action against you in relation to your research, including under the Computer Misuse Act 1990, the Copyright, Designs and Patents Act 1988, or our Customer Agreement and Website Terms.
• We will not report you to the police or any other authority for the research itself, and if a third party contacts us about it we will confirm that your activity was authorised under this policy.
• We consider your research authorised access for the purposes of the Computer Misuse Act 1990, to the extent of the scope in section 5 and the rules in section 6.
• We will not contact your employer, your university or your client about your report unless you ask us to.
• We will not require you to sign a non-disclosure agreement as a condition of us accepting, triaging or fixing your report.
• If you accidentally cross a line — you see personal data you did not expect, or a test does more than you intended — that is not a breach of this policy provided you stop, tell us promptly, and delete anything you retrieved. Telling us makes it better, not worse.

4. How to report, and what happens next

Email security@aldercrm.com. If that ever bounces, use hello@aldercrm.com with “security” in the subject line and it will reach the same people. Our machine-readable contact details are published at /.well-known/security.txt in the format described by RFC 9116.

Please include, as far as you can:

• what the issue is, and what an attacker could do with it;
• the URL, endpoint or page where you found it, and which environment (for example aldercrm.com, or a workspace subdomain);
• enough steps for us to reproduce it — a short screen recording is often faster than prose;
• anything you retrieved, so we can work out whether real data was involved;
• how you would like to be credited, or that you would rather not be.

Write in English if you can. Send it in plain text or as an attachment; do not post it publicly, and do not send it through a customer's charity as an intermediary.

What we commit to

These are the response times we hold ourselves to. Working days are Monday to Friday excluding England and Wales bank holidays. Timelines for a fix run from the point we confirm the issue, and we will tell you if something is going to take longer and why.

If we go quiet on you, that is our failure and not a hint. Chase us at hello@aldercrm.com, and if we are still silent, section 7 says what you are entitled to do about it.

5. What is in scope

Everything Alder runs, on any of these:

• aldercrm.com and this website;
• app.aldercrm.com, auth.aldercrm.com, signup.aldercrm.com, and any workspace subdomain <workspace>.aldercrm.com;
• the participant and volunteer portals, including any custom portal domain we serve;
• our public JavaScript, CSS, source maps and other build artefacts;
• our public code repositories, container images and published packages;
• our DNS, email authentication (SPF, DKIM, DMARC) and TLS configuration;
• our iOS and Android applications;
• any Alder infrastructure you can reach from the internet.

Things we would especially like you to look for

Nothing on this list is a hint that we know of a problem. They are the classes of issue that would hurt a charity most, so they are the ones we would rather hear about first.

• Credentials or secrets we have published by accident — in a JavaScript bundle, a source map, a repository, a container image, a build artefact, an error page or a backup. This is the class of issue behind the Beacon incident described in section 2, and it is at the top of our list for that reason.
• Anything that crosses between workspaces. Each charity's data is isolated from every other charity's. A way to read, write or even count another workspace's records — through an ID in a URL, an API, an export, a search, a subdomain or a background job — is the most serious kind of bug we can have.
• Authentication and session handling — logging in as someone else, staying logged in after access is removed, bypassing two-factor authentication, or moving between workspaces you are not a member of.
• Authorisation inside a workspace — reading safeguarding notes, case records or donor data that your role should not permit. These records concern vulnerable people, so a permission bug here is more serious than the same bug over ordinary data.
• The public portals — participant and volunteer sign-up, guest check-in, public event pages. They are reachable without an account, so anything that turns one into a way to enumerate or confirm the people a charity supports matters a great deal.
• Exposed storage — uploaded files, exports or backups reachable without authorisation, or by guessing a URL.
• Injection, SSRF, deserialisation, file upload handling and the rest of the usual catalogue.
• Anything that would let someone alter or delete a charity's records, including audit logs and anything that undoes a deletion that should have stayed done.

Out of scope

We will still read anything you send, and if you show real impact we will take it seriously whatever list it is on. But by default we do not treat these as reportable issues:

• Denial of service, load testing, or anything that degrades the service for real charities. Never test this.
• Social engineering, phishing or physical attacks against Alder staff, our customers, or our suppliers.
• Findings against a customer's own systems, a customer's own configuration, or a third-party service we merely link to.
• Missing security headers, cookie flags, or TLS configuration preferences with no demonstrated impact.
• Reports produced entirely by a scanner, with no proof of concept and no analysis.
• Rate limiting on a form, unless you can show what it actually enables.
• Self-XSS, clickjacking on pages with no state-changing action, or issues that require a fully compromised device or browser.
• Email spoofing of domains we do not send from, or the absence of DNSSEC.
• Software version disclosure with no known exploitable vulnerability attached.
• Anything requiring a physically or administratively privileged position we have given you.

6. The rules we ask you to follow

Everything in section 3 is conditional on these. They exist because the data in Alder belongs to charities and to the people they support, and none of it is ours to put at risk on your behalf or on ours.

• Do not access, download, alter or keep other people's data. If a proof of concept needs a real record to be convincing, one screenshot with the personal details redacted is enough. Stop at the point the issue is proven.
• Test against your own workspace. Open a free one at signup.aldercrm.com/signup/free, and start the workspace subdomain with security- — for example security-jbloggs. That prefix is how we tell a researcher's workspace from a charity's, so it decides whether we read unusual activity as your testing or as an incident; a workspace without it is one we may treat as an attack on a customer. Use test data in it, never real people.
• Ask if you need more than the free plan gives you — a higher tier, or a second workspace to test isolation between two. Email us and we will set it up at no cost, with the same security- prefix. We would far rather provide the environment than have you improvise one against a real charity.
• If you find a live credential, prove it minimally and stop. Confirming that a key is valid is fair. Enumerating what it can reach, listing a storage bucket, or reading a database is not, and past that point we cannot protect you. Tell us immediately — a live credential is the one report we would like to receive at any hour.
• Do not degrade the service. No automated scanning at volume, no brute force, no fuzzing that generates real notifications, emails or SMS to real people. Charities run on this system during their working day.
• Delete anything you retrieved once we have confirmed the report, and tell us you have.
• Keep it between us until it is fixed — see section 7 for what happens if that takes too long.
• Report only what you found. Do not attach a demand for payment, a deadline shortened by an offer, or a threat to publish. That is not a disclosure and we will treat it as what it is.
• Comply with the law and with data protection obligations, which we cannot waive on anyone else's behalf.

7. Public disclosure

We are not going to sit on your finding, and we are not going to ask you to either.

• You may publish 90 days after you report, whatever has happened in the meantime. If we fix it sooner, you may publish as soon as the fix is live. We will not ask you to stay quiet for longer than that, and we will not treat publication after 90 days as a breach of this policy.
• If we have not acknowledged you within 5 working days, treat that as a failure on our part. You are free to publish, or to go to the ICO or the NCSC, without waiting for the 90 days.
• We would like to coordinate, mainly so that customers hear about it from us at the same time, and so that we can credit you properly. We will tell you a date rather than ask you for an open-ended extension.
• Please give us a little longer only if a fix genuinely requires it — a coordinated release with a supplier, say. We will explain why, in specifics, and we will not use it as a way to run the clock out.
• We will write it up ourselves where an issue affected customer data, whether or not you publish. Section 8 says what that involves.

8. What happens on our side

A report reaches a named person, not a shared queue nobody owns. We reproduce it, fix it, and then ask the question that matters more than the fix: is this the only place we have made this mistake? A bug that appears once in a codebase has usually appeared more than once, and a fix that closes one instance and leaves four is not a fix.

We also check whether it was ever exploited, using our access and audit logs, and we write down what our logs could and could not tell us. Where a report shows we could not have answered that question, closing that gap is part of the fix rather than a follow-up we may or may not get to.

9. Rewards and credit

We do not pay bounties today. Alder is a small, independently owned company selling to charities, and we would rather tell you that plainly than advertise a reward we would then argue about. If that changes, this section changes with it and the date at the top of the page will say when.

What we do offer:

• Public credit on this page, in the wording you choose, or no credit at all if you would rather.
• A written summary of what we changed, which is often the useful thing for a portfolio or a CVE record.
• A reference for an employer or a client, if that helps you.
• A free workspace of whatever size your testing needs, for as long as you are working with us.

With thanks to

Nobody yet — this programme opened in September 2026. This list is people who have reported a genuine issue to us and asked to be named. We will not pad it out.

10. This policy

This policy is published by Alder CRM Limited. It is the “responsible disclosure programme” referred to in paragraph 3(h) of Schedule 3 (Acceptable Use Policy) of the Customer Agreement, which permits testing of the service under this policy and prohibits it otherwise. It sits alongside our Security & Data Protection page, our Privacy Policy and our sub-processors list.

We may update it. Changes apply from the moment they are published and are not retrospective: a report made in good faith under the version of this page that was live at the time is judged against that version. Personal data you send us in a report is handled under our Privacy Policy and kept for as long as we need it to fix the issue and to keep an accurate record that we did.

Alder CRM Limited
Security reports: security@aldercrm.com
Everything else: hello@aldercrm.com
Registered office: The Brew, 1st Floor, Eagle House, 163 City Road, London, EC1V 1NR
Company registration: England and Wales, No. 17116559