Website GlowupsBy Caro

How we protect our clients and their data

Website Glowups by Caro. Security and resilience plan. Version 3.3, 2 November 2026. Updated following an external AI-assisted review.

Every check is marked Live Planned To set up or To check. NEW marks anything new or changed since Version 1.

Main workflow map

Needed now Lanes 2 to 8 protect Website Glowups today. Before the portal launches Lane 1 is the client portal, all planned. Until it is ready and tested, first clients use the onboarding form, email and Stripe's own billing page.

Client sign inOur future
client portal1Before the portal launches
  1. 1.1NEWFace ID or fingerprintPlanned
  2. 1.2NEWEmailed sign in linkPlanned
  3. 1.3No passwords storedPlanned
  4. 1.4New sign in alertPlanned
  5. 1.5NEWSessions can be endedPlanned
  6. 1.6Ring fenced dataPlanned
  7. 1.7NEWSeparation testPlanned
  8. 1.8Encrypted at restPlanned
  9. 1.9NEWIndependent security testPlanned
Our team accessCaro, future staff and
every business account2Needed now
  1. 2.1NEWTwo step sign in, alwaysClient account, live Others, to set up
  2. 2.2NEWA different password everywhereTo set up
  3. 2.3NEWRecovery codes kept safeLive
  4. 2.4NEWLimited publishing keyTo check
  5. 2.5NEWOld access removedTo set up
  6. 2.6One login per personPlanned
  7. 2.7Role based permissionsPlanned
  8. 2.8Activity logPlanned
Data protectionClients, finders
and leads3Needed now
  1. 3.1Hold as little as possiblePlanned
  2. 3.2Card details never touch usPayments, live Billing page, planned
  3. 3.3Encrypted in transitLive
  4. 3.4UK GDPR and the ICORegistration, live Trading name, to set up
  5. 3.5Privacy notice and termsTo set up
  6. 3.6NEWRetention scheduleTo set up
  7. 3.7NEWClient website enquiriesTo set up
  8. 3.8NEWAgreements that matchTo set up
Forms and
bot protectionWebsite checker
and booking form4Needed now
  1. 4.1Invisible bot checkLive
  2. 4.2Hidden honeypot fieldLive
  3. 4.3Rate limits per visitorLive
  4. 4.4NEWFlagged, never acted onLive
  5. 4.5NEWChecked on the serverTo set up
  6. 4.6NEWNo code injectionTo set up
  7. 4.7NEWSafe error messagesTo set up
  8. 4.8NEWUpload limitsTo set up
Hosting and
attack protectionWebsites and email5Needed now
  1. 5.1Cloudflare networkLive
  2. 5.2Simple static websitesLive
  3. 5.3Client sites kept separatePlanned
  4. 5.4NEWSeparate account for client sitesOpened, live
  5. 5.5Business emailLive
  6. 5.6Email authenticationTo set up
Backups and recoveryRecovering from
any failure6Needed now
  1. 6.1Version control on GitHubChecker, live All sites, planned
  2. 6.2NEWNightly backups of everythingPlanned
  3. 6.3NEWBackups that cannot be wipedPlanned
  4. 6.4NEWOne real restore, timedDo now, to set up
  5. 6.5NEWMove host within hoursTarget, planned
  6. 6.6Uptime monitoringStage 1, planned
  7. 6.7Written recovery planPlanned
Checks and reviewsOngoing reviews
and maintenance7Needed now
  1. 7.1Quarterly access reviewPlanned
  2. 7.2Updates kept currentPlanned
  3. 7.3NEWOne page incident checklistDo now, to set up
  4. 7.4NEWBreaches recorded and reportedTo set up
AI tools, domains
and developmentHow we build and
look after sites8Needed now
  1. 8.1NEWNo secrets in AI chatsDo now, to set up
  2. 8.2NEWOnly the access neededDo now, to set up
  3. 8.3NEWReview before going liveDo now, to set up
  4. 8.4NEWNo tool can change every siteDo now, to set up
  5. 8.5NEWKnow where data goesDo now, to set up
  6. 8.6NEWTest copies before livePlanned
  7. 8.7NEWDomain handoverDo now, to set up
  8. 8.8NEWFive minute launch checklistTo set up
  9. 8.9NEWAI tool's Cloudflare connectionTo set up
  10. 8.10NEWKeys and connected apps reviewedDo now, to set up
  11. 8.11NEWAI tool on the client account onlyClient, live Main, planned

