Summary: When customer accounts go dormant, the sensitive data behind them usually stays fully readable and widely accessible. Drawing on New Zealand’s final Manage My Health inquiry report, this article gives security and governance leaders a practical approach for reviewing why dormant data is retained, who can still see it and how masking, tokenization and access monitoring can reduce exposure without disrupting legitimate obligations.
Most customer accounts never formally close. They simply go quiet. A customer stops logging in, a patient switches providers or a member moves across the country, and the account stays exactly where it was, holding a name, a date of birth, contact details, a transaction history and whatever else was collected along the way. Nobody decides to keep that data. It just stays.
That quiet persistence is what turns a dormant account into a data security question rather than a housekeeping chore. The sensitive data inside it still lives in production tables, still flows into analytics pipelines and still appears in query results for anyone whose role grants access. What has changed is the reason for holding it, which may have expired months or even years ago without anyone noticing.
A regulator just put dormant accounts on the record
On October 30, New Zealand’s Privacy Commissioner, Michael Webster, released his second and final report into the December 2025 cyber breach of Manage My Health, a patient portal. He called the incident a major wake-up call for agencies and used the report to highlight practices he considers important for every organization, not only those in healthcare.
One of those practices was having a clear process for identifying and managing dormant accounts. His office generally expects organizations to check in with an account holder after 12 months of inactivity to confirm whether they want to keep the account, unless a specific law or reason requires the information to be retained.
That 12-month expectation belongs to New Zealand’s regulator, and it isn’t a universal legal standard. The principle behind it travels well, though. The Commissioner’s broader message was that organizations need to understand what information they hold, why they need it and how they are handling it. Customer inactivity is one of the clearest signals that it’s time to ask those questions again.
Connect account status to your sensitive data inventory
Most organizations already track whether an account is active. Far fewer can say which sensitive fields sit behind a dormant account and where copies of those fields live. The customer record in the operational database is usually only the beginning, because the same values are often replicated into a data warehouse, joined into reporting tables and cached in downstream tools.
The first step is to bring those two views together. When account status becomes an attribute your data governance program can see, you can answer a practical question with confidence: how much identifiable data do we hold for people who no longer have an active relationship with us? That number tends to be larger than teams expect, and it gives the rest of the review a clear scope.
Document why each record still needs to exist
Dormancy doesn’t automatically mean deletion. Financial institutions, healthcare providers and many other organizations have legitimate obligations to retain records for years, and legal holds or open disputes can extend those periods further. The goal is not to purge everything that looks inactive. It is to separate the records you must keep from the records you simply haven’t removed.
Writing down the reason for retention, along with the obligation or business need that supports it, turns an assumption into a decision. It also gives each retained dataset a natural end date, so that when the retention period runs out, someone knows it is time to act.
Ask whether retained data still needs to be readable
Retention and usability are two different decisions, and treating them as one is where a lot of unnecessary exposure comes from. A record kept for seven years to satisfy a regulator does not need to appear in clear text on a marketing dashboard or in a churn model that a dozen analysts query every week.
This is where data masking and data tokenization earn their place. Analysts can still count dormant accounts, segment them by region or study why customers drifted away, all without seeing real names, account numbers or birth dates. Format-preserving encryption approaches keep the data shaped the way downstream tools expect, so reports and pipelines continue to run. When a legitimate need for the original values does arise, such as a customer reactivating, an access request or a regulatory inquiry, authorized users can still reach them through a controlled path.
Look closely at who is still touching the data
Dormant data should be quiet data. If a table full of inactive customer records is being queried every day, that activity deserves an explanation. Very often the answer is harmless, such as a forgotten scheduled job or a report that nobody has retired. Occasionally it is something that warrants a closer look.
Reviewing access activity against retained datasets lets you see which users, service accounts and applications are still reading sensitive values. Any usage that nobody can explain should be assigned to an owner who either confirms the business need or shuts the access down. Over time, this practice shrinks the number of places where dormant data can quietly leak.
Make the review recurring and record every decision
A single cleanup project helps, but accounts go dormant every day, so the review has to repeat. Many organizations align it with their existing retention schedule or a quarterly governance cycle. Each pass should produce a record of what was reviewed, what was retained and why, what was masked or deleted and which exceptions were approved and by whom.
That record matters more than it might seem. When an auditor, a regulator or your own leadership asks how you handle data for inactive customers, a documented and repeatable process is a far stronger answer than good intentions.
Turning inactivity into a governance trigger
The practical challenge is that dormant data rarely sits in one place, and manual reviews struggle to keep up with the pace at which accounts go quiet. This is the kind of work ALTR is designed to support. Its data classification helps teams locate sensitive fields across their cloud data platforms, while policy-driven masking, tokenization and format-preserving encryption let them limit what retained data reveals without breaking the workflows that rely on it. Database activity monitoring then shows who is still accessing those datasets, giving owners the evidence they need to make each recurring decision.
Inactivity is easy to overlook because nothing appears to happen. Treat it instead as a prompt to confirm why the data is still there, who can see it and whether they still need to. Organizations that build that habit now will be far better prepared when a regulator, an auditor or an incident asks the same questions.