A twelve-year-old test account protected by 'Password1' became the entry point for ransomware attackers who compromised the personal data of 3,300 people in Wales, most of them children. The ICO’s October 2024 reprimand of Ogi Networks Limited and Data Cymru reveals how basic security lapses create catastrophic exposure, particularly when responsibility for those controls isn't clearly assigned.
This checklist addresses the specific technical and contractual failures that enabled the breach. Use it to verify your organization hasn't left similar doors open.
Prerequisites
Before working through this checklist, confirm you have:
- Current documentation of all processor relationships, including IT service providers
- Access credentials to your identity management system (Active Directory, Azure AD, or equivalent)
- Your organization's data processing agreements and records of processing activities
- Authority to implement or request changes to password policies and account management procedures
If you're a controller working with processors, you'll need collaboration from your service provider to complete several items.
Account Security and Hygiene
1. Enforce strong password requirements
Check that your password policy requires:
- Minimum length of 12 characters
- Mix of character types (upper, lower, numbers, symbols)
- Rejection of common passwords and dictionary words
- Expiration or change requirements for administrative accounts
Test this by attempting to create a weak password on a non-production account. An attempt to set 'Password1' should fail immediately with a clear explanation of requirements.
2. Implement multi-factor authentication (MFA) for remote access
Verify MFA is enforced for:
- VPN connections
- Remote desktop access
- Cloud service portals
- Administrative interfaces
Ensure you cannot complete remote authentication without a second factor (authenticator app, hardware token, or biometric). No exceptions should exist for "trusted" devices or legacy systems.
3. Set expiration dates for test and development accounts
Review all accounts created for testing, development, or temporary purposes. Each must have:
- A documented business purpose
- An assigned owner
- An automatic expiration date
- The same appropriate technical and organisational measures as production accounts
Your identity system should show zero accounts older than six months with "test", "dev", "temp", or "demo" in the name. Any that exist should have documented justification and scheduled review dates.
4. Conduct regular account audits
Implement quarterly reviews that examine:
- All accounts with administrative privileges
- Accounts inactive for over 90 days
- Service accounts and their access scope
- Accounts created by third-party processors
Ensure you have calendar entries for these reviews, documentation of the last four quarters' findings, and evidence that identified issues were remediated. The review should cover your full Active Directory structure, not just obvious user accounts.
5. Review local administrator accounts post-deployment
After deploying any system or service that creates local admin accounts:
- Document which accounts were created
- Verify their necessity
- Apply password requirements
- Schedule the first review within 30 days
Your deployment checklist should include account documentation as a mandatory sign-off step. You should be able to produce a list of all local admin accounts created in the past year and evidence they've been reviewed.
Processor Relationships and Contracts
6. Ensure written contracts with processors include Article 28 requirements
For every organization that processes personal data on your behalf, verify your contract includes:
- Subject matter and duration of processing
- Nature and purpose of processing
- Types of personal data and categories of data subjects
- Controller's rights to audit
- Processor's obligation to assist with data subject rights
- Processor's obligation to assist with personal data breach notification
- Requirements for sub-processor approval
- Data deletion or return provisions
You should be able to open your contract with your IT service provider and point to specific clauses addressing each Article 28(3) requirement. The contract should be signed before processing begins.
7. Assign responsibility for security measures explicitly
Your processor contracts must specify:
- Which party implements password policies
- Who conducts account audits
- Who monitors for unauthorized access
- Who maintains security patches
- Escalation procedures for security issues
When you ask "Who ensures test accounts don't persist for twelve years?", the contract should provide an unambiguous answer. If the answer is the processor, their security obligations should be detailed enough to enforce.
8. Review processor security practices regularly
Before appointing a processor and annually thereafter:
- Request evidence of their appropriate technical and organisational measures
- Review their incident response procedures
- Verify their account management practices
- Confirm their audit capabilities
Maintain a file for each processor containing their most recent security documentation, dated within the past year. Document your assessment of whether their measures meet Article 32 standards.
Common Mistakes
Assuming IT service providers handle security by default. Data Cymru had no contract specifying ONL's security obligations. When the breach occurred, accountability was unclear. Your contract must explicitly state who implements each control.
Treating test accounts as temporary without enforcing expiration. The compromised account existed for over twelve years. If you create an account for testing, set an automatic expiration date in your identity system, not just a calendar reminder.
Conducting ad-hoc reviews instead of scheduled audits. Data Cymru's account reviews weren't routine and didn't cover Active Directory comprehensively. Ad-hoc reviews miss things. Schedule quarterly audits as recurring calendar events with specific deliverables.
Believing basic security doesn't apply to legacy systems. The test account predated modern security practices but remained accessible. Every account in your environment must meet current standards, regardless of when it was created.
Separating compliance and security teams. Article 32 requires appropriate technical and organizational measures. If your compliance team doesn't understand your account management practices, and your security team doesn't understand processor obligations, gaps emerge.
Next Steps
Complete this checklist within 30 days. Items 1, 2, and 6 are foundational, address these first if you identify gaps.
If you find test accounts without expiration dates (item 3), disable them immediately and document why they existed. Investigate whether similar accounts exist in other systems.
If your processor contracts lack Article 28 requirements (item 6), you're operating outside compliance. Draft compliant terms and propose them to your processor. If they resist, you need to reassess the relationship.
Schedule your first quarterly account audit (item 4) before finishing this checklist. The ICO's message is clear: basic cybersecurity controls aren't optional. A single overlooked account can compromise thousands of data subjects and trigger supervisory authority action.
