A Vaughan family company finally stopped hoarding old customer files

The situation

The email that started it was three lines long: a customer asking, politely but pointedly, why a company he had not ordered from in six years still had his account details, his old purchase history, and apparently his banking reference number on file. Cherise read it twice before forwarding it to her brother Kittipong with a single line: do we still have this stuff?

The two of them run the mid-sized distribution company their parents built, a Vaughan operation now doing somewhere in the range of ten million dollars a year moving specialty goods to retailers across the region. Cherise had spent years as an air traffic controller before coming back to run operations; Kittipong still flies part-time as a commercial pilot on his weeks off from the business. Neither of them had built the company's customer database. That had been Simone, a family friend since childhood who had done the firm's early marketing and systems work as a contractor for nearly a decade before stepping back a few years earlier.

When Cherise finally got into the customer database herself, the scale of it startled her. There were records going back well over a decade, including customers who had placed a single order in the company's early years and never returned. Full order histories, contact details, and in some cases banking references used for direct deposits sat untouched in the same tables as active accounts, with no flag distinguishing a live customer from someone who had not ordered anything since before the company moved offices.

Worse, when she asked their IT contractor to check who had access to the system, Simone's old login credentials were still active. Nobody had turned them off when the contract ended, because nobody had ever been assigned to do it. Simone was still a close family friend, someone who came to Kittipong's daughter's birthday party every year, which made the conversation about closing that access feel more awkward than it should have been for a purely administrative task.

The two siblings did not agree at first on how urgent the problem was. Kittipong's instinct was to quietly delete what looked old and move on; Cherise worried that deleting records without understanding what obligations attached to them could create a different problem, especially with the banking references sitting in the mix. Neither of them had ever had to think about the company as something that collected and held personal information as a matter of course, rather than as a byproduct of selling goods. That gap in how they saw the business was, in its own way, part of what had let the records pile up unnoticed for so long.

Cherise and Kittipong came to us wanting two things: to understand what obligations they actually had around all this old data, and to fix the access problem without turning a family friendship into a confrontation.

What the documents showed

We started by asking for everything the company had in writing about how customer data was collected, used, and kept. There was almost nothing. A short privacy notice lived on the company's website, last updated years earlier, that made general promises about protecting customer information but said nothing about how long records were kept or when they would be deleted. Internally, there was no retention policy at all. Nobody had ever decided how long a customer's file should live in the system after the relationship ended; the default, in practice, had been forever.

We reviewed the contractor agreement Simone had signed at the outset of the relationship. It included a standard confidentiality clause and a requirement to return or destroy company records at the end of the engagement, but it did not specifically address system access, and there was no record that anyone had followed up when the contract wound down. The agreement was old enough that some of its terms no longer reflected how the business actually operated, since Simone's role had expanded informally over the years to include far more system administration than the written scope described.

We also asked Cherise and Kittipong to pull together everything they knew about what categories of data the company actually held. This took longer than expected, because the information was spread across the order system, an old marketing platform, spreadsheets kept by different employees over the years, and a handful of paper files in storage. Some of it duplicated other records. Some of it, including a batch of banking references collected years earlier for a direct-deposit refund program the company no longer ran, had no ongoing business purpose at all.

What the documents showed, in short, was a company that had never made an active decision about data retention. Records accumulated because deleting them was nobody's job, and access had been granted based on trust and history rather than on what a role actually required. That gap was fixable, but it needed a structure the company could actually follow going forward, not just a one-time cleanup.

There was also a narrower question buried in the mess: whether the company had any specific obligation to notify customers or take particular steps because of how long the banking references had been kept. We explained to Cherise and Kittipong that Canadian privacy law generally expects an organization to limit how long it keeps personal information to what is reasonably needed for the purpose it was collected for, and that keeping banking references years after the refund program that used them had ended was hard to justify under that standard. The fix here was not a dramatic one, but it was not optional either: stop collecting more than needed, decide how long to keep what remains, and delete the rest.

What we did

1. Inventoried the data the company actually held. We worked with Cherise to map every system, spreadsheet, and paper file containing customer information, sorted by category and rough age, so the company could see for the first time what it was keeping and why, rather than guessing at the scale of the problem. That inventory was the foundation every later step depended on, because nobody could set a sensible retention period for data they could not yet see in one place.
2. Drafted a retention schedule tied to business need. For each category of data we set a clear period for how long it should be kept after the customer relationship ended, based on how long the company might reasonably need it for service, warranty, or accounting purposes, with a default deletion date after that. This gave the company a rule to apply going forward instead of relying on nobody ever getting around to deleting anything.
3. Built a defensible reason for each retention period. Rather than picking arbitrary numbers, we tied each period to something concrete: the length of a product warranty, the period the company's own accounting records needed to be kept, or the time a dispute could realistically still surface. Grounding each period in a real business reason meant the schedule would hold up if a customer or a regulator ever asked why a particular record was kept as long as it was.
4. Closed out the old contractor access formally. We drafted a short, professional letter to Simone confirming that the engagement had ended and that system access was being revoked as a standard step, framed as routine housekeeping rather than a statement of distrust. That framing is what let Cherise and Kittipong send it without the conversation turning personal or straining a friendship that mattered to both of them.
5. Rewrote the public privacy notice. The old notice made vague promises the company was not actually keeping. We rewrote it to accurately describe what data the company collects, why, and how long it is kept, so the notice matched reality instead of aspiration, which mattered because a notice that overpromises is itself a liability once anyone checks it against practice.
6. Set up an access review process. We put in place a simple rule: whenever a contractor or employee's role ends or changes, someone is assigned to review and update their system access within a set number of days, with a written checklist so the task does not depend on any one person remembering. That checklist is what closes the exact gap that had left Simone's login active for years.
7. Purged the data with no remaining purpose. Once the schedule was in place, we helped the company identify and delete the records that were already past their new retention period, including the old direct-deposit banking references, reducing the volume of sensitive information sitting in the system. Deleting what no longer served a purpose shrank the company's exposure the moment the schedule took effect, rather than leaving it to age out slowly.
8. Trained the small office team on the new rules. A schedule on paper does the company no good if the two or three staff who touch customer data day to day do not know it exists, so we walked the team through what gets kept, for how long, and who to ask before creating a new spreadsheet export that might sit forgotten for years the way the old ones had. That training is what keeps the fix from quietly unraveling the way the original problem began.

The outcome

Within a few months, the company had gone from holding an unmeasured decade of accumulated customer data to running on a retention schedule that automatically flags records for deletion once they age out. The volume of stored customer information dropped substantially once the oldest, purposeless records were purged, and the banking references from the discontinued refund program were gone entirely.

Simone's access was closed without incident. The letter framed the change as standard practice rather than a personal decision, and the friendship survived the conversation intact, in part because Cherise and Kittipong were able to point to a written policy rather than having to explain a judgment call about someone they had known for years.

The customer who first raised the question got a substantive answer: his old data had been reviewed under the new schedule and removed, and the company could now explain, in plain terms, what it kept and why. Cherise said the exercise changed how she thinks about the business generally, since the same gap between informal practice and written policy showed up once they started looking for it elsewhere too. The company now reviews its retention schedule annually, and the privacy notice on its website actually describes what happens to a customer's information rather than gesturing at it.

Kittipong, who had initially wanted to just delete the old files quietly, came around to the value of doing it properly once he saw how the documented approach protected him and his sister if a customer or regulator ever asked the same question again. Cherise now keeps a short written log whenever the company changes what data it collects or how long it keeps it, something the business had never done before, so the next review will not require starting from zero the way this one did.

What you can learn from this