The Former Employee Still Had Access

Why this matters

Most shops find out a former employee still had access the same way: months late, from an automated email nobody was expecting. By then the question is no longer "how do we lock this down" but "what did they reach, what did they do with it, and why did our offboarding miss it." This case works backwards from that email, using only what the shop's own systems had written down, and the gaps in those records turn out to be as important as the entries.

The alert that started it

A fourteen-person heating and cooling shop. In late August the owner got a routine security email from the shop's field-service software: a new sign-in from an unrecognised device. The account was Dana's. Dana had been the shop's lead dispatcher and had left on good terms in mid-March to take an office job across town.

The owner's first instinct was that it was a glitch, or a stale session on an old office computer. That instinct is wrong more often than it is right, and it is worth saying why: a "new device" alert means the system saw a sign-in it could not match to a known device, which a forgotten office tab does not produce. A real person typed a password somewhere.

First move, before any investigation: disable the account, do not delete it. Deleting it in most systems destroys the activity history attached to it, which is the evidence this whole review runs on. Disabling stops the access and keeps the record. The owner did that within ten minutes and then started reading.

What the record showed

The field-service software kept a sign-in history and an export log. Pulled for Dana's account from her last day forward, it read like this:

USER   EVENT        DATE      DEVICE        NOTE
dana   sign-in      Mar 18    office-pc-2   last day
dana   sign-in      Apr 09    new-browser   home IP
dana   export       Apr 09    new-browser   customers.csv
dana   sign-in      Apr 22    new-browser
dana   sign-in      May 06    new-browser
dana   export       May 06    new-browser   pricebook.csv
dana   sign-ins x7  Jun-Aug   new-browser   view only
dana   sign-in      Aug 27    phone-new     ALERT SENT

Read carefully, that is eleven sign-ins after her last day (one each on April 9, April 22 and May 6, seven across June to August, and the August 27 one that triggered the alert), and two exports: the full customer list three weeks after she left, and the price book four weeks after that. The June to August sign-ins show no exports and no edits, only views of the schedule and a handful of customer records.

Three things fall out of that log before anyone talks to anybody.

The alert was not the first unusual sign-in. The April 9 sign-in was also from a new browser. The software sent no alert then, because device-change alerts had been switched on by the owner in July after reading an article. Every earlier sign-in happened in silence.

The activity has a shape. A burst of extraction in the first seven weeks, then months of light browsing. That pattern is consistent with someone who took what they wanted early and then kept looking out of curiosity or habit, which is a different story from someone actively working against the shop every week. It does not tell you intent, and the owner was careful not to decide intent from a log.

The August alert came from a phone. A new phone, months after leaving, suggests the password had been saved in a browser and carried across when she replaced her device. That matters later: it means the password was never changed after she left, not that she worked to get it back.

What else she could reach

The field-service software was the only system with a usable log. The owner then sat down with the office manager and built a list of every system Dana had touched in her two years, from memory, from the browser's saved passwords on her old desk computer, and from the shop's card statements (any recurring software charge is a system someone logs into).

The shop's written offboarding checklist had six lines on it: email, the field-service software, the office door code, the shop phone extension, payroll, and the fuel card. All six were ticked on March 18, except that the field-service line had been ticked when the office manager removed Dana from the dispatch schedule, which is not the same thing as disabling her sign-in. That one confusion is the whole incident.

The rebuilt list ran to fourteen systems. Beyond the six, Dana had held:

• the parts supplier's ordering portal, on a single shared shop login
• the equipment distributor's warranty portal, under her own name
• the shop's business social media accounts, as an admin
• the online review profile, as a manager
• the shared voicemail box for the after-hours line
• the shared cloud folder holding scanned permits and customer photos
• the payment processor dashboard, view-only
• the domain registrar, as a secondary contact on the account

Of those eight, four had no activity log the shop could read: the supplier portal, the voicemail box, the cloud folder's free tier, and the registrar's contact role. For those, the honest answer to "did she get in" is "we cannot tell." The owner wrote that down as a finding, not a gap to paper over. A review that says "no evidence of access" about a system that keeps no evidence is reporting on its own blindness.

The four with logs (social, reviews, warranty portal, processor) showed no sign-ins after March. That is real reassurance for those four and nothing more.

Separating what happened from what could have

The owner's written summary split the case into three columns, which is the most useful thing a shop can do at this stage because it stops the worst case from being treated as the known case.

The registrar row is worth a note. The contact role itself kept no sign-in log the shop could see, but the domain's own settings (where it points, who it is registered to) had not changed since the previous year, so the worst outcome there was ruled out by a different record. Checking the result when you cannot check the access is a legitimate move.

Where the call forks

At this point the shop had a factual picture and a decision about what to do with it. This is where the article stops being operational and becomes a list of what to walk into a professional's office with. This is not legal advice.

Whether it is a crime or a civil matter is a question for an attorney, and it is not obvious. The federal Computer Fraud and Abuse Act (18 U.S.C. 1030) covers accessing a computer without authorization, and since the U.S. Supreme Court's 2021 decision in Van Buren v. United States courts read it narrowly. An employer who never revoked a credential may struggle to argue access was unauthorized, though a departed employee has no ongoing business reason to be there. Most states have their own computer-access statutes that read differently, and trade secret law sits alongside both: the federal Defend Trade Secrets Act (18 U.S.C. 1836) and the state version of the Uniform Trade Secrets Act most states have adopted. Whether a customer list or price book counts as a trade secret depends heavily on whether the shop treated it as secret, and a shop that left the door open for five months has weakened that argument itself.

Whether customers must be notified is a separate question with its own owner. State breach-notification statutes generally key on specific data types (Social Security numbers, financial account numbers, driver's license numbers, and in some states health or login data) rather than on names, addresses and phone numbers. A customer list without those fields usually falls outside them, but the definitions vary state to state and a few are broader. See related: Handling a Data Breach Notification Obligation.

Walk into the attorney's office with: the exported log for the field-service account, saved as a file and as a screenshot with the date visible; the fourteen-line system list with the three-column table; the original six-line offboarding checklist showing what was ticked and when; Dana's last day and her new employer if known; and any employment agreement or handbook page she signed covering confidentiality. Do not contact the former employee before that meeting. A friendly "hey, did you log in?" text is exactly what an attorney would want to have drafted differently, and it tips off anyone who has something to delete.

In this case the attorney recommended a short, factual letter asking Dana to confirm she had deleted the two files and would not access shop systems again, rather than litigation. The shop's damages were hard to show, the access had gone unrevoked by the shop's own failure, and the files had real but modest value. A different shop, with a competitor's quotes undercutting it on its own customer list within weeks, might reasonably have gone further. That is the attorney's call to make with the facts in hand.

The offboarding gap, stated exactly

The root cause was not that the shop had no offboarding process. It had one, followed on the day. The process listed six systems against a real footprint of fourteen, and it allowed "removed from the schedule" to stand in for "sign-in disabled." Both failures are common and both are fixed by the same two changes.

The checklist is generated from the account list, not written from memory. A shop that keeps a current list of every system and who holds a login to each can produce a person's offboarding list by filtering it. A shop that writes the offboarding list at the moment someone leaves will always write the systems it thinks about most. See related: The Account Inventory Every Shop Should Keep.

Every line says what "done" looks like. "Field-service software: account disabled, sign-in tested and refused" cannot be ticked by taking someone off a schedule. See related: The Employee Offboarding Digital Access SOP.

The shared logins were their own lesson. The supplier portal and the voicemail box could not be revoked for Dana alone, because everyone used the same password; changing it meant re-telling five people. That friction is why it had not been changed when the previous two employees left either, so in effect three former staff had held it. See related: The Shared Login Problem.

How they checked the fix held

Two months later the office manager ran a test. She took the next departing employee's name, a seasonal installer leaving in October, and tried every system on his filtered list the morning after his last day using a spare browser and his old credentials, which she had recorded before resetting them. Nine systems were on his list; all nine refused the sign-in. She logged the test with the date and the result for each.

That test is the part most shops skip, and it is the only thing that would have caught the original gap. A ticked checklist proves someone believed they did the work. A refused sign-in proves the work was done.

References

• 18 U.S.C. 1030 (Computer Fraud and Abuse Act) and Van Buren v. United States, 593 U.S. 374 (2021)
• 18 U.S.C. 1836 (Defend Trade Secrets Act) and your state's enactment of the Uniform Trade Secrets Act
• See related: The Employee Offboarding Digital Access SOP
• See related: The Account Inventory Every Shop Should Keep
• See related: The Shared Login Problem