Numbers match the full detail on the following pages.

Plan summary

NEW

Priority consideration

If someone got into our main account tomorrow, how many client websites could they change?

The current position. All of them, as every site sits in one Cloudflare account. Fixing this is our first priority, and the five step fix follows the map.

Second consideration

If the AI tool's connection were compromised, could someone create a new key even after old ones are deleted?

The current position. Yes, for the main account. That access is removed once the sites have moved to the new client account.

Found in a read only check on 2 November, with nothing changed. The AI development tool reaches Cloudflare through a permanent authorised connection that can create new keys. Three long lived keys with no expiry date are in the account.

Five step fix, without interrupting live sites

  1. Turn on two step sign in or passkeys on every business accountClient, live Others, to set up
  2. Review the three long lived keys with Caro, and check every other connected app that can reach the main accountDo now, to set up
  3. Open a separate Cloudflare account for client sites, before taking significant numbers of paying clientsOpened 2 Nov, live
  4. Move client sites across one at a time, testing each oneIn progress
  5. Connect the AI tool only to the client account and remove its access to the main accountLinked, live Removal, planned

To check Whether Cloudflare allows a key limited to one Website Glowups project for every publishing step. If not, the separate client account is the likely safest low cost route.

NEW

Do now, low or no cost

  1. Passkeys or two step sign in on the main Cloudflare account, GitHub, our domain registrar, Microsoft 365, Stripe and development tools 2.1
  2. A different password for every service 2.2
  3. Remove old access and old access keys 2.5
  4. AI working rules 8.1 to 8.5
  5. Review the long lived keys and other connected apps 8.10
  6. Domain handover process 8.7
  7. One page incident checklist with an offline copy 7.3
  8. Test one real restore on the first client site, and time it 6.4

All of these are To set up. None is marked Live until it has been checked on the real accounts.

NEW

Two layers of security

  • Needed now Website Glowups security. Our accounts, data, forms, hosting, backups, checks and AI tools. Sections 2 to 8.
  • Before the portal Client portal security. Section 1, all Planned. Until the portal is ready and tested, first clients use the onboarding form, email and Stripe's own billing page.
NEW

Security roadmap

Stage 1

First paying clients, now

Secure accounts, domain process, AI rules, backups, incident checklist, basic automated uptime monitoring (free service).

About £0 to £50

Stage 2

First 10 to 50 sites

Automated backups, restore testing, fuller monitoring, staff permissions.

Allow about £10 to £50 a month

Stage 3

Portal and a larger client base

Separation testing, secure sign in, access logs, independent security test.

Budgeted separately

These are planning allowances, not quotes. We check what our existing services already include before buying anything new.

NEW

What we are not spending money on yet

  • Expensive monitoring software
  • Enterprise password managers
  • A full time security consultant
  • Independent testing of every simple site
  • Enterprise backup platforms
  • Complex identity systems before the portal
  • Security tools that duplicate each other

We are keeping the independent security test for the portal. If it is unaffordable, the portal launches with fewer features rather than untested.

Incident response

  1. Detect through uptime and sign in alerts.
  2. Contain by removing access or switching host.
  3. Notify affected people promptly, following our one page checklist, kept offline too.
  4. Review the incident and update the plan.

NEW Every data breach is recorded. Breaches likely to put people's rights at risk are reported to the ICO within 72 hours of us becoming aware.

NEW

Questions for our security adviser

  1. Which backup provider would you recommend, so backups stay safe even if our main accounts are affected?
  2. How should we scope the limited publishing key for client sites?
  3. What cyber insurance cover should a business like ours hold?
  4. How long should we keep former clients' records and backups?
  5. Who could do the portal's independent test, and at what stage of the build?

What we hold

  • We keep contact and business details, website files, booking and change requests.
  • We never keep card details or client passwords.
  • Client website enquiries we aim to forward, not store. To be decided and written down, see 3.7.

Every check in detail

