Dormant accounts: who owns the review?

Dormant accounts are accounts that appear unused over the period being reviewed. A lack of recent activity is a reason to investigate their purpose, permissions and dependencies. It does not establish that an old account is safe to leave enabled or safe to delete.

If an IT provider carries out your account review, accept the work when it shows which accounts were covered, what decisions were made and who owns anything unresolved. A spreadsheet marked "reviewed" is insufficient when an old test account still has unexplained access. The business must decide whether a remaining exception is acceptable, with technical evidence from the provider and a date for resolving it.

This matters when your organisation outsources identity administration but still relies on its own staff to explain what applications do. The provider may know how to change an account. Your operations team may be the only people who know which monthly report would stop if it disappeared.

What the ICO case says about responsibility

In its 20 October 2026 announcement, the Information Commissioner's Office says it reprimanded Ogi Networks Limited and Data Cymru after a ransomware attack on 1 November 2024. The ICO says personal information concerning 3,300 people, mostly children, was taken.

The announcement describes a test account created in January 2012 that either remained active or was inadvertently reactivated. It identifies weak credentials, incomplete or non-routine account reviews, and unclear responsibility for delivering, monitoring and auditing outsourced Active Directory services. Active Directory manages identities and access in many business Windows environments. The case raises a practical question for a customer and its provider: who checks that the account review happened and that its findings were resolved?

The ICO recommends routinely identifying and deactivating unnecessary test, dormant and former-user accounts. It also recommends clear contractual responsibility for account controls. Its announcement describes improvements after the incident, so the findings should not be treated as a description of the organisations' controls today. The Ogi enforcement record and Data Cymru enforcement record are dated 14 October 2026. Those dates are distinct from both the attack and the later announcement.

The process below is a suggested way for an SME to commission and accept a review. It is not a reconstruction of that incident or a claim that one review proves compliance.

Agree what the provider is reviewing

Before work starts, identify the systems and account types included. A review limited to current employees may omit test accounts and identities used by applications. Ask the provider to explain the evidence period and its limits, including whether it can see scheduled or infrequent use. A field labelled "last used" needs an explanation of what activity it actually records.

Agree who supplies the account list, who investigates technical dependencies and who confirms business need. The provider should report its findings and carry out approved changes within its remit. A named person in your organisation should accept the review, decide whether unresolved business risks need escalation and check that agreed actions return for review. Put those responsibilities into the service arrangement rather than assuming that "managed IT" includes every part of the process.

Your ICT supplier evidence review can hold that agreement and the provider's evidence. This account review needs a more specific result: each unexplained account should have a supported decision or an open action, without disappearing into a general supplier rating.

A test account that still supports a monthly task

Consider a fictional small distributor reviewing an old account called stock-test. The account has no named owner and its description says only "testing". A short activity report shows no recent use. The provider proposes disabling it as part of routine housekeeping, but neither party has checked the warehouse reporting process.

The operations manager cannot yet confirm that the account is unnecessary. She asks the provider to inspect the application configuration and agrees to own the business decision while its purpose is investigated. The provider finds that a monthly stock export uses the account to read a shared folder. The account's name is misleading, and the short report did not cover that monthly task.

The team now has a different problem to resolve. The export is needed, but its dependence on an undocumented test identity is not an acceptable permanent arrangement. Keeping the account indefinitely would preserve the same uncertainty at the next review. Disabling it without planning could prevent the warehouse team from producing a required report.

A failed change leaves an open action

In the fictional example, the provider and operations manager agree a representative test in a suitable non-production environment, with an approved recovery route. The test temporarily removes the old account's access and attempts the stock export. The export fails because it cannot read the folder.

They record the failed result and recover the test environment through the agreed procedure. They do not mark the account removed, and they do not use a successful login by another user as proof that the export works. The failed test has identified the exact task that the replacement must support.

The operations manager approves a temporary exception until 5 November, an illustrative date chosen for this example. The provider records the required folder access, verifies the agreed restrictions and assigns its engineer to replace the dependency. The operations manager owns the exception and checks the export result. They agree that a missed deadline must return to her for a decision before expiry. The exception will not silently renew.

That decision accepts a defined remaining risk while the repair proceeds. It does not declare the account safe merely because somebody signed a form. If the team cannot establish and verify acceptable restrictions, it must escalate the exposure and consider an approved alternative for the report. Evidence of compromise would require the responsible incident team to reassess the plan; routine housekeeping is not a reason to retain suspected compromised access.

Replace the dependency and test both outcomes

The provider prepares a dedicated identity for the export using controls appropriate to the application, with a recorded purpose and owner. It tests the replacement's required access and checks that it cannot access an unrelated folder. The operations manager compares the resulting export with the expected stock records, including a representative month-end run. The team also checks that the approved recovery route remains usable.

After those checks pass, the provider carries out the agreed production change and disables the old account. It verifies that the export succeeds through the replacement identity and that the old account cannot perform the task. The operations manager accepts the business result, and the provider retains the change and test evidence with the review. If either check fails, the action stays open and the team follows its agreed recovery and escalation procedure.

Disabling the old account and later deleting it are separate decisions. The team records when it will consider deletion, subject to its retention, recovery and investigation requirements. It does not infer that deletion is appropriate just because the export passed once.

What the business can accept as complete

The fictional review reaches the following decisions. Each change in status follows new evidence.

An organisation may finish a review cycle with explicitly accepted exceptions, if that is its agreed acceptance condition. Its report should then say that the review is complete with open remediation, identify the affected accounts and retain the decision owners and deadlines. It should not say that all unnecessary access has been removed.

This distinction lets the provider complete an honest review without encouraging rushed changes. It also lets the business see the work still needed. At the next checkpoint, ask for the exception's outcome and evidence, not simply another copy of the account list. Set future review timing and event triggers to fit the accounts, risks and service agreement rather than adopting an unexplained universal interval.

Resolve the ownership gap before the next review

Start with one unresolved account from your latest review. Ask the provider what purpose and dependency evidence it holds, then identify the person in your organisation who can confirm the business need. Agree what result would justify removal, what would require a temporary exception and who will check the outcome.

If your provider's reports and your internal responsibilities do not join up, IT compliance support can help assess the gap, define responsibilities and organise the evidence needed for review. The scope should distinguish the business acceptance decision from technical changes that your provider or application specialist must perform.

Discuss your account review responsibilities. Bring the review scope, service responsibilities and a redacted example of an unresolved account. Keep credentials and confidential account exports out of the enquiry. The useful starting point is the decision you cannot yet support and the evidence needed to make it.