Security and service information

• The website holds no patient identifiable data and no clinical records, and connects to no clinical system
• Everything published is public information. There is no confidential data on the site by design
• Application processing and primary content storage are configured for the London region, though delivery and some service data are international
• Sign-in is protected by one password shared across your practice. There are no named user accounts and no multi-factor authentication today
• Each practice's content is isolated, and a session for one practice cannot touch another
• The code is open source under the MIT licence, so you can read exactly what it does, and keep running it if we stop trading

The single shared password is the significant limitation, and it is set out in full below rather than buried.

The website is a Next.js application hosted on Vercel, with its application region configured for London, and served to patients from Vercel's global edge network. Pages are rendered ahead of time and cached, which is why they load quickly and why traffic spikes are uneventful. Because delivery is global, cached copies and request logs are not confined to the UK.

Your content is stored as a single JSON document in Upstash Redis, in a London database region, keyed to your practice. There is no relational database, no WordPress, no plugins and no server for your practice to patch. That removes the largest single source of compromise in GP websites: an unmaintained plugin in a WordPress install.

The site has no comment system, no file uploads from the public, no patient login and no forms that write to anything a patient can reach.

Five suppliers, listed in full in the table below. Each is contracted as a processor with a published data processing agreement, and none may use your data for its own purposes.

We will tell you before we add another one to this list.

What protects your site today. One password, shared by your practice. Signing in creates a session cookie that is httpOnly, secure and sameSite=lax, and is cryptographically signed with the practice slug inside it, so a cookie issued for one practice cannot be replayed against another. Passwords are stored as salted scrypt hashes; we cannot read yours and neither can anyone who obtains the database. Sign-in attempts are rate limited. Sessions expire on their own. All traffic is HTTPS, and admin pages are excluded from search engines.

What it does not do, today:

• There are no named user accounts, so the site cannot tell you which member of staff made a change
• There is no multi-factor authentication
• There is no audit log of edits, beyond the date the site was last updated
• Removing one person's access means changing the password for everybody

What that means in practice. Treat the password the way you treat the code for the dispensary door: a practice credential, changed when someone leaves, never reused elsewhere, never written down where a patient or contractor could see it. Email us and we will change it, usually the same working day.

Whether that is acceptable is your practice's judgement, and the relevant question is what an attacker would gain. The worst case is defacement of a public noticeboard: embarrassing, visible immediately, and fixable in minutes because we hold your content and can restore it. No patient data is reachable, because there is none.

If your information governance policy requires named accounts, multi-factor authentication and an audit trail, we do not meet that today. Tell us and we will tell you honestly where it sits on our roadmap rather than sell you something that does not fit.

We host every practice on one deployment, so isolation between them is something we have to get right rather than something we get for free.

Content is stored under a key derived from your practice slug. Every admin request revalidates the session against the practice in the URL, and the slug is inside the signed cookie payload, so an authenticated session for one practice is rejected by another. Cache invalidation is keyed the same way, so one practice saving its opening hours cannot flush anyone else's site.

We test this deliberately before releases, by signing in to one practice and then attempting to read and write another practice's content and cache. If you want to try it against your own site, tell us first and we will not treat it as an incident.

Availability. Pages are statically generated and served from cache, so they stay up during most failures of anything behind them. If our storage is unreachable the site serves its last known content rather than an error. If the NHS news feed is unreachable, only the news section is affected. We do not offer a contractual uptime figure, for the reasons set out in our terms.

Backups. What is included is managed storage and platform replication: your content lives in Upstash, which persists and replicates it as part of their service. That protects against hardware failure. It does not give you a point-in-time copy to roll back to.

Independent scheduled backups are not currently included. Practices can download a complete restorable copy at any time, and we would rather say this plainly than let "backups included" imply we hold dated snapshots of your site. Scheduled encrypted exports into separate storage, with a defined retention period, are the next thing we intend to build here.

Your own copy. Because of that, taking your own is worth two minutes: Advanced settings in your admin panel has a Download my website button that gives you the entire site as one file. It is the same format the template loads, so it can be restored to our hosting or to your own. Take a copy after any substantial edit.

Recovery. If content were lost or wrongly edited, restoring from a file you hold takes minutes. Without one, we would restore whatever the storage layer can give us, which we cannot guarantee will be current.

The template is developed in the open. Every change is a public commit you can read.

Security fixes and dependency updates are applied to the hosted service by us, and deployed without you needing to do anything. Changes that alter what patients see, or that follow a change in NHS guidance, are described to customers by email before or when they ship.

Self-hosted deployments update when you choose to pull the changes in, which is covered in the deployment guide.

Report a security problem to [email protected] with "Security" in the subject. We acknowledge within one working day and will keep you updated until it is closed. We do not operate a paid bug bounty, but we will credit anyone who reports something responsibly if they want us to.

Please do not test against a live practice website. Fork the template and test your own copy: it is free, it is designed for it, and no patients are looking at it.

If a personal data breach affects your practice, we will tell you without undue delay and with enough detail for you to meet your own obligation to report to the ICO within 72 hours. Where we are the controller, we report it ourselves.

A fair question to ask a small supplier, so here is a real answer.

The template is published under the MIT licence at github.com/JLHITS/simple-surgery-template. That licence cannot be withdrawn from the versions already published. Your content downloads as one file that the template reads directly. Your domain is registered to your practice, or transferable to it on request.

So the recovery path if we disappeared is: take your file, deploy the free template to your own Vercel and Upstash accounts, point your domain at it. That is the same hour of work described in our deployment guide, and any competent local IT supplier could do it for you.

We would give 90 days' notice and a refund of the unused part of your year if we chose to stop, and we would help you move. But the point is that you do not have to take our word for that: you are not dependent on our goodwill, because the code and the content are already yours.

simplesurgery.co is built to the same standards as the template: semantic HTML, keyboard operable, visible focus states, no PDFs, no pop-ups and no accessibility overlay. We aim to meet WCAG 2.2 AA.

We have tested with keyboard navigation, automated tooling and screen reader spot checks. We have not commissioned an independent audit, so we describe this as tested rather than certified.

If something here is not usable for you, email [email protected] and tell us what happened. We will fix it and reply.

• Keep the password to your practice, and ask us to change it when someone leaves
• Publish nothing that identifies a patient
• Download a copy of your website after any substantial edit
• Tell us quickly if you think something has been accessed that should not have been

None of this is unusual. It is the same care you would take with any practice system, applied to something with a much smaller blast radius.