| Processing Activity: | Usage Data, Audit Logs, and Device/Connection Data Processing |
| Legal Basis: | Article 6(1)(f) UK GDPR - Legitimate Interest |
| Assessment Date: | 2 September 2026 |
| Legal Basis: | Article 6(1)(f) UK GDPR - Legitimate Interest |
| Assessor: | Pogo Kid Limited (Data Controller) |
| Status: | Approved |
1. Introduction
This Legitimate Interest Assessment (LIA) evaluates the lawful basis for processing usage data, audit logs, and device/connection data under Article 6(1)(f) of the UK GDPR. It ensures that our legitimate interests in processing this data for security monitoring, abuse prevention, and service improvement do not override the rights and freedoms of data subjects.
This assessment is required by Article 6(1)(f) which states that processing is lawful if it is necessary for the purposes of the legitimate interests pursued by the controller or by a third party, except where such interests are overridden by the interests or fundamental rights and freedoms of the data subject which require protection of personal data.
2. Processing Overview
2.1 Data Types Processed
| Data Category | Specific Data Elements | Purpose |
|---|---|---|
| Usage Data | Feature usage patterns, system interactions, navigation paths | Service improvement, debugging, performance optimisation |
| Audit Logs | Timestamps, user actions, resource access, administrative events | Security monitoring, compliance, incident investigation |
| Device/Connection Data | IP address, browser type and version, device type, user agent | Security monitoring, abuse prevention, server error diagnosis |
2.2 Processing Context
- Controller: Pogo Kid Limited (trading as Soniq Studio)
- Data Subjects: Platform users (Customers), including account holders and administrators
- Processing Activities: Collection, storage, analysis, and retention of technical and usage metadata
- Retention Periods:
- Application and server error logs: Up to 90 days
- Audit logs: Duration of active account plus up to 1 year (for compliance demonstration)
- Device/connection metadata: Session duration only (not stored long-term)
2.3 Third-Party Involvement
- Grafana Cloud (United Kingdom): Server log aggregation, performance traces, audit logs
- Scaleway (France, EU): Cloud hosting and log storage
- Cloudflare (US): Connection metadata processing (reverse proxy, DDoS protection) - covered by EU-U.S. Data Privacy Framework and UK Extension
Note: No behavioural analytics, advertising tracking, or third-party data sharing occurs. All processing is first-party and service-essential.
3. Purpose Test
3.1 Identified Purposes
We process usage data, audit logs, and device/connection data for the following legitimate purposes:
-
Security Monitoring
- Detect and prevent unauthorised access attempts
- Identify and respond to security incidents
- Monitor for suspicious activity patterns
- Maintain system integrity and protect against attacks
-
Abuse Prevention
- Identify and block malicious actors
- Prevent service abuse (e.g., API abuse, spam)
- Detect and mitigate automated attacks (DDoS, brute force)
- Protect platform availability for all users
-
Service Improvement
- Diagnose server errors and application failures
- Identify performance bottlenecks and optimisation opportunities
- Understand usage patterns to improve user experience
- Debug and resolve technical issues reported by users
3.2 Purpose Assessment
| Purpose | Lawful? | Justification |
|---|---|---|
| Security Monitoring | ✅ Yes | Essential for protecting user data and system security; aligns with our duty to implement appropriate technical measures (Article 32 UK GDPR) |
| Abuse Prevention | ✅ Yes | Necessary to maintain service availability and protect all users from malicious activity; proportional to the risk |
| Service Improvement | ✅ Yes | Necessary for maintaining and enhancing service quality; directly benefits users through improved reliability and performance |
Conclusion: All identified purposes are lawful and legitimate business interests that directly benefit our users and protect their data.
4. Necessity Test
4.1 Necessity Analysis
We must demonstrate that no less intrusive method can achieve the same purposes effectively.
4.1.1 Security Monitoring
| Method | Effectiveness | Intrusiveness | Feasibility |
|---|---|---|---|
| Current: Device/connection data + audit logs | High - Comprehensive threat detection | Medium - Minimal personal data (IP, user agent) | ✅ Feasible |
| Alternative: No monitoring | ❌ None - Unable to detect security incidents | Low | ❌ Not feasible |
| Alternative: Pseudonymised only | ⚠️ Partial - Loses ability to trace specific threats | Low | ❌ Reduces effectiveness |
| Alternative: Sampling only | ⚠️ Partial - Misses intermittent threats | Low | ❌ Creates security gaps |
Assessment: Full device/connection data is necessary for effective threat detection and incident response. Pseudonymisation would prevent us from correlating events to specific sessions, severely limiting our ability to investigate security incidents.
4.1.2 Abuse Prevention
| Method | Effectiveness | Intrusiveness | Feasibility |
|---|---|---|---|
| Current: IP + device fingerprinting | High - Effective at identifying repeat offenders | Medium | ✅ Feasible |
| Alternative: IP-only | ⚠️ Partial - Easily bypassed with VPNs/proxies | Medium | ⚠️ Less effective |
| Alternative: Rate limiting only | ⚠️ Partial - Doesn’t prevent sophisticated abuse | Low | ⚠️ Limited scope |
| Alternative: User reporting only | ❌ None - Reactive, not preventive | Low | ❌ Not feasible for prevention |
Assessment: Device and connection data combined with IP addresses provides the most effective abuse prevention. Rate limiting alone is insufficient as it doesn’t address all abuse vectors.
4.1.3 Service Improvement
| Method | Effectiveness | Intrusiveness | Feasibility |
|---|---|---|---|
| Current: Usage + error logs | High - Enables proactive issue resolution | Medium - Technical metadata only | ✅ Feasible |
| Alternative: User reports only | ❌ None - Reactive, incomplete information | Low | ❌ Not feasible for proactive improvement |
| Alternative: Synthetic monitoring | ⚠️ Partial - Doesn’t capture real user issues | Low | ⚠️ Misses user-specific problems |
| Alternative: Aggregated only | ⚠️ Partial - Loses individual error context | Low | ⚠️ Reduces debugging capability |
Assessment: Individual error logs and usage patterns are necessary to diagnose specific issues affecting particular users. Aggregated data alone would prevent us from resolving individual user problems.
4.2 Proportionality Check
We apply the principle of data minimisation (Article 5(1)(c) UK GDPR):
- ✅ IP addresses: Stored only temporarily for security purposes, hashed where possible
- ✅ User agent strings: Contains only technical device/browser information, no personal identifiers
- ✅ Audit logs: Limited to actions on sensitive resources, not all user activity
- ✅ Usage data: Focused on system interactions, not content or personal preferences
- ✅ Retention: Strict limits applied (90 days for error logs, 1 year max for audit logs)
Conclusion: The data processed is proportionate and necessary - no less intrusive method can achieve the identified purposes effectively.
5. Balancing Test
5.1 Controller’s Legitimate Interests
| Interest | Weight | Justification |
|---|---|---|
| Protect user data from breaches | 🔴 Very High | Legal obligation under Article 32; fundamental to user trust |
| Maintain service availability | 🔴 Very High | Business continuity; affects all users |
| Prevent fraud and abuse | 🟠 High | Protects user experience and platform integrity |
| Improve service reliability | 🟠 High | Directly benefits users through better experience |
| Comply with security obligations | 🔴 Very High | Legal and contractual requirements |
5.2 Data Subject’s Rights and Freedoms
| Right/Freedom | Impact Level | Mitigation |
|---|---|---|
| Right to privacy (Article 7, 8 Charter) | 🟡 Medium | Data minimisation, strict retention limits, no profiling |
| Right to data protection (Article 8 Charter) | 🟡 Medium | Encryption, access controls, security measures |
| Right to be forgotten (Article 17) | 🟢 Low | Automated deletion after retention periods; manual deletion on request |
| Right to object (Article 21) | 🟡 Medium | Users can request processing restriction; necessary for vital interests |
| Freedom from discrimination | 🟢 Low | No automated decision-making; human review required |
| Freedom of expression | 🟢 Low | Processing doesn’t affect content or communication |
5.3 Safeguards Implemented
We implement the following technical and organisational measures to protect data subject rights:
5.3.1 Data Minimisation
- Only essential technical metadata is collected (IP, user agent, timestamps, action types)
- No content data, personal communications, or behavioural profiles are processed for these purposes
- Audit logs are limited to sensitive resource access only
5.3.2 Purpose Limitation
- Data is strictly scoped to the identified purposes (security, abuse prevention, improvement)
- No secondary processing for marketing, analytics, or profiling
- Access to logs is role-based and audited
5.3.3 Storage Limitation
- Error logs: Automatically deleted after 90 days
- Audit logs: Deleted after account closure + 1 year (or sooner if not needed for compliance)
- Device data: Not stored long-term; processed in real-time for security decisions
5.3.4 Security Measures
- Encryption in transit (TLS 1.2+) and at rest (LUKS2 AES-256)
- Role-based access controls with least privilege
- No routine access to logs by administrators
- Regular security audits and penetration testing
5.3.5 Transparency
- Clear disclosure in Privacy Policy (Section 4.4)
- No hidden or undocumented processing
- Users can request their data or processing details
5.3.6 Data Subject Rights
- Right to access: Users can request their audit log entries
- Right to rectification: Users can correct inaccurate log data (where applicable)
- Right to erasure: Data deleted after retention periods or on valid request
- Right to object: Users can object; processing may continue if necessary for security/legal reasons
5.4 Reasonable Expectations
Data subjects can reasonably expect that:
- A service provider will monitor for security threats
- Technical metadata will be logged for debugging purposes
- Abuse prevention measures will be in place to protect all users
- Such processing will be conducted with appropriate safeguards
5.5 Balancing Outcome
Controller’s Interests:
- Very High (x3) + High (x2) = Weighted Score: 9-10/10
Data Subject’s Rights:
- Medium (x4) + Low (x2) = Weighted Score: 3-4/10
Net Assessment: The controller’s legitimate interests significantly outweigh the impact on data subject rights, given the comprehensive safeguards in place.
6. Risk Assessment
6.1 Privacy Risks Identified
| Risk | Likelihood | Impact | Risk Level | Mitigation |
|---|---|---|---|---|
| Unauthorised access to logs | Low | Medium | 🟡 Low-Medium | Encryption, access controls, audit trails |
| Data breach from logs | Low | Medium | 🟡 Low-Medium | Security measures, minimisation |
| Function creep (secondary use) | Low | High | 🟡 Low-Medium | Purpose limitation, governance |
| Individual identification from IP | Medium | Low | 🟢 Low | Temporary storage, aggregation where possible |
| Long-term retention | Low | Medium | 🟡 Low-Medium | Automated deletion, retention policy |
6.2 Residual Risk
After applying all safeguards, the residual privacy risk is LOW.
7. Conclusion
7.1 Three-Test Summary
| Test | Result | Confidence |
|---|---|---|
| Purpose Test | ✅ Pass | High |
| Necessity Test | ✅ Pass | High |
| Balancing Test | ✅ Pass | High |
7.2 Final Determination
The processing of usage data, audit logs, and device/connection data under Article 6(1)(f) UK GDPR is LAWFUL.
- ✅ Purpose: Clear, legitimate purposes (security, abuse prevention, improvement)
- ✅ Necessity: No less intrusive method achieves these purposes
- ✅ Balancing: Controller’s interests outweigh data subject rights given safeguards
7.3 Conditions for Lawful Processing
This assessment is valid subject to the following conditions being maintained:
- Data minimisation continues to be applied (only necessary metadata collected)
- Retention periods are not extended beyond those stated
- Security measures remain in place and are regularly reviewed
- No secondary processing occurs (no marketing, analytics, or profiling)
- Transparency is maintained (privacy policy updated as needed)
8. Review and Maintenance
8.1 Review Schedule
This LIA will be reviewed:
- Annually (or sooner if significant changes occur)
- Following any data breach involving these data types
- Following regulatory guidance changes on legitimate interest
- Following new processing purposes being identified
8.2 Change Log
| Version | Date | Changes | Assessor |
|---|---|---|---|
| 1.0 | 2026-09-02 | Initial assessment | Pogo Kid Limited |
8.3 Approval
Approved by: Pogo Kid Limited (Data Controller)
Approval Date: 2 September 2026
Next Review Date: 2 September 2027
Appendix A: Legal References
- UK GDPR Article 6(1)(f): Processing necessary for legitimate interests
- UK GDPR Article 5(1)(c): Data minimisation principle
- UK GDPR Article 32: Security of processing
- UK GDPR Recital 47: Legitimate interest of the controller
- ICO Guidance: Lawful basis - Legitimate interests (ico.org.uk)
Appendix B: Related Documents
- Privacy Policy - Section 4.4 (System & Usage Data)
- Data Retention Policy - Retention periods for each data type
- Security Measures - Technical and organisational security controls