A Customer Says a Tech Shared Their Alarm Code

Why this matters

A customer who believes your technician leaked their alarm code is not complaining about a repair. They are telling you their house stopped feeling safe, and they have already picked a suspect. Handle it as a personnel matter and you either fire someone who did nothing or defend someone who did, with no way to know which. Handle it as a records question and the answer is usually sitting in three logs you already have. In the case below, the answer was not a person at all. It was where the shop kept the code.

The call

A homeowner, here called the Ruiz household, phoned the office on a Monday. Their monitoring company had sent an alert the previous Thursday at 1:40 in the afternoon: the system was disarmed with a valid code while both of them were at work. Nothing was taken, and the monitoring company said the disarm looked like a normal entry. Mrs. Ruiz had given that code to exactly two parties: her sister, and your shop, when a tech replaced the water heater 23 days earlier. Her sister was out of state. So, she said, it was your tech.

The office manager did three things on that call, and they are the right three. She did not argue. She did not promise discipline. She said: "I am going to pull every record we have on how that code was stored and who could see it, and I will call you back by Wednesday with what I find. In the meantime, please change that code today, and ask your monitoring company for the event log from Thursday." Changing the code first matters more than anything the shop finds later, because whoever used it still has it.

Start from what the customer's panel already recorded

Most alarm panels log events by user code slot, not just by "disarmed". A panel typically holds a master code plus a handful of numbered user codes, and the event log says which slot was used. That is the first fork, and it costs the customer one phone call to resolve.

The Ruiz log, as the monitoring company read it to her:

EVENT LOG  (as read by monitoring company)
THU 13:40  DISARM   USER 01 (MASTER)   KEYPAD 1
THU 13:41  ZONE 04  KITCHEN MOTION     (disarmed)
THU 13:52  ZONE 01  FRONT DOOR OPEN    (disarmed)
THU 13:53  ARM AWAY USER 01 (MASTER)   KEYPAD 1
-- prior entries --
3 wks ago  DISARM   USER 01 (MASTER)   KEYPAD 1  09:05
3 wks ago  ARM AWAY USER 01 (MASTER)   KEYPAD 1  15:20

Two things stand out. The code used was the master code, slot 01, which means Mrs. Ruiz had given the shop her master code rather than a separate service code. And the intruder re-armed on the way out, twelve minutes later, which is the behavior of someone who expected to come back unnoticed rather than someone grabbing what they could. The 09:05 and 15:20 entries three weeks earlier match the water heater appointment window on the shop's own ticket.

If the log had shown a slot the shop was never given, the investigation would have stopped there and pointed elsewhere. It did not, so the shop had to account for every place that code lived on its side.

Trace every copy of the code

The office manager did not start with the tech. She started with the code itself and asked: in how many places does this string of four digits exist in our systems, and who could read each one? This is the move that separates a records review from an accusation. A code given to a shop rarely stays in one place.

She found four copies:

• The customer record's general notes field in the field-service software: "Alarm 4-digit code is ####, panel by back door." General notes were visible to every active login.
• The job's work order, which pulled the general notes onto the printed and PDF ticket automatically.
• A text message from the dispatcher to the tech's work phone the morning of the job, repeating the code and the address.
• The paper work order itself, printed for a tech who preferred paper, which went into a clipboard in the truck.

The customer pictured one copy in one head. The shop had made four, and three of them carried the address in the same view as the code, which is the combination that turns a number into a key.

What the software logs showed

Most field-service and CRM systems keep a record-view or audit log, though it is often off by default or kept only for a limited window. This shop's software recorded who opened a customer record and when. The pull showed:

• The assigned tech opened the Ruiz record twice, both on the job day, and never again.
• Two office users opened it during scheduling and invoicing, as expected.
• Eleven active logins in total could see general notes. Two of them belonged to people who had left the company four and seven months earlier and had never been deactivated. Neither had opened the Ruiz record, according to the log.
• One login was a shared office account used by three people, so for that account the log could only say "someone in the office".

That last point is the limit of every review like this. A shared login turns a precise log into a shrug. See related: The Shared Login Problem. The former-employee accounts were a finding in their own right even though they did not explain this event. See related: The Former Employee Still Had Access.

The hypotheses, and what killed each one

The assigned tech passed it on. Possible in principle, and the customer's theory. Against it: he viewed the record only on the job day, the text message to his phone was still there and had not been forwarded, and the entry pattern (re-arming on exit) did not fit a tech who knew he would be the first suspect. None of that proves innocence. It means there was no evidence pointing at him, and an owner who acts on suspicion alone is making the decision the customer made, with less excuse.

A former employee with live access. The logs showed no view of the record by either stale account, and their passwords had not been used for sign-in since they left. The software's sign-in history is a separate log from the record-view log, and both were checked. Ruled out for this event, fixed anyway.

The paper ticket. Here the office manager found the thing that mattered. The night after the Ruiz job, eighteen days before the Thursday disarm, that same truck was broken into in the tech's driveway. The police report, filed at the time and saved in the shop's incident folder, listed a tablet charger, a meter and "a clipboard of paperwork". Nobody at the time thought about what was on the paperwork. The clipboard held the Ruiz work order, with the address, the panel location and the master code printed together on one page.

What the evidence supported

The shop could not prove the stolen ticket was the source. It could show a documented theft of a page carrying the code and address, eighteen days before a disarm with that code, and no other path in its records with any evidence behind it. That is enough to act on and not enough to state as fact, and the call back to Mrs. Ruiz said exactly that:

"We found that a printed work order with your address and the code you gave us was in a truck that was broken into the night after your job. We reported the break-in at the time, but we did not realize your code was on that page, and we should have. We have no evidence your technician shared it. We are changing how we store codes so this cannot happen again, and I can send you a copy of the police report number for your own report."

She took it well, mostly because she was given a specific finding instead of either a defense or a sacrifice.

Why the finding was the storage

Every link in that chain was a storage decision nobody had made on purpose:

• The code lived in a free-text field that was readable by every login and printed by default.
• The code and the address appeared on the same page, so one lost page was a complete key.
• The shop had taken a master code when a temporary user code would have done, so the customer could not simply delete the shop's access after the job.
• A truck break-in was treated as a property loss, and nobody asked what customer information left with the paperwork.

Fix those four and the next incident is either impossible or much smaller. The procedure itself, from asking for the code to deleting it after the job, belongs to the shop's code-handling SOP. See related: The Customer Key and Code Handling SOP.

What would have pointed somewhere else

The conclusion would have been different under any of these:

• The panel log shows a slot the shop never had. Then the leak is on the customer's side: a cleaner, a dog walker, a contractor from last year. Say so plainly and offer the log reading back to them.
• The record-view log shows a view by someone with no reason to open it, near the date of the disarm. Then it is a personnel question with real evidence behind it, and it goes to the owner and, if theft is suspected, to the police.
• No view log exists at all. Then the honest answer is that the shop cannot tell, and the fix is the same storage change plus turning the log on today, so the next review has something to read.

On the legal side

An alarm code is generally not "personal information" under state data-breach notification statutes, which mostly define that term around names combined with Social Security numbers, account or card numbers, driver's license numbers and similar identifiers, and the definitions differ state to state. So a lost page with a code and address usually does not trigger a formal breach notice, though a page that also carried, say, a card number would. Telling the customer is right regardless of whether a statute requires it. If a customer threatens a claim, stop the review at the records stage and send what you found to your insurance agent and attorney. This is not legal advice. See related: Handling a Data Breach Notification Obligation.

References

• See related: The Customer Key and Code Handling SOP
• See related: Customer Keys, Codes and Lockbox Custody
• See related: The Shared Login Problem
• See related: The Former Employee Still Had Access
• See related: Handling a Data Breach Notification Obligation