Privacy Policy

What we store, and why it’s safe

We hold as little of your personal data as possible, keep what we do hold encrypted, and don’t share it.

Most of what mySites.guru stores about your sites is integers and a handful of strings, such as the platform name or a preference value. When you revoke our access or cancel, your sites keep working exactly as before, because we don’t own your data and never did.

We are registered with two Information Commissioners (UK and Jersey, Channel Islands), our connector is open source and GPL-licensed, and we’ve operated under these rules for over a decade.

Questions? Get in touch. A human replies.

1. Awareness

Everyone building and running mySites.guru is GDPR-aware. The service is owned by Blue Flame Digital Solutions, a UK company.

Code deployed to any platform is reviewed by the Data Controller named below. That’s a second pair of human eyes on every change, whether the author is staff or a contractor.

2. Information we hold

We store the minimum needed to run the service, covering two groups:

• 2.1 Customers (the operators using mySites.guru)
• 2.2 Customers’ Joomla and WordPress sites (your end users)

We don’t share or resell any user data beyond what’s described on this page.

2.1 Information held on our users

What we collect

Strictly what the service needs:

• Email address
• First and last name
• Full invoice address
• VAT number, country, and status
• Social login IDs (Google, GitHub, Facebook) if you use them
• Twitter name (deprecated, retained for old accounts)
• IP address and timezone
• Card details including optional billing address (handled by Stripe)
• Username and password (one-way hashed, never stored in plain text)

Who collects it

mySites.guru, controlled by the Data Controller listed below.

How

You enter it during sign-up and while using the service. We process it to deliver the service you signed up for (see Lawful basis below). A handful of third parties such as MailChimp enrich it with metadata like your mail client when they serve our email.

Why

To provide the service you signed up for: authentication, billing, debugging, and anonymous stats we use to improve the product.

Who we share it with

The full list is in the Vendors we use section above.

Likely effect

The service runs, billing automates, and you can unsubscribe from any mailings at any time.

2.2 Information held on your connected websites

The short version: almost none, and never your site’s content.

This is the part most people want pinned down before they connect a client’s production site, so here is exactly what crosses the wire.

Routine monitoring sends counts, not records. A snapshot is integers, booleans and short version strings: your PHP version, how many Super Users exist, how many users have never logged in, whether the root .htaccess is present, your database prefix, free disk space. Every query a snapshot runs against your site’s user table is a COUNT(*), so the automatic monitoring that runs day to day never receives a row from it.

Two tools do read user records, when you use them. The Universal User Manager exists so you can search and edit the user accounts on your sites, so a search returns the matching records: id, name, username, email address, registration date, last visit, and whether the account is blocked. On WordPress it returns id, name, username, email address and roles. No password is returned, and results are streamed to your browser rather than stored by us. The MD5 hashed password audit finds accounts still using the obsolete MD5 format so you can force a reset, and returns the id, username, name and the hash itself for up to 100 accounts; to show you what those weak hashes resolve to we use an external lookup service and a cache. Both need a deliberate action by a signed-in user of your account, and neither runs in the background.

File hashes are computed on your server. The audit walks your filesystem and computes an MD5 hash of every file. Those hashes and paths are written to a table in your own site’s database, on your own hosting, and it is the totals that reach us: how many suspect files, how many hacked files, whether the scan errored. Hashes do come back to the console for display when you ask for them: opening a report, browsing the file manager, or running AI analysis fetches the relevant paths and hashes from your server so we can show them to you. What we do not hold is a standing copy of your whole file listing.

We do not pull your site’s content, and nothing is pulled before you ask. Nothing dumps your tables or exports your posts, articles, customers or orders. What can be pulled, on an explicit action by you, is the audit’s own output: the file names and metadata the scan cached on your server, a list of flagged or hacked files, or a CSV export of those results. Those are your audit results, fetched because you asked for them.

File contents move only when you click something. One mechanism transfers a file’s contents to us, and it needs a deliberate action by a signed-in user of your account: opening that file in the file manager or editor, or submitting that specific file for AI malware analysis. The content travels over the encrypted connector channel, is used to draw the editor or build the analysis request, and is not written to our database.

AI analysis is off until you switch it on. It is disabled by default and enabled per account. When you enable it and submit a file, that file’s contents, name and size go to Anthropic or OpenAI, whichever engine you picked, and their verdict comes back. What we store is the verdict and its metadata: filename, path, size, MD5, provider, model, risk level, findings, tokens and cost. Not the file. We deliberately do not save the prompt. You can also supply your own Anthropic or OpenAI key, in which case your own contract with them governs it.