Client portal security, before the portal launches All Planned. Until then, first clients use the onboarding form, email and Stripe's own billing page.

1 Client portal sign in and separation Client portal at my.websiteglowups.co.uk 1.1 NEW Face ID or fingerprint Passkeys are the main way in. They strongly resist phishing, though lost devices and account recovery still need care. Planned 1.2 NEW Emailed sign in link The backup option. It expires after 15 minutes and cannot be reused. Planned 1.3 No passwords stored So there are none to leak, guess or reuse. Planned 1.4 New sign in alert An email every time someone signs in, so clients can spot any unexpected access promptly. Planned 1.5 NEW Sessions can be ended Sign out on all devices with one tap, plus limits on repeated sign in attempts. Planned 1.6 Ring fenced data Each client only ever sees their own business. Planned 1.7 NEW Separation test An automated test with two test clients proves neither can see the other's records, even by changing a link or reference. Required before real data. Planned 1.8 Encrypted at rest Client portal data stored encrypted. Moved here from section 3. Planned 1.9 NEW Independent security test An outside expert tests the portal before launch. If that is unaffordable, we launch with fewer features rather than untested. Planned

Website Glowups security, needed now Sections 2 to 8. Numbers match the full list in words.

2 Our accounts and team access Caro, future staff and every business account 2.1 NEW Two step sign in, always On for the new client Cloudflare account, with app and email codes. Still to set up on the main account, Microsoft 365, GitHub and Stripe. Client account, live Others, to set up 2.2 NEW A different password everywhere Every service has its own password, kept in the secure password manager we already use. To set up 2.3 NEW Recovery codes kept safe Stored in a paid password manager with emergency access contacts set up, away from the accounts they unlock. Live 2.4 NEW Limited publishing key A key that can only publish Website Glowups sites. Whether Cloudflare allows this for every publishing step is still to be checked. To check 2.5 NEW Old access removed Old logins, tools and access keys checked and removed. Access ends the day someone leaves. To set up 2.6 One login per person Every person has their own login. No shared accounts. Planned 2.7 Role based permissions Each person only sees the areas their role needs. Planned 2.8 Activity log A record of who did what, and when. Planned
3 Data protection Clients, finders and leads 3.1 Hold as little as possible We keep only the personal data we need. Planned 3.2 Card details never touch us Payments and promo codes run on Stripe's own secure pages. The portal billing page will too. Payments, live Billing page, planned 3.3 Encrypted in transit HTTPS on every website, form and page. Live 3.4 UK GDPR and the ICO Registered with the ICO. The trading name is being added to the registration. Registration, live Trading name, to set up 3.5 Privacy notice and terms Updated for the portal, with consent records kept. To set up 3.6 NEW Retention schedule What we keep, why, and when it is deleted. Covers enquiries, website content, change requests, backups and former clients' records. To set up 3.7 NEW Client website enquiries To decide and write down. Our aim is to forward them rather than store them, keeping as little as possible. To set up 3.8 NEW Agreements that match Client agreements and data processing terms that match how the service operates. To set up
4 Forms and bot protection Website checker and booking form 4.1 Invisible bot check Cloudflare Turnstile on the website checker and the booking form. Live 4.2 Hidden honeypot field A trap field only robots fill in. Those entries are automatically discarded. Live 4.3 Rate limits per visitor Website checker 10 an hour. Booking form 5 an hour. Live 4.4 NEW Flagged, never acted on A flagged booking request is only emailed to Caro, marked “Check, may be spam”. Nothing is booked automatically. Live 4.5 NEW Checked on the server Every form checks what is sent on the server, not only in the browser. To set up 4.6 NEW No code injection Nothing typed into a form can inject code into our systems. To set up 4.7 NEW Safe error messages Error messages never reveal anything private. To set up 4.8 NEW Upload limits Limits on the type and size of any file uploaded through a form. To set up
5 Hosting and attack protection Websites and email 5.1 Cloudflare global network Sites served from hundreds of locations, with attack protection and HTTPS built in. Live 5.2 Simple static websites No plugins to update and no public admin login on client sites. Our standard build. Live 5.3 Client sites kept separate Websites run apart from the portal, so a portal problem never takes them down. Planned 5.4 NEW Separate account for client sites Opened on 2 November 2026, with two step sign in on. No sites in it yet. Moving them across is in progress. Opened, live 5.5 Business email Microsoft 365 Exchange for all company email. Live 5.6 Email authentication DKIM and DMARC, so others cannot easily send email pretending to be us. To set up
6 Backups and recovery Recovering from any failure 6.1 Version control on GitHub Every site's files kept with full history. In place for the website checker. Checker, live All sites, planned 6.2 NEW Nightly backups of everything Images, settings and form data as well as code, copied to a separate company in the UK or EU. Planned 6.3 NEW Backups that cannot be wiped A problem in our main hosting or GitHub account must not be able to delete the backups. Planned 6.4 NEW One real restore, timed Restore the first client site to a test location, check it works and time it. Do now, to set up 6.5 NEW Move host within hours A target, not yet tested. Any site moved to another host within hours. Target, planned 6.6 Uptime monitoring Basic automated monitoring, using a free service. Needed now. Stage 1, planned 6.7 Written recovery plan Our recovery plan, tested at least once a year. Planned
7 Checks and reviews Ongoing reviews and maintenance 7.1 Quarterly access review Check who can see what, and remove anything not needed. Planned 7.2 Updates kept current Software and dependencies kept up to date. Planned 7.3 NEW One page incident checklist Who notices, who acts, who tells clients and where the instructions are. An offline copy kept too. Do now, to set up 7.4 NEW Breaches recorded and reported Every data breach is recorded. Breaches likely to put people's rights at risk are reported to the ICO within 72 hours of us becoming aware. To set up
8 AI tools, domains and development How we build and look after sites NEW LANE 8.1 NEW No secrets in AI chats No client passwords, private keys or payment details in AI conversations. Do now, to set up 8.2 NEW Only the access needed AI development tools only get access to the projects they need. Do now, to set up 8.3 NEW Review before publishing Changes to important systems are reviewed before they go live. Do now, to set up 8.4 NEW No unrestricted changes No AI tool can make unrestricted changes across all client sites. Do now, to set up 8.5 NEW Know where data goes Check what client information goes to AI providers and how they handle it. Do now, to set up 8.6 NEW Development kept apart New work is tried on a test copy first, never straight on a live client site. Planned 8.7 NEW Domain handover process The client stays the registered owner and we get only the access needed. We record where each domain is registered and when it renews, and agree what happens if a client cancels. Domain logins never go in an ordinary spreadsheet. Do now, to set up 8.8 NEW Five minute launch checklist For every new site we confirm the domain, HTTPS, forms, access and backup. To set up 8.9 NEW The AI tool's Cloudflare connection A permanent authorised app connection, not a key. It can create new keys itself, so deleting temporary keys alone does not limit access. To review and narrow. To set up 8.10 NEW Keys and connected apps reviewed Three keys with no expiry date. Caro to confirm which are still needed. Every other connected app that can reach the main account is checked too. Do now, to set up 8.11 NEW AI tool on the client account only Connected on 2 November 2026 and checked. It sees only the new client account. Older connections to the main account stay until the move is done. Client account, live Main account removed, planned

