The situation
Vartan had already tried to fix it himself, twice. His company supplies dosage packaging and inventory software to independent pharmacies and veterinary clinics across the region, a business he had built from a part-time side project into something doing close to $600,000 a year. The company's systems held prescription-adjacent customer data for dozens of clinics, and one contractor, Duc, had built and maintained nearly all of it since the beginning, with full administrator access to every account, every client database, and every backup.
The first attempt was a conversation. After a laptop belonging to Duc was stolen from his car - with an active session logged into the company's client portal still open on it - Vartan asked him, informally, to set up more restricted logins and stop using one shared administrator password for everything. Duc agreed on the phone and said he would get to it. Eight months later, nothing had changed, and Vartan discovered the same shared password was still being used when he asked a favour of Duc's assistant and was handed the login without hesitation.
The second attempt was an email, more pointed this time, asking Duc to draft a short security policy and confirm it was in place. Duc sent back two paragraphs restating what he already did, without addressing the shared password or the scope of his access at all. Vartan did not know how to push further without damaging a relationship he depended on - Duc was the only person who understood the company's systems well enough to keep them running, and there was no one else lined up to replace him.
What made the gap urgent rather than merely uncomfortable was a hiring decision. Vartan was close to bringing on the company's first outside executive, a chief operating officer from outside the founding circle, someone who would expect to see real vendor contracts and real data security terms rather than a decade of informal trust. He came to us not with a breach to report, but with a question he could not answer with confidence: if a regulator or a new executive asked what controls existed over who could see client data, what would he actually be able to show them? Two informal attempts had produced nothing more than a promise and a paragraph, and Vartan had run out of ways to ask nicely.
What was actually at stake
What was actually at stake was not one stolen laptop. It was whether the company had any meaningful control over data that dozens of clinics had trusted it with, and whether that could be demonstrated to anyone who asked - a client renewing a contract, an incoming executive doing his own due diligence, or, in the worst case, a regulator responding to a complaint. A shared administrator password used by one contractor and, apparently, his assistant, meant the company could not say with confidence who had accessed a given client's records on a given day, or prove that access had ever been limited to people who needed it for their work.
The clinics whose data lived in the system were themselves handling sensitive patient information, and their contracts with Vartan's company generally required reasonable security measures in return. 'Reasonable' is a flexible word, but a single shared login with no access logs and no limits on scope sits well outside almost any definition a court or a client would accept after the fact. If one of those clinics ever asked to see the company's data security terms with its own vendors, the honest answer was that no written terms existed at all - the entire arrangement with Duc rested on a decade of trust and a verbal understanding from when the company had one employee and no client data worth worrying about.
The hiring decision raised the stakes further. Bringing in an outside chief operating officer meant, for the first time, someone with no personal loyalty to Duc and every professional reason to ask hard questions about vendor access before accepting the role. A COO candidate doing basic diligence on a company handling health-adjacent data would reasonably expect a written vendor agreement covering access, confidentiality, and what happens if the relationship ends. Walking into that conversation with nothing in writing risked either losing the candidate's confidence or, worse, having the gap surface only after the hire, at a point where fixing it would look like a problem being managed rather than a house already in order.
There was also a practical risk specific to Duc himself. Full administrator access with no contract meant the company had no clear right to revoke that access, recover its systems, or restrict what Duc could do with client data if the relationship ever soured - a risk that mattered more, not less, given how dependent the business had become on him.
What we did
- Mapped what Duc actually needed access to, separate from what he had. We interviewed Vartan and his staff about which systems Duc genuinely maintained day to day - the inventory platform and the billing system - versus systems he had administrator rights to purely by historical accident, like the client portal holding prescription-adjacent records he rarely touched. This separated the real dependency from the excess access that had never been reviewed.
- Drafted a written vendor agreement covering access, confidentiality, and termination. No contract had ever existed with Duc, only a verbal understanding from a decade earlier. We put in writing what data he could access, his confidentiality obligations toward client records, and what would happen to his access and any copies of company data if the relationship ended, so the company would have an enforceable document rather than a memory of a phone call.
- Proposed role-based access replacing the single shared administrator login. Instead of one password used by Duc and, apparently, his assistant, we proposed individually named accounts with access scoped to the systems each person actually worked in, along with basic logging so the company could later show who had accessed a given record and when, which is the kind of answer a clinic or an incoming executive could actually rely on instead of a verbal assurance.
- Paused negotiations for six weeks after Duc's father passed away suddenly. Midway through reviewing the draft terms, Duc lost his father and stepped back from all work commitments to handle the funeral and his family's affairs. We advised Vartan to hold the file rather than push a vendor already anxious about losing access during a period of real personal loss, which meant resetting the timeline we had originally given him.
- Resumed with a narrower, faster-to-close draft once Duc was ready. Rather than reopening every point from the original proposal, we trimmed the agreement down to the terms that mattered most - access scope, confidentiality, and termination rights - so Duc could review and respond to something short rather than relitigating a long contract while still managing a difficult few months.
- Negotiated the access boundary Duc pushed back on hardest. Duc resisted losing administrator rights to the client portal entirely, arguing he occasionally needed it for emergency troubleshooting outside business hours. We negotiated a compromise: standing access removed, replaced by a temporary elevated-access request he could trigger himself and that logged automatically, giving him a real path to emergency access without a permanent open door.
- Finalized the agreement and helped the company implement the new logins. Once terms were settled, we finalized the written agreement, and Vartan's staff worked with Duc to retire the shared password and set up the individually scoped accounts, giving the company, for the first time, a written record of who could see what and a signed agreement it could actually point to if anyone ever asked.
The outcome
The company ended up with a written vendor agreement, individually scoped logins, and a logged process for emergency access - genuine improvements over a decade of one shared password and no contract at all. It did not end up with everything we or Vartan had originally wanted. Duc retained a form of privileged access to the client portal, just no longer a standing one, and the company accepted that trade because Duc remained, realistically, the only person who understood the systems well enough to respond to an after-hours failure without weeks of onboarding someone new.
The process took roughly four months rather than the six weeks originally estimated, almost entirely because of the pause after Duc's father died. Vartan chose not to push a hard deadline through that period, which meant the company's first outside executive hire went ahead with the vendor agreement still in draft, not finalized. We advised Vartan to be direct with the incoming COO about that timeline rather than let it surface as a surprise, and he was: the candidate accepted the role with the agreement's completion listed as an open item, which turned out to matter less to the hire than Vartan had feared.
What the company gained was not a clean before-and-after story but a real, working compromise. Vartan still depends on one contractor more than a company handling client data probably should, and the emergency-access provision is, honestly, a narrower gap rather than a closed one. What changed is that the gap is now written down, logged, and time-limited instead of unlimited and invisible - a meaningfully smaller risk than the one he brought to us, even if it is not the risk-free outcome either side started out hoping for.
Ngoc, the company's pharmacy technician, was among the first staff to get an individual login rather than borrowing a shared one, and told Vartan afterward that she had not realized until then how casually client information had been treated before. One of the veterinary clinics on the client list asked its own veterinary technician to confirm, in writing, that the vendor agreement covered its records specifically - a request Vartan could finally answer with a document instead of a verbal assurance, which was exactly the gap the file had set out to close. That reaction, more than any single clause in the agreement, was what convinced Vartan the compromise had been worth the extra months it took to get there.
What you can learn from this
- If a vendor has broad access to your systems on nothing more than a verbal understanding, put it in writing before you need it, not after something goes wrong.
- Map what a contractor actually needs access to, separately from what they have. The two lists are rarely the same, and the gap is often where real risk sits.
- A single shared login makes it impossible to show who accessed what and when. Individually scoped accounts with basic logging cost little and answer questions you cannot otherwise answer.
- A negotiated compromise that narrows a risk and documents it is a legitimate outcome, even when it falls short of eliminating the risk entirely - do not treat a partial win as a failure.
- Personal circumstances on the other side of a negotiation are real. Building flexibility into your timeline protects the relationship you may still depend on once the file closes.
This is a corporate problem we handle
Start a file online — flat, published fees, reviewed by a licensed lawyer before a dollar is owed.