When Geoffrey Smith accessed 490 personal records at Herefordshire Council over four days, he didn't hack into the system. He used his legitimate access to view sensitive information like children's medical records and social worker reports, often involving people he knew. The council only discovered this breach after concerns were raised about a specific case. This reactive approach is common, but it often comes too late, after significant data exposure.
The ICO prosecuted Smith under Section 1 of the Computer Misuse Act 1990 instead of Section 170 of the Data Protection Act 2018 to secure a custodial sentence, two months suspended, along with unpaid work and costs. Section 170 doesn't allow imprisonment, which many argue weakens deterrence. However, waiting for stronger sentencing won't protect your data subjects. You need proactive technical controls to identify unusual access patterns before an employee becomes a liability.
Essential Preparations
Before implementing this strategy, ensure your system allows employees to access personal data as part of their role. You'll need:
Access to system logs. Your database, CRM, or electronic health record must generate audit logs showing who accessed what and when. If logging isn't enabled, activate it first, this strategy depends on it.
A SIEM or log aggregation tool. Platforms like Splunk, Elastic Stack, or Microsoft Sentinel help you query and alert on access patterns. Even a scheduled SQL query is better than manual checks.
Baseline access patterns. Understand normal access behavior by collecting at least two weeks of logs. This helps identify anomalies.
Clear role definitions. Document which roles require access to specific records. If your model allows unrestricted access, address this first, technical controls can't fix poor access design.
Step-by-Step Implementation
Step 1: Enable comprehensive audit logging
Ensure your system captures user ID, timestamp, record ID, action type, and IP address. Many systems log views but not downloads, Smith downloaded 94 documents, which is a stronger indicator of intent. Ensure downloads and exports trigger distinct log entries.
In SQL-based systems, add audit triggers to sensitive tables. For example, in PostgreSQL:
CREATE OR REPLACE FUNCTION audit_record_access()
RETURNS TRIGGER AS $$
BEGIN
INSERT INTO access_audit_log (user_id, record_id, action_type, timestamp, ip_address)
VALUES (current_user, NEW.id, TG_OP, NOW(), inet_client_addr());
RETURN NEW;
END;
$$ LANGUAGE plpgsql;
Apply this trigger to tables with personal data. Verify it's working by checking the audit table after test access.
Step 2: Define detection rules
Start with these high-signal patterns:
Volume anomalies: Alert when a user accesses more than three times their daily average within a four-hour window. Smith accessed hundreds of records in four days, your baseline will show whether 50 records in one shift is normal or a red flag.
Relationship-based access: Flag when an employee accesses records matching their own surname, address, or known associates. This requires enriching your audit logs with record metadata and employee data. Use a query like:
SELECT a.user_id, a.record_id, a.timestamp
FROM access_audit_log a
JOIN employee_data e ON a.user_id = e.user_id
JOIN case_records c ON a.record_id = c.record_id
WHERE c.subject_surname = e.surname
OR c.subject_postcode = e.home_postcode;
Run this daily and route matches to a supervisor for review.
Out-of-role access: Alert when a user accesses records outside their department. If your system tags records by service area, cross-departmental access should be rare. Smith accessed adult records involving family members, this pattern should trigger immediate review.
Step 3: Implement alerting and response workflows
Configure your SIEM to notify your data protection officer and the employee's manager when a rule triggers. Include employee name, record count, time window, and a link to the full audit trail.
Don't automate account suspension to avoid false positives. Instead, require the manager to review within 24 hours and document either "legitimate business need" or "escalate to HR investigation".
Create a response template:
- Manager reviews audit log and case notes
- If unexplained, manager interviews employee the same day
- If unjustified, HR launches a formal investigation
- If unauthorized access is confirmed, seek legal advice on whether to self-report to the ICO
Step 4: Harden access controls
After monitoring for a month, review which rules fired most often. If daily alerts occur for legitimate collaboration, your access model may be too restrictive. If no alerts occur despite known gossip about cases, your rules may need adjustment.
Tighten role-based access so employees can't browse records outside their caseload without a supervisor override. Implement break-glass access for emergencies, requiring a reason code and manager approval logged in the audit trail.
Validation: How to Verify It Works
Test with a controlled violation. Have a trusted colleague access their own family member's record with consent. Your alert should fire within your configured window. If not, check your query logic and log ingestion.
Review a sample of legitimate access. Pull 20 random audit entries from the past week and ask employees to explain each access. If they can't justify it, your baseline of "normal" access may include unauthorized browsing.
Run the Smith scenario. Query your logs for any employee who accessed more than 100 records in a week where those records share a postcode or surname with the employee. Investigate any matches immediately.
Maintenance and Ongoing Tasks
Weekly: Review triggered alerts and close them with documented justification. Track your false positive rate, if more than 30% of alerts are legitimate, recalibrate your thresholds.
Monthly: Audit high-volume users. The top 10 accessors should align with high-caseload roles. Investigate if a new hire appears in the top 10.
Quarterly: Update your relationship-matching logic when employees change address or surname. Refresh role definitions when organizational structures change.
Annually: Re-baseline access patterns. Normal changes as caseloads shift, new systems launch, or remote work policies evolve.
The council caught Smith only after concerns were raised about a specific case. Your goal is to catch the next Smith at record 10, not record 490. Technical monitoring won't prevent every unauthorized access, but it will reduce the time between violation and detection, turning a potential crisis into a manageable incident.
