Legitimate Interest Assessment

Assessment Overview

This Legitimate Interest Assessment (LIA) evaluates whether Maelstrom AI’s processing activities satisfy the requirements of GDPR Article 6(1)(f). Parts 1-3 cover IP address logging for rate limiting and abuse prevention on production verification infrastructure. Part 4 covers Cloudflare bot protection applied to the docs interactive sandbox. Both assessments follow the Information Commissioner’s Office (ICO) three-part test.

Part 1: Purpose Test

What is the legitimate interest?

Preventing abuse of the age verification service through rate limiting, DDoS mitigation, and fraud detection. Maelstrom AI operates a cryptographic age verification infrastructure used by relying parties (verifiers) to confirm user age without collecting personal data. IP address processing is required to protect the availability and integrity of this service.

Is it a legitimate interest?

Yes. Protecting service availability and infrastructure integrity is a well-recognised legitimate interest under GDPR. The European Data Protection Board (EDPB) and the ICO both acknowledge that network and information security constitutes a legitimate interest (Recital 49, GDPR).

Is there a real need for this processing?

Yes. Without rate limiting and abuse detection:

• The verification service could be overwhelmed by volumetric attacks (DDoS)
• Malicious actors could attempt brute-force exploitation of verification endpoints
• Service availability for legitimate relying parties and their end users would be compromised
• Fraudulent verification requests could undermine the trust model

Part 2: Necessity Test

Is the processing necessary for this purpose?

Yes. IP-based rate limiting requires processing the source IP address of incoming requests. This is the standard and most effective method for identifying and throttling abusive traffic patterns at the network level.

Could we achieve the purpose in a less intrusive way?

Maelstrom AI already implements the least intrusive approach practicable:

1. IP addresses are hashed using SHA-256 before storage. plaintext IPs are not retained
2. Retention is limited to 90 days with automatic expiry enforced at the storage layer (critical security event logs are retained for up to 365 days)
3. Cloudflare edge rate limiting provides an additional layer of protection before requests reach Maelstrom AI’s infrastructure, reducing the volume of IP data Maelstrom AI must process directly
4. No cross-service correlation is performed. hashed IPs are used solely within the rate limiting context

Alternative approaches (such as CAPTCHAs or client-side tokens alone) do not provide equivalent protection against volumetric or automated attacks and would introduce greater friction for end users.

Is the processing proportionate?

Yes. The processing is tightly scoped:

• IP addresses are hashed, not stored in plaintext
• Hashed values auto-expire after 90 days (critical security event logs are retained for up to 365 days)
• Processing is limited to rate limiting and abuse prevention. no profiling, tracking, or secondary use
• Hashing is one-way, making recovery of the original IP address from the stored hash computationally impractical

Part 3: Balancing Test

Impact on individuals

Minimal. The hashed IP address cannot directly identify an individual. The 90-day retention window (up to 365 days for critical security events) limits temporal exposure. No profiling, behavioural analysis, or tracking is performed. The processing does not result in any decision that affects an individual’s access to services. rate limiting applies at the infrastructure level, not at the individual user level.

Reasonable expectations

Users reasonably expect that a web service processes IP addresses for security purposes. This is standard industry practice disclosed in Maelstrom AI’s privacy policy. The ICO’s guidance confirms that individuals generally expect their IP addresses to be processed for network security.

Relationship with data subjects

Maelstrom AI operates a B2B2C model. Maelstrom AI provides age verification infrastructure to relying parties (verifiers). End users interact with relying party websites and applications, not directly with Provii. The processing relationship is indirect, which further reduces any impact on data subjects.

Safeguards in place

Special categories or children

IP addresses are not special category data under GDPR Article 9. Children may use the age verification service (the service exists precisely to verify age), but IP address processing is identical for all users regardless of age. No additional data is collected from children, and the processing does not vary based on the user’s age or any other characteristic.

Conclusion (Parts 1-3)

The legitimate interest balancing test is satisfied. IP address processing for rate limiting and abuse prevention is necessary, proportionate, and does not override the rights and freedoms of data subjects. The safeguards in place (hashing, 90-day auto-expiry with up to 365 days for critical security events, no cross-service correlation, and no third-party sharing) further reduce any residual impact on individuals.

The processing may proceed under GDPR Article 6(1)(f).

Part 4: Cloudflare Bot Protection (Docs Sandbox)

This part assesses the separate processing activity of passive Cloudflare bot protection applied to the docs interactive sandbox at docs.provii.app. The production IP-processing assessment in Parts 1-3 is retained unchanged; this part runs in parallel for a distinct surface, a distinct audience, and a distinct cookie surface.

Part 4.1: Purpose Test

What is the legitimate interest?

Preventing automated abuse of the docs sandbox credential endpoints. The sandbox is a public, unauthenticated developer-onboarding surface that issues short-lived synthetic credentials and exposes the API explorer for evaluation. It must withstand credential-harvesting bots, scripted abuse of the fixture issuer, and volumetric abuse against Cloudflare Worker request budgets, without forcing developers through a sign-up wall.