Verdicts are shared, your files are not. We cache each analysis against the file’s MD5 hash and reuse it across the platform. That is the point of it: once a file has been judged malicious or clean, every customer running that same file gets the verdict straight away, without it being sent for analysis again. What is shared between customers is the hash and the verdict. Your file’s contents are not retained, not shared, and never shown to another customer.

We do not store your backups, and we do not choose where they go. We never receive, download or store a backup archive. When you run a backup we trigger and poll your own backup software through its API on your own hosting, and record the run status, nothing more. Where the archive ends up is decided by the backup profile you configured: it may stay on your server, or your profile may send it on to storage you picked elsewhere. That configuration is yours. What happens to the data at that destination is your responsibility, not ours. We run the trigger, we do not pick the destination, and we have no access to it.

Screenshots are of the public homepage. To draw a thumbnail we send your site’s public URL to our screenshot vendor, which visits it as any anonymous visitor would and returns a PNG of the public homepage. No credentials are used and nothing behind a login is captured. That PNG is stored in Amazon S3 in Ireland at an unguessable path, and is readable from that path by anyone who has it, in the same way the homepage it shows is already public to anyone.

Who does the data protection law make responsible for what? For your own account data, we are the Controller. For personal data on the sites you connect, you are the Controller and we are your Processor. If you manage sites for clients, you are usually your client’s Processor and we are your Sub-processor. That relationship, including sites you manage for third-party clients, is covered by our Data Processing Agreement, which applies to every customer automatically.

3. Communicating privacy information

This page is it.

Everything we have to say on the matter lives here, and we keep it current.

4. Your rights under GDPR

Right to be informed

This page. You’re reading it.

Right of access

Everything we hold on you is in your mySites.guru account and exportable on demand from your account privacy page.

Right of rectification

Contact us and we’ll update it.

Right of erasure

Contact us. We’ll act within legal timescales.

Right to restrict processing

We only process the data described on this page.

Right to data portability

Use the Export button in your account, any time.

Right to object

Contact us.

Right not to be subject to automated decision-making or profiling

We don’t do that, and we never will.

5. Subject access requests

We reply to every access request, yes or no, within a week. The legal limit is one month. Free for paid and free accounts alike.

Or skip the queue and export your personal data yourself from your mySites.guru account. Same information, instant.

5.1 Complaints

If you think we’ve mishandled your personal data, tell us first and we’ll try to put it right.

• Email the Data Controller at phil@phil-taylor.com, or use the contact form.
• We’ll acknowledge your complaint within 30 days and give you a considered reply as quickly as we can.

Under the Data (Use and Access) Act 2025 you have the right to complain to us directly, and we have a duty to handle it. If you’re still not satisfied, you can escalate to the UK’s Information Commissioner’s Office, or to the Jersey Office of the Information Commissioner. You can go straight to the regulator, but we’d rather have the chance to fix it first.

6. Lawful basis for processing

We process your personal data on three lawful bases: to deliver the service you signed up for (Article 6(1)(b), performance of a contract), for our marketing email (Article 6(1)(a), consent), and to protect the platform against fraud and abuse (Article 6(1)(f), legitimate interests).

Connecting a site to mySites.guru is a deliberate, multi-step action by a site super-admin who is also the account holder. It instructs us to operate the connector on that site so we can deliver the service you asked for.

Signing up adds you to our mailing list. That part is consent: you can change or withdraw it at any time in your notification preferences.

Retaining a minimal record to defend the platform

You may have the right to be forgotten, but we keep the right to defend ourselves and our platform.

mySites.guru is a technical service that makes effectively unlimited automated HTTP calls to remote servers and websites on behalf of our users, around the clock. Because that activity reaches other people’s infrastructure, we and our users have to be able to stand behind it. If it is ever challenged, whether by a genuine legal query, attack or lawsuit, or by a malicious accusation, we must be able to show what was done, when, and by whom, and defend both our own actions and those of our users.

As a business-to-business service we hold very little personal data, and only what you gave us. This may include any name, moniker or username provided to us by you, your email address and IP addresses. Even after a deletion request, we reserve the right to retain that minimal amount where we genuinely need it to:

• Defend against legal claims, and prove who used the platform. We connect to remote servers and websites on your instruction, so if law enforcement or a court asks, we have to be able to show who made a given request, including handing our logs to a court if we are lawfully ordered to.
• Prevent and prove fraud, both financial and technical. Financial such as card testing and card washing; technical such as proving whether our platform was, or was not, used in a cyber attack, and by whom, or defending an accusation or claim of defamation arising from it.
• Protect ourselves and our other customers from repeated abuse, such as personal attacks or the abuse of free trials.

Where we retain data after a deletion request we apply strict data minimisation and strict confidentiality. The personal data we keep (any name, moniker or username you provided, your email address and IP addresses) stays fully encrypted and at rest, is not accessed unless one of the situations above actually arises, and is removed entirely once we are satisfied that no further abuse, fraud or legal defence is possible.

Some of the technical data we keep is stored only as a blind hash, not as encrypted data. A blind hash is a one-way fingerprint: we cannot reverse it to recover the original value, we can only re-hash a value supplied to us in future and check whether it matches. Domain names previously connected to the service are held this way, and IP addresses may also be blind-hashed after a period of time to anonymise them. This lets us protect every user and the platform from abuse (for example, stopping a locked domain from being re-added, or recognising a repeat abuser by IP) without keeping the original values in any recoverable form. Hashing is not encryption: for this data we hold only the hash, never an encrypted copy of the original.

This is permitted under GDPR: the right to erasure does not apply where holding the data is necessary to establish, exercise or defend a legal claim (Article 17(3)), and we rely on our legitimate interests in preventing fraud and abuse (Article 6(1)(f)). Relying on these does not exempt us from the rest of GDPR, so we still minimise what we hold and keep it confidential and secure.

7. Consent

Where we rely on consent, it’s explicit and specific: you give it for our marketing email when you sign up, and you can withdraw it at any time in your notification preferences.

We never source personal data from anywhere else, manually or automatically. You give us the data, or we don’t have it.

Installing the connector on a site you run instructs us to operate it on your behalf, and we don’t prompt you each time it runs. That is part of delivering the service (see Lawful basis), not a separate consent.

8. Children

mySites.guru is a business-to-business service and isn’t offered to children. We don’t age-gate sign-up.

9. Data breaches

We actively monitor for unauthorised access and harden our systems continuously to reduce the attack surface.

Security reports go to phil@phil-taylor.com. We process them same-day and pay bounties for valid findings.

What we do to reduce the attack surface

• Aggressive firewalls and network isolation throughout the infrastructure.
• No public internet access to our servers. Only Phil Taylor can reach the live platform.
• We track CVEs in every library we depend on and patch as soon as fixes land.
• 2FA on every sensitive third-party account.
• Data stores and sensitive backends live on separate servers behind separate firewalls.
• Backups run every 3 hours, GPG-encrypted, held for at most one month, stored off-site.
• Encryption keys live on different physical hardware to the database.
• Multiple systems would have to be hacked, and encryption broken, to issue a single valid request to a connected site.

10. Data protection by design

Security comes first when we design anything new. We protect the integrity of the system, then the data it stores.

Our engineers know software and network security well. That shapes the architecture before a line of code is written.

11. Data Controller

Under GDPR we operate with a Data Controller rather than a Data Protection Officer:

12. International & data transfers

mySites.guru may, through its users, process data from individuals across the EU.

The service is run by Blue Flame Digital Solutions Limited, a UK company managed from Jersey, Channel Islands (outside the EU). Our main establishment is Jersey, so our supervisory authority sits there, and the UK’s Information Commissioner also applies.

Both jurisdictions hold European Commission adequacy decisions, so personal data can flow from the EEA to us without any additional transfer mechanism. The UK decision was renewed on 19 December 2025 and runs to 27 December 2031. Jersey holds decision 2008/393/EC, reaffirmed by the Commission’s review of January 2024.

Blue Flame Digital Solutions Limited is registered with the UK Information Commissioner and the Jersey Information Commissioner, and fully complies with the Data Protection (Jersey) Law 2018.

Some of the vendors listed above are based outside the UK, including in the United States. Where we transfer your personal data outside the UK, we rely on the UK’s approved safeguards: the International Data Transfer Agreement (IDTA) or the UK Addendum to the EU Standard Contractual Clauses, and, for US vendors certified under it, the UK-US Data Bridge. We only pass the minimum data needed, and only to vendors with their own published GDPR commitments (linked in the vendor list above). The Data (Use and Access) Act 2025 keeps these safeguards valid and adds a risk-based test for transfers, which ours already meet.

The full list of vendors, the personal data each one receives, where it processes it, and the transfer mechanism we rely on, is in Annex A of our Data Processing Agreement.