Data Processing Agreement

1. Definitions

“Controller”, “Processor”, “Data Subject”, “Personal Data”, “Processing” and “Supervisory Authority” have the meanings given to them in the GDPR.

“Connected Site”

Means a website you have connected to mySites.guru by installing our connector on it.

“Customer Personal Data”

Means Personal Data that we process on your behalf under this DPA, including any Personal Data reached through a Connected Site.

“Data Protection Law”

Means all data protection and privacy law applicable to the processing under the Agreement, including UK GDPR and the Data Protection Act 2018, EU GDPR (Regulation 2016/679), and the Data Protection (Jersey) Law 2018.

“Sub-processor”

Means any processor we engage to process Customer Personal Data on your behalf.

“Security Incident”

Means a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data.

2. Roles of the parties

2.1 Two distinct relationships. Our role differs depending on whose data it is:

• Your account data (your name, email address, billing address, VAT number, IP address). We are the Controller. This is not covered by this DPA; it is covered by our Privacy Policy. We decide the purposes and means because we need this data to run our business, bill you, and defend the platform.
• Personal data on your Connected Sites. We are the Processor, and you are the Controller. If you manage sites for your own clients, you are typically the Processor for your client and we are your Sub-processor. This DPA covers that relationship, and it is the part of the arrangement that most customers need documented.

2.2 This DPA covers your clients’ sites. For the avoidance of doubt, and because we are asked this often: this DPA applies to Personal Data reached through every site you connect, including sites you manage on behalf of third-party clients. It is not limited to the data in your own mySites.guru account.

2.3 Your obligations. You warrant that you have a lawful basis for the processing you instruct us to carry out, that you are entitled to connect each site you connect, and that you have given any notices and obtained any consents your own compliance requires. Where you act as Processor for your own client, you warrant that your contract with that client permits you to appoint us as a Sub-processor.

2.4 Our obligations. We process Customer Personal Data only on your documented instructions, as set out in section 3.

3. Scope and instructions

3.1 Documented instructions. The Agreement, this DPA, and your use of the service’s documented features together constitute your complete and final instructions to us. We process Customer Personal Data only:

• to provide the service you subscribed to;
• to take steps necessary for the performance of the Agreement, including support you ask us for;
• on your further written instruction, where that instruction is consistent with the Agreement; and
• where required by law, in which case we will tell you first unless the law forbids it.

3.2 The service is deliberately narrow. The connector is fixed-purpose code. It exposes a defined set of operations, it does not accept arbitrary instructions from us, and its full source is published under the GPL for you to inspect on any site you connect. Section 4 describes what it does with your data, including every case where content or user records are returned.

3.3 If an instruction breaks the law. If we believe an instruction from you infringes Data Protection Law, we will tell you without undue delay and may suspend that processing until it is resolved.

4. What we actually process

This section describes the real behaviour of the service. It is written to be checked against the connector source, not to be taken on trust.

4.1 Routine monitoring sends counts, not records. A snapshot returns counts, flags, version numbers and configuration values: the PHP version, the number of Super Users, the number of users who have never logged in, whether the root .htaccess exists, the database prefix, free disk space, and so on. Every query a snapshot runs against your site’s user table is an aggregate COUNT(*), so the automatic, background monitoring that runs day to day never receives a row from it.

4.1.1 Two tools do read user records, when you choose to use them. Both need a deliberate action by a signed-in user of your account. Neither runs in the background:

• The Universal User Manager lets you search for and edit the user accounts on your connected sites, which is the point of it. A search returns the matching user records: id, name, username, email address, registration date, last visit date, and whether the account is blocked. On WordPress it returns id, name, username, email address and roles. No password is returned. Results are streamed to your browser for that search and are not stored by us.
• The MD5 hashed password audit finds accounts still using the obsolete MD5 password format, so you can force a reset. It returns the id, username, name and the MD5 password 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.

Outside these two tools, and the file access described in 4.3 and 4.6, the routine monitoring works from counts, flags and hashes.

4.2 File hashes are computed on your server. The malware audit walks your filesystem and computes an MD5 hash of each file. Those hashes, paths, sizes and timestamps are written to a table in your own site’s database, on your own server, and it is the aggregate results (the number of suspect files, the number of hacked files, whether the scan errored) that sync back to us. 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.

4.3 File contents are transferred only when you ask. There is exactly one mechanism that transfers a file’s contents to us, and it runs only on an explicit action by a signed-in user of your account:

• you open a file in the in-app file manager or editor; or
• you submit a specific suspect file for AI malware analysis.

In both cases the content travels over the encrypted connector channel, is used to render the editor or build the analysis request, and is not written to our database. For AI analysis we deliberately do not persist the prompt.

4.4 We do not pull your site’s content, and nothing is pulled before you ask. No feature dumps your tables or exports your posts, articles, customers or orders. Routine database access is the aggregate counting described in 4.1 plus a handful of single configuration values. What can be pulled, and only on an explicit action by you, is the audit’s own output: the file names and metadata the scan cached in its table 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, and never before.

4.5 We do not store your backups, and we do not choose where they go. We never receive, download or store a backup archive. When a backup runs we trigger and poll your own backup software through its API on your own server, and we record the run status, nothing more. Where the archive ends up is decided entirely by the backup profile you have configured: it may stay on your server, or your profile may post-process it to storage you have chosen elsewhere. That configuration is yours. The handling, security and location of data at that destination is your responsibility as Controller, not ours. We operate the trigger; we do not select the destination and we have no access to it.

4.6 AI malware analysis is off unless you turn it on. AI analysis is disabled by default and enabled per account. When you enable it and submit a file, that file’s contents, its name and its size are sent to Anthropic or OpenAI, whichever engine you have selected, and their verdict comes back. Files over 200KB are sampled rather than sent whole. What we store is the analysis metadata: filename, path, size, MD5, the provider and model used, the risk level, the findings, token counts and cost. Not the file, and we deliberately do not keep the prompt. You may supply your own Anthropic or OpenAI API key, in which case your own contract with that provider governs the processing.

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

4.7 Screenshots. To show a thumbnail of a site in your dashboard, we send the site’s public URL to our screenshot vendor, which visits it the way any anonymous visitor would and returns a PNG of the public homepage. That PNG is stored in Amazon S3 in Ireland (eu-west-1) at an unguessable path and is served publicly from that path, in the same way the homepage it depicts is already public. No credentials are used to take it, and it captures only what a logged-out visitor sees.

4.8 Categories of Data Subject and Personal Data. Under normal operation the service processes no Personal Data from your Connected Sites, for the reasons in 4.1 to 4.5. Personal Data can enter the processing in two ways:

4.9 Special category data. The service is not designed for and must not be used to process special category data under Article 9, or criminal offence data under Article 10. If a file you open or submit happens to contain such data, you remain responsible for that decision.

4.10 Duration and subject matter. The subject matter is the provision of website monitoring, security auditing, malware scanning, update management and backup orchestration. Processing lasts for as long as your subscription is active and the site is connected, and ends as set out in section 8.

5. Confidentiality

Everyone we authorise to process Customer Personal Data is bound by a duty of confidentiality, whether by contract or by statute, that survives the end of their engagement. Access is limited to those who need it to deliver or support the service.

6. Security

6.1 Measures. We implement and maintain the technical and organisational measures in Annex B, which are designed to meet Article 32. We may update them, provided the overall level of security is not reduced.

6.3 Reporting to us. Security reports go to phil@phil-taylor.com. We triage them the same day and pay bounties for valid findings.

7. Sub-processors

7.1 General authorisation. You give us general written authorisation to engage the Sub-processors listed in Annex A.

7.2 Our obligations. For each Sub-processor we impose data protection terms no less protective than this DPA, and we remain fully liable to you for their acts and omissions as if they were our own.

7.3 Changes. Before adding or replacing a Sub-processor we will give you at least 30 days’ notice, by email and by updating Annex A on this page.

7.4 Your right to object. You may object to a new Sub-processor on reasonable data protection grounds by writing to us within 30 days of that notice. We will work with you in good faith to find a way forward. If we cannot, you may terminate the affected part of the service without penalty and receive a pro-rata refund of any fees paid in advance for it.

8. Deletion and return

8.1 When you delete a site. All data relating to that site, including every snapshot and audit result we hold for it, is removed from the live service immediately. We retain no access to a site once it is disconnected.

8.2 When your subscription ends. You can export your data at any time from your account, before or after cancelling. On termination we delete or return Customer Personal Data as you direct.

8.3 What we keep, and why. We may retain the minimum necessary where law requires it (tax records for up to six years where you have paid us), where it sits in an encrypted backup pending its retention expiry, or to establish, exercise or defend a legal claim under Article 17(3). Anything retained on those grounds is isolated from further processing, kept encrypted, and deleted when the reason for keeping it ends. Our retention practice is set out in full in our Terms.

9. International transfers

9.1 Where processing happens. The service runs on servers in London, United Kingdom. Screenshots and favicons are stored in Amazon S3 in Ireland (eu-west-1). Transactional email is sent through Amazon SES in London (eu-west-2). Blue Flame Digital Solutions Limited is registered as a company in the United Kingdom, and the business is owned and operated from Jersey, Channel Islands, which is our main establishment. Both jurisdictions hold European Commission adequacy decisions, so personal data may 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.

9.2 Transfers outside the UK and EEA. Some Sub-processors in Annex A are established outside the UK and EEA, principally in the United States. Where Customer Personal Data is transferred to them we rely on:

• the UK International Data Transfer Agreement (IDTA), or the UK Addendum to the EU Standard Contractual Clauses, for transfers subject to UK GDPR;
• the EU Standard Contractual Clauses, including Module Three (processor to processor) where we act as your Processor, for transfers subject to EU GDPR;
• the EU-US Data Privacy Framework and the UK-US Data Bridge, for vendors certified under them; and
• a transfer risk assessment, kept under review, for each such transfer.

We transfer the minimum data needed and only to vendors with their own published data protection commitments, linked in Annex A.

9.3 No Privacy Shield. This DPA does not rely on the EU-US Privacy Shield, which was invalidated in July 2020. Any earlier version of this document that referenced it is superseded.

10. Assisting you

10.1 Data subject requests. Taking into account the nature of the processing, we will assist you by appropriate technical and organisational measures in responding to requests from Data Subjects exercising their rights. Most of what you need is directly accessible in your account. If a Data Subject contacts us directly about data we process on your behalf, we will not respond substantively; we will refer them to you and tell you promptly, unless the law requires otherwise.

10.2 DPIAs and consultations. We will provide reasonable assistance with data protection impact assessments and prior consultations with a Supervisory Authority, so far as the information is available to us and relates to our processing.

10.3 Cost. Assistance under 10.1 and 10.2 is free for reasonable, occasional requests. We reserve the right to charge a reasonable fee for repetitive or manifestly excessive requests, and we will tell you before doing so.

11. Audit

11.1 Information. We will make available all information reasonably necessary to demonstrate compliance with Article 28, including written responses to security and data protection questionnaires. Ask, and you will get an answer from the person who wrote the code.

11.2 Inspections. We will allow for and contribute to audits and inspections conducted by you or an auditor you mandate. Because we are a small team running a live platform, an on-site or hands-on inspection requires at least 30 days’ notice, is limited to once in any 12-month period unless a Supervisory Authority requires otherwise or a Security Incident has occurred, must be subject to confidentiality, must not compromise other customers’ data or the security of the platform, and is at your cost.

11.3 Documentation. Annex B, this page, and our Privacy Policy are maintained as current documentation and are the first thing to read before requesting an audit.

12. Liability and general

12.1 Each party’s liability under this DPA is subject to the limitations and exclusions in the Agreement, save that nothing limits either party’s liability to a Data Subject under their data protection rights.

12.2 Except as changed by this DPA, the Agreement continues unchanged.

12.3 This DPA is governed by the law and jurisdiction stated in the Agreement, except where Data Protection Law requires otherwise.

12.4 This DPA version 2.0 supersedes all earlier versions, including the PDF dated 1 January 2021.

Annex A: Sub-processors

Current as at 24 July 2026. Being listed here does not mean we send a vendor your personal data. Several receive only technical or anonymous data, and some are used only if you opt into a feature. Each entry states what it actually receives.

On the public marketing website only, and only after you accept cookies in the banner, Google Analytics and a Meta pixel measure traffic and advertising. Neither runs inside the application at manage.mysites.guru.

Annex B: Technical and organisational measures

These are the Article 32 measures referenced in section 6.1.

Access control and authentication

• Your mySites.guru account password is stored one-way hashed and is never recoverable in plain text.
• Two-factor authentication is available to every account, including WebAuthn passkeys, and is enforced on every sensitive third-party account we hold.
• Sessions are cookie-based with strict SameSite, Secure and HttpOnly flags.
• Access to production systems is restricted to named personnel over key-based authentication on a private network. There is no public internet access to the application servers or the database.
• Administrative impersonation of a customer account is restricted, logged, and visible in the account’s own activity log.

Encryption

• All traffic to the platform is over TLS.
• Communication with the connector on your site is encrypted end to end; a request is only valid if it carries the correct signature for that specific site.
• Personal data is encrypted at rest in the database.
• Encryption keys are held on different physical hardware to the database.
• Backups are GPG-encrypted, held off-site, and retained for at most one month.

Network and infrastructure

• Firewalls and network isolation throughout, with data stores and sensitive backends on separate servers behind separate firewalls.
• The database is not reachable from the public internet.
• Multiple independent systems would have to be compromised, and encryption broken, before a single valid request could be issued to a connected site.

Resilience and continuity

• Backups run every three hours.
• The application runs as a replicated service across multiple containers.
• Infrastructure is reproducible from version-controlled build definitions.

Secure development

• Every code change deployed to any environment is reviewed by the Data Controller, whether written by staff or a contractor. That is a second pair of human eyes on every change.
• Dependencies are tracked for CVEs and patched promptly.
• Static analysis, coding standards and an automated test suite run against the codebase.
• Security is a design constraint before code is written, not a review step afterwards.

Data minimisation by design

• Routine, automatic monitoring returns counts, flags and version strings rather than content. This is an architectural decision, not a configuration setting.
• File hashes are computed on your server and held there. We fetch them for display when you ask, rather than keeping a standing copy.
• Site user records and file contents are returned only on an explicit user action, through the tools described in sections 4.1.1, 4.3 and 4.6, and are not persisted by us beyond the analysis metadata described there.
• AI analysis is off by default, per-file, and stores metadata rather than the file.
• Backup archives are never downloaded to our infrastructure.

Organisational

• Blue Flame Digital Solutions Limited is registered with both the UK Information Commissioner’s Office and the Jersey Office of the Information Commissioner.
• Everyone with access to the platform is bound by a written duty of confidentiality.
• The Data Controller named in section 12 is directly accountable for data protection and is reachable by name and email.
• Security reports are triaged the same day, with bounties paid for valid findings.

Incident history

Since mySites.guru launched we have had no major security incidents, and one minor theoretical issue, fixed the same day it was reported, with no data exposure.

Annex C: Description of processing (Article 28(3))