| Processing Activity: | Usage Data, Audit Logs, Device/Connection Data, and App Error Reports Processing |
| Legal Basis: | Article 6(1)(f) UK GDPR - Legitimate Interest |
| Assessment Date: | 5 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, device/connection data, and app error reports 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 (including time a contact portal link was opened), 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, error diagnosis |
| App Error Reports | The error and what the app was doing when it happened, the page address with access links and query details removed, browser type. For signed-in users, some reports include profile identifiers | Diagnosing and fixing errors in the app |
2.2 Processing Context
- Controller: Pogo Kid Limited (trading as Soniq Studio)
- Data Subjects: Platform users (Customers), including account holders and administrators. App error reports can also come from students and Responsible Adults who open a contact portal, payment or invitation link; some students are children
- Processing Activities: Collection, storage, analysis, and retention of technical and usage metadata
- Retention Periods:
- Application and server error logs: Up to 90 days
- App and server error reports: 30 days, deleted by a nightly job
- 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
Error reports from our servers and from the app go to our own error tracker, which runs on our Scaleway infrastructure in France. No third party receives them.
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 errors on our servers and in the app, including errors the app catches in the user’s browser
- 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.1.4 App Error Reports
Errors that happen in the app, in the user’s browser, never reach our server logs. Without reports from the app we would only learn of them when someone tells us.
| Method | Effectiveness | Intrusiveness | Feasibility |
|---|---|---|---|
| Current: Reports only for errors the app catches, with access links and query details removed from page addresses | High - Enough context to find and fix the error | Low - No automatic collection | ✅ Feasible |
| Alternative: Automatic collection (all uncaught errors, console and network history, session recordings) | High | High - Records far more than an error needs | ❌ Rejected as disproportionate |
| Alternative: No app error reports | ❌ None - App errors go unseen | Low | ❌ Not feasible |
| Alternative: User reports only | ⚠️ Partial - Incomplete, and puts the effort on the person who hit the error | Low | ⚠️ Kept alongside, not instead |
Assessment: Reporting only the errors the app already catches, with page addresses cleaned before they leave the browser, is the least intrusive method that still lets us fix errors people hit. No external hosted service or session recordings.
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
- ✅ App error reports: Sent only for errors the app catches. Access links and query details are removed from page addresses, and the error tracker does not record the visitor’s IP address
- ✅ Retention: Strict limits applied (90 days for error logs, 30 days for error reports, 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
- App error reports are sent only for errors the app catches. Nothing is collected automatically: no clicks, console output, network requests or session recordings
- Contact portal, payment and invitation links grant access on their own, so the secret part is replaced before a report leaves the browser. Query details (such as sign-in codes and payment provider return values) are removed entirely
- Our developers must not include anything a user typed in an error report
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
- Error reports: Automatically deleted after 30 days by a nightly job
- 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
- Objecting to app error reports: Error reports can be switched off in any browser, and we will explain how on request. Most reports carry no identifier, and none carry an IP address, so we cannot usually find one person’s past reports; they are deleted after 30 days
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
- An app will tell its maker when something goes wrong in it, so the fault can be fixed
- 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 |
| Access links exposed in reported page addresses | Low | High | 🟡 Low-Medium | Secret parts of contact portal, payment and invitation addresses replaced, query details removed, before sending |
| Personal data in error messages (e.g. an error that repeats something a user typed) | Low | Medium | 🟡 Low-Medium | Developer rule against including user-entered values, 30-day retention, access limited to our team |
| Children’s data in error reports | Low | Medium | 🟡 Low-Medium | Names and emails not deliberately collected, no IP addresses recorded, access links removed, 30-day retention |
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)
- App error reports stay limited to errors the app catches, with page addresses cleaned before sending, and no automatic collection or session recording is added
- The error tracker does not record visitors’ IP addresses (it is not configured to read the forwarded client address)
- The nightly deletion job for error reports keeps running
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.2 | 2026-09-27 | Added app error reports: data elements, necessity, safeguards, risks and conditions. Added students and Responsible Adults as data subjects of error reports | Pogo Kid Limited |
| 1.1 | 2026-09-05 | Added explicit reference to “time a contact portal link was opened” in Audit Logs data elements to align with Privacy Policy | Pogo Kid Limited |
| 1.0 | 2026-09-02 | Initial assessment | Pogo Kid Limited |
8.3 Approval
Approved by: Pogo Kid Limited (Data Controller)
Approval Date: 5 September 2026
Next Review Date: 5 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