Every check, in words

  1. Client portal security, before the portal launchesUntil the portal is ready and tested, first clients use the onboarding form, email and Stripe's own billing page.
  2. 1. Client portal sign in and separationClient portal at my.websiteglowups.co.uk
  3. 1.1
    NEW

    Face ID or fingerprint

    Passkeys are the main way in. They strongly resist phishing, though lost devices and account recovery still need care.

    Planned
  4. 1.2
    NEW

    Emailed sign in link

    The backup option. It expires after 15 minutes and cannot be reused.

    Planned
  5. 1.3

    No passwords stored

    So there are none to leak, guess or reuse.

    Planned
  6. 1.4

    New sign in alert

    An email every time someone signs in, so clients can spot any unexpected access promptly.

    Planned
  7. 1.5
    NEW

    Sessions can be ended

    Sign out on all devices with one tap, plus limits on repeated sign in attempts.

    Planned
  8. 1.6

    Ring fenced data

    Each client only ever sees their own business.

    Planned
  9. 1.7
    NEW

    Separation test

    An automated test with two test clients proves neither can see the other's records, even by changing a link or reference. Required before real data.

    Planned
  10. 1.8

    Encrypted at rest

    Client portal data stored encrypted. Moved here from section 3.

    Planned
  11. 1.9
    NEW

    Independent security test

    An outside expert tests the portal before launch. If that is unaffordable, we launch with fewer features rather than untested.

    Planned
  12. Website Glowups security, needed now
  13. 2. Our accounts and team accessCaro, future staff and every business account
  14. 2.1
    NEW

    Two step sign in, always

    On for the new Website Glowups Cloudflare account since 2 November 2026, with an authenticator app and email codes. Still to set up on the main account, GitHub, our domain registrar, Microsoft 365, Stripe and development tools.

    Client account, liveOthers, to set up
  15. 2.2
    NEW

    A different password everywhere

    Every service has its own password, kept in the secure password manager we already use.

    To set up
  16. 2.3
    NEW

    Recovery codes kept safe

    Recovery codes stored in a paid password manager with emergency access contacts set up, away from the accounts they unlock. Codes for each other account go there as two step sign in is turned on.

    Live
  17. 2.4
    NEW

    Limited publishing key

    A key that can only publish Website Glowups sites. Whether Cloudflare allows this for every publishing step is still to be checked.

    To check
  18. 2.5
    NEW

    Old access removed

    Old logins, tools and access keys checked and removed. Access ends the day someone leaves.

    To set up
  19. 2.6

    One login per person

    Every person has their own login. No shared accounts.

    Planned
  20. 2.7

    Role based permissions

    Each person only sees the areas their role needs.

    Planned
  21. 2.8

    Activity log

    A record of who did what, and when.

    Planned
  22. 3. Data protectionClients, finders and leads
  23. 3.1

    Hold as little as possible

    We keep only the personal data we need.

    Planned
  24. 3.2

    Card details never touch us

    Payments and promo codes run on Stripe's own secure pages. The portal billing page will too.

    Payments, live Billing page, planned
  25. 3.3

    Encrypted in transit

    HTTPS on every website, form and page.

    Live
  26. 3.4

    UK GDPR and the ICO

    Registered with the ICO. The trading name is being added to the registration.

    Registration, live Trading name, to set up
  27. 3.5

    Privacy notice and terms

    Updated for the portal, with consent records kept.

    To set up
  28. 3.6
    NEW

    Retention schedule

    What we keep, why, and when it is deleted. Covers enquiries, website content, change requests, backups and former clients' records.

    To set up
  29. 3.7
    NEW

    Client website enquiries

    To decide and write down. Our aim is to forward them rather than store them, keeping as little as possible.

    To set up
  30. 3.8
    NEW

    Agreements that match

    Client agreements and data processing terms that match how the service operates.

    To set up
  31. 4. Forms and bot protectionWebsite checker and booking form
  32. 4.1

    Invisible bot check

    Cloudflare Turnstile on the website checker and the booking form.

    Live
  33. 4.2

    Hidden honeypot field

    A trap field only robots fill in. Those entries are automatically discarded.

    Live
  34. 4.3

    Rate limits per visitor

    Website checker 10 an hour. Booking form 5 an hour.

    Live
  35. 4.4
    NEW

    Flagged, never acted on

    A flagged booking request is only emailed to Caro, marked “Check, may be spam”. Nothing is booked automatically.

    Live
  36. 4.5
    NEW

    Checked on the server

    Every form checks what is sent on the server, not only in the browser.

    To set up
  37. 4.6
    NEW

    No code injection

    Nothing typed into a form can inject code into our systems.

    To set up
  38. 4.7
    NEW

    Safe error messages

    Error messages never reveal anything private.

    To set up
  39. 4.8
    NEW

    Upload limits

    Limits on the type and size of any file uploaded through a form.

    To set up
  40. 5. Hosting and attack protectionWebsites and email
  41. 5.1

    Cloudflare global network

    Sites served from hundreds of locations, with attack protection and HTTPS built in.

    Live
  42. 5.2

    Simple static websites

    No plugins to update and no public admin login on client sites. Our standard build.

    Live
  43. 5.3

    Client sites kept separate

    Websites run apart from the portal, so a portal problem never takes them down.

    Planned
  44. 5.4
    NEW

    Separate account for client sites

    Opened on 2 November 2026 for Website Glowups only, with two step sign in on. It holds no sites yet. Moving the sites across is in progress, one at a time, so one problem cannot reach everything.

    Opened, live
  45. 5.5

    Business email

    Microsoft 365 Exchange for all company email.

    Live
  46. 5.6

    Email authentication

    DKIM and DMARC, so others cannot easily send email pretending to be us.

    To set up
  47. 6. Backups and recoveryRecovering from any failure
  48. 6.1

    Version control on GitHub

    Every site's files kept with full history. In place for the website checker.

    Checker, live All sites, planned
  49. 6.2
    NEW

    Nightly backups of everything

    Images, settings and form data as well as code, copied to a separate company in the UK or EU.

    Planned
  50. 6.3
    NEW

    Backups that cannot be wiped

    A problem in our main hosting or GitHub account must not be able to delete the backups.

    Planned
  51. 6.4
    NEW

    One real restore, timed

    Restore the first client site to a test location, check it works and time it.

    Do now, to set up
  52. 6.5
    NEW

    Move host within hours

    A target, not yet tested. Any site moved to another host within hours.

    Target, planned
  53. 6.6

    Uptime monitoring

    Basic automated uptime monitoring using a free service, with alerts before a client notices. Needed now, in Stage 1.

    Stage 1, planned
  54. 6.7

    Written recovery plan

    Our recovery plan, tested at least once a year.

    Planned
  55. 7. Checks and reviewsOngoing reviews and maintenance
  56. 7.1

    Quarterly access review

    Check who can see what, and remove anything not needed.

    Planned
  57. 7.2

    Updates kept current

    Software and dependencies kept up to date.

    Planned
  58. 7.3
    NEW

    One page incident checklist

    Who notices, who acts, who tells clients and where the instructions are. An offline copy kept too.

    Do now, to set up
  59. 7.4
    NEW

    Breaches recorded and reported

    Every data breach is recorded. Breaches likely to put people's rights at risk are reported to the ICO within 72 hours of us becoming aware.

    To set up
  60. 8. AI tools, domains and development NEWHow we build and look after sites
  61. 8.1
    NEW

    No secrets in AI chats

    No client passwords, private keys or payment details in AI conversations.

    Do now, to set up
  62. 8.2
    NEW

    Only the access needed

    AI development tools only get access to the projects they need.

    Do now, to set up
  63. 8.3
    NEW

    Review before publishing

    Changes to important systems are reviewed before they go live.

    Do now, to set up
  64. 8.4
    NEW

    No unrestricted changes

    No AI tool can make unrestricted changes across all client sites.

    Do now, to set up
  65. 8.5
    NEW

    Know where data goes

    Check what client information goes to AI providers and how they handle it.

    Do now, to set up
  66. 8.6
    NEW

    Development kept apart

    New work is tried on a test copy first, never straight on a live client site.

    Planned
  67. 8.7
    NEW

    Domain handover process

    The client stays the registered owner and we get only the access needed. We record where each domain is registered and when it renews, and agree what happens if a client cancels. Domain logins never go in an ordinary spreadsheet.

    Do now, to set up
  68. 8.8
    NEW

    Five minute launch checklist

    For every new site we confirm the domain, HTTPS, forms, access and backup.

    To set up
  69. 8.9
    NEW

    The AI tool's Cloudflare connection

    A permanent authorised app connection, not a key. It can create new keys itself, so deleting temporary keys alone does not limit access. To review and narrow.

    To set up
  70. 8.10
    NEW

    Keys and connected apps reviewed

    Three keys with no expiry date, one for domains and two build keys for other projects. Caro to confirm which are still needed. Every other connected app that can reach the main account is checked too.

    Do now, to set up
  71. 8.11
    NEW

    AI tool on the client account only

    Connected to the new client account on 2 November 2026, and checked. It sees only that account and cannot see the main one. Its older connections to the main account stay until the move is done.

    Client account, liveMain account removed, planned