Is it a legitimate interest?

Yes. Network and information security is a recognised legitimate interest under GDPR Recital 49. Protecting a public developer onboarding surface from automated abuse is squarely within that scope. Without bot protection the sandbox issuer would be trivially farmable by scripts, which would degrade service availability for genuine evaluating developers and inflate operational costs.

Is there a real need for this processing?

Yes. The sandbox exists precisely so prospective integrators can evaluate Provii without an account. That openness is the value proposition of the surface but also the attack surface. Cloudflare bot protection is the minimum effective defence because any in-app challenge (CAPTCHA, proof-of-work, sign-up) materially degrades the onboarding experience the sandbox is designed to provide.

Part 4.2: Necessity Test

Is the processing necessary for this purpose?

Yes. Passive edge bot protection. running in Cloudflare’s network layer before requests reach the Worker. is the only viable mechanism for a public developer-facing surface operated without user authentication. The alternative (requiring developers to create an account before using the sandbox) defeats the pre-contractual onboarding purpose documented in Section 2.5 of the Privacy Policy and in the new Docs Sandbox DPIA.

Could we achieve the purpose in a less intrusive way?

Maelstrom AI already adopts the least intrusive bot protection posture practicable:

1. Passive detection only. The sandbox uses Cloudflare Bot Fight Mode signals passively; interactive challenges (managed challenge, Cloudflare managed challenge) are reserved for traffic already flagged as likely malicious, so the typical developer sees no friction.
2. Cloudflare-owned cookies. __cf_bm (30-minute TTL) and cf_clearance (30-day TTL) are set by Cloudflare edge infrastructure, not by Maelstrom AI application code. Both are strictly necessary under ePrivacy Article 5(3) for the security service the developer has explicitly requested.
3. Transient IP processing. Source IP is processed at the edge for the duration of the bot scoring decision. Maelstrom AI does not persist raw IP from sandbox traffic; only hashed IP is stored through the pathway documented in Parts 1-3.
4. No behavioural profiling. Cloudflare bot scores are consumed as pass or fail signals at the edge. Maelstrom AI does not receive, store, or analyse per-user behavioural fingerprints.

Alternatives considered: requiring account sign-up before sandbox access (defeats the onboarding purpose, collects more data than necessary), running our own bot detection (less effective at equivalent cost and would require processing more data than Cloudflare’s edge model), or operating the sandbox without bot protection (fails the purpose test and exposes the issuer to abuse).

Is the processing proportionate?

Yes. Bot protection is scoped to the docs sandbox surface, implemented at the edge, and consumed as a pass or fail signal. No application-level profiling is layered on top. Cookies set by Cloudflare are strictly necessary, short-lived at the session scale (__cf_bm 30 minutes) or time-boxed at the clearance scale (cf_clearance up to 30 days), and neither carries an advertising, analytics, or cross-site tracking payload.

Part 4.3: Balancing Test

Impact on individuals

Low. The processing applies to a public developer-facing surface that consumers are not directed to. The data subject population is self-selecting: a developer chooses to visit the docs sandbox as part of evaluating Provii, which is a pre-contractual activity they have initiated. Cloudflare bot cookies are strictly necessary, do not contain personal information, and cannot be used for advertising or cross-site profiling. Raw IP is processed transiently at the edge during bot scoring and is not retained by Maelstrom AI beyond the hashed-IP pathway documented in Parts 1-3.

Reasonable expectations

Developers evaluating an integration expect bot protection on a public API explorer. Using Cloudflare for edge security is standard industry practice and is disclosed in the Cookie Policy and the Privacy Policy (Section 2.5). The ICO’s guidance on cookie-based bot protection treats passive edge detection as proportionate where the alternative is either a sign-up wall or degraded service integrity.

Safeguards in place

Special categories or children

Bot protection processes no special category data under GDPR Article 9. The docs sandbox is a developer-facing surface; the DPIA at DPIA. Children’s Code Standard 2 (Docs Sandbox) concludes the sandbox is not likely to be accessed by children in the ICO sense. Cookies are identical for all visitors and do not vary by any demographic attribute.

Conclusion (Part 4)

The balancing test is satisfied for Cloudflare bot protection on the docs sandbox. The processing is necessary to defend a public, unauthenticated developer onboarding surface against automated abuse; less intrusive alternatives either fail the purpose (no bot protection) or collect more data than necessary (pre-sandbox account sign-up). The safeguards above hold the residual impact on developers to a low, transient level and the cookies involved are strictly necessary and Cloudflare-owned.

The processing may proceed under GDPR Article 6(1)(f). The strictly-necessary cookies __cf_bm and cf_clearance are exempt from consent under ePrivacy Article 5(3) and UK PECR Regulation 6(4).

Alternative Lawful Bases Considered

Document Control