1. Our Commitment
RedSecLabs is committed to GDPR compliance. Guardian Gaze was designed with a privacy-first architecture and minimal data collection as the default. We process personal data only where necessary and with a valid legal basis.
2. Legal Basis for Processing
We process personal data under the following legal bases:
- Contract performance: To deliver the security scanning service you signed up for
- Legitimate interest: To improve our detection capabilities and protect users from threats
- Consent: For optional features like AI scanning, marketing emails, and analytics
3. Your Rights Under GDPR
As an EU/EEA data subject, you have the right to:
- Access: Request a copy of all personal data we hold about you
- Rectification: Correct inaccurate personal data
- Erasure: Request deletion of your personal data ("right to be forgotten")
- Portability: Receive your data in a machine-readable format
- Restriction: Restrict processing of your data in certain circumstances
- Objection: Object to processing based on legitimate interest
- Withdraw consent: Withdraw consent at any time without affecting prior processing
To exercise any of these rights, contactemail protected. We will respond within 30 days.
4. Data Processing Agreements
We maintain Data Processing Agreements (DPAs) with all sub-processors, including Anthropic (AI analysis) and our hosting providers. DPAs are available upon request.
5. International Transfers
Data may be transferred outside the EU/EEA for processing (e.g., AI analysis via US-based Anthropic API). Such transfers are protected by Standard Contractual Clauses (SCCs) approved by the European Commission.
6. Data Protection Officer
For GDPR enquiries, contact our Data Protection team:email protected
You also have the right to lodge a complaint with your local Data Protection Authority.
Does installing a security plugin create a GDPR obligation?
Usually yes, and it is a manageable one. If a plugin transmits anything that can identify a person (an IP address counts), then a UK or EU site operator is processing personal data through a third party, and that relationship needs a lawful basis, a record, and a data processing agreement.
The good news is that security is among the easiest processing to justify. Legitimate interest is the standard basis, and protecting a website and its users from compromise is an unusually defensible one. Recital 49 of the GDPR explicitly recognises network and information security as a legitimate interest.
What matters is doing the paperwork rather than assuming it does not apply. The obligations are a record of processing, a data processing agreement with the provider, and a privacy notice that tells visitors what happens. None of that is onerous, and all of it is worse to assemble after a complaint than before.
Why what a security tool collects should be boring
The principle that matters most here is minimisation: process what you need for the purpose and nothing else. A security scanner needs file hashes, code fragments, configuration state and the metadata required to identify a threat. It does not need your customers' order history, and a tool that collects it anyway has created risk rather than reduced it.
This is worth checking when you evaluate any security plugin, because the answer varies considerably across the market. The question to ask is specific: what leaves my server, where does it go, how long is it kept, and who else touches it.
IP addresses deserve particular attention, because they are personal data under UK and EU law and security tooling handles them constantly, block lists, rate limiting, login logs, audit trails. That processing is defensible; leaving it undocumented is not.
Where the data goes matters as much as what it is
International transfer is where most WordPress site operators are quietly non-compliant, usually without knowing. If a plugin sends data outside the UK or EEA, that transfer needs a lawful mechanism: an adequacy decision, standard contractual clauses, or another approved route.
The complication is that plugins rarely make this visible. A plugin's own privacy notice may name a processor, but the sub-processors behind that provider are frequently unlisted, and a chain of three companies is quite normal. Asking for the sub-processor list is reasonable and the answer tells you a great deal about how seriously a vendor takes this.
The same applies to your host, your CDN, your analytics and your email provider. Security is often where operators first confront the question, but it is rarely where the largest transfer actually sits.
What changes if the site is actually compromised
This is the part that makes security tooling a compliance instrument rather than merely a compliance liability. A personal data breach must be reported to the supervisory authority within 72 hours of becoming aware of it, and to affected individuals without undue delay where the risk to them is high.
Two words in that carry the weight. The clock starts on awareness, which means an organisation that detects late reports late, and reporting late is itself a breach of the obligation, separate from the incident. And you must describe the scope: what was accessed, when, and by whom.
That is exactly what continuous monitoring and an audit log produce. Without them, scope is estimated, and both available estimates are bad, over-report and you alarm customers unnecessarily, under-report and you have failed the obligation. Detection speed is therefore not only a security control; it is what makes the 72-hour clock survivable.
Common questions
Does using a WordPress security plugin require a DPA?
If the plugin transmits personal data (and IP addresses count), then yes, you need a data processing agreement with the provider, a record of the processing, and a privacy notice covering it.
What is the lawful basis for security processing?
Legitimate interest, in almost all cases. Recital 49 of the GDPR explicitly recognises network and information security as a legitimate interest, which makes it one of the more defensible processing purposes.
Are IP addresses personal data?
Yes, under UK and EU law. Security tooling handles them constantly through block lists, rate limiting and audit logs. That processing is defensible; leaving it undocumented is not.
What should I ask a security vendor?
What leaves my server, where it goes, how long it is kept, who the sub-processors are, and what transfer mechanism covers anything leaving the UK or EEA. The willingness to answer the sub-processor question is itself informative.
How does security tooling help with the 72-hour breach deadline?
The clock starts when you become aware, and you must describe scope. Continuous monitoring shortens the gap between compromise and awareness, and an audit log is what lets you state scope rather than estimate it.
Do I have to report every compromise?
No: the obligation covers personal data breaches, and notification to individuals is required where risk to them is high. Determining which category an incident falls into requires knowing what was accessed, which is again a logging question.