The test account was created in 2012. The attack came in 2024.
In Wales, an account called Test2 sat on a public-sector network for more than twelve years with the password Password1. The UK regulator's write-up this week reads like a post-mortem most organisations could write about themselves.
Find and remove test, dormant and former-user accounts on a schedule, block weak passwords, require multi-factor authentication on remote access, and write down whether you or your IT supplier owns each of those jobs. On October 20, 2026 the UK's Information Commission's Office reprimanded Ogi Networks and Data Cymru after a 2024 ransomware attack used a test account created in 2012 with the password Password1; data on 3,300 people, most of them children, was taken.
What happened
On October 20, 2026, the UK's data protection regulator published reprimands for two Welsh organisations: Ogi Networks, an IT provider, and Data Cymru, the local government data unit for Wales.
The facts, from the Information Commission's Office's release, are short and uncomfortable. On November 1, 2024, a ransomware attack hit Data Cymru's systems. It encrypted 182.7GB of data and took 42GB. The stolen information belonged to 3,300 people, most of them children, from two projects supporting children and families.
The attackers got in through an account called Test2. Ogi Networks had created it in January 2012. For more than twelve years it was protected by the password Password1. It had either stayed active all that time or been switched back on by accident before the attack.
The regulator's head of investigations, David Doodson, put it plainly: "Password1 is not an appropriate password, it is a wide-open door to nefarious actors."
We're writing this up as a post-mortem, because it isn't really a story about one weak password. It's a story about an account nobody was responsible for.
Timeline
The dates are worth seeing in one place. The account was created in 2012. GDPR obligations arrived in May 2018, and the regulator notes the account carried on for more than six years after that. The attack came in November 2024. A proper data processing contract between the two organisations was signed in April 2025. The reprimands came in October 2026.
Twelve years is long enough for everyone who knew why Test2 existed to have moved on. That's normal. What's not normal is having no process that would ever find it.
One detail in the release deserves more attention than it got. The regulator says the account had either stayed active since 2012 or been "inadvertently reactivated" before the attack. That second possibility matters. Disabling an account feels like dealing with it, but a disabled account still exists, still has its old password, and can be switched back on by a script, a restore from backup, or someone tidying up the wrong list. If an account has no reason to exist, delete it. If it must stay for audit reasons, change its password to something long and random first, and record who decided it stays.
Sequence of work
Twelve years of one test account
- January 2012
Ogi Networks creates Test2 with the password Password1.
- May 2018
GDPR obligations apply; the account remains.
- 1 November 2024
Ransomware attack uses Test2; 42GB taken, 182.7GB encrypted.
- 30 April 2025
Compliant data processing contract signed between the two organisations.
- 20 October 2026
Both organisations reprimanded.
Nobody owned the account, so nobody owned deleting it.
Why it lasted twelve years
The regulator found failings on both sides, and that's the most useful part of the write-up.
The supplier created it and never looked again. Ogi Networks created the account without password-strength rules and didn't regularly audit the accounts it had set up on Data Cymru's network. It also left local administrator accounts on three affected systems with the same password for more than twelve years.
The client controlled the network but didn't review all of it. Data Cymru kept overall control and could instruct its supplier to create or remove accounts. But its account reviews weren't scheduled or routine, and they didn't cover everything in its directory. When it brought in stronger password rules, the old test account wasn't brought under them.
Nobody wrote down who did what. There was no contract with the data protection terms the law requires when appointing a sub-processor, and nothing documenting how the directory services would be delivered, monitored or audited. In the regulator's words, that created "a gap in the allocation of responsibilities."
Put simply, it comes down to this. Nobody owned the account, so nobody owned deleting it. Each side could reasonably have assumed the other would.
Where your Test2 is probably hiding
This happened on a Windows network, but forgotten accounts turn up wherever software has users. These are illustrative, but they're the places we'd look first in an organisation's web apps and portals:
- Admin test users in a public-facing portal, set up during the build and never removed at launch.
- Staging accounts that work on production because both share a login system.
- Demo logins created for an app store reviewer or a sales demo. We've written about giving Apple's reviewer an easy login. That account needs an owner and an end date too.
- Vendor and contractor accounts from a project that finished years ago.
- Shared logins on a supplier portal, which we covered in seasonal temps sharing one password.
- Leavers' accounts that got disabled in email but not in the line-of-business system. See when someone leaves.
The tell is always the same. If you can't name the person who would notice the account being deleted, it's a candidate.
What to change
The regulator listed its lessons, and they're sensible for any organisation, public or private:
- Remove accounts that are no longer needed, routinely. Test, dormant and former-user accounts should be found and switched off.
- Block weak and common passwords so Password1 can't be set in the first place.
- Protect remote access with multi-factor authentication by default.
- Review the whole account environment, including permissions and security groups, not a sample.
- Avoid shared administrator credentials, so one compromised system doesn't open others.
- Put responsibilities in the contract. Say how your IT provider will deliver, monitor and audit security controls.
We'd add one thing for anyone commissioning software. Make account cleanup part of launch and handover. Every account created during a build should be listed, with an owner and an end date, and the list should be signed off before go-live. That's cheap at handover and very expensive twelve years later.
Decision guide
Who should have caught it
| Consideration | Supplier | Client |
|---|---|---|
| Creating accounts | Apply password rules and record why it exists. | Approve it and set an end date. |
| Reviewing accounts | Audit accounts it created, on a schedule. | Review the whole directory, not a sample. |
| Removing accounts | Remove on instruction or at end date. | Instruct removal and confirm it happened. |
| Contract | Say how controls are delivered and audited. | Include the legally required terms and check them. |
Put this into practice this month
Pull a list of every account in your main directory and your public-facing systems, with last login dates. Anything unused for ninety days goes on a review list with a named owner. Test, demo and vendor accounts get an end date or get removed.
Then open your IT supplier contract and look for one sentence: who reviews accounts, how often, and who tells whom when something is found. If it isn't there, that's your first conversation.
If you run public services or portals and want account reviews, ownership and supplier responsibilities designed into the system rather than left to memory, that's the government and public sector work we do. Talk to us.
Related work: Sutton|Place.
We build alongside the people doing the work.
Bring us the problem you’re thinking about.