The Analyst Who Left in March

In short: A Hong Kong brokerage's compliance officer pulled a list of everyone who had left in the previous eighteen months and cross-checked it against active accounts. The lists did not match. Two mailboxes still received mail, one VPN account still authenticated, four laptops were unaccounted for, and the firm was paying for nine licences attached to people who no longer worked there. None of this was negligence — it was the predictable result of treating offboarding as a task rather than a record.

Why access is a supervised control in a Hong Kong brokerage, not an IT housekeeping item

A licensed securities firm in Hong Kong operates in an environment where who can reach what is a supervised question. Client information, order and trade records, research in progress, and the systems that touch any of them are all subject to controls the firm is expected to be able to describe and evidence. This article does not attempt to interpret any specific regulatory obligation or threshold — that belongs to the firm's own compliance and legal advisers. What it describes is the operational reality underneath: whatever the requirement turns out to be, the firm can only answer it as well as its records allow.

The complicating factor in this particular business is that turnover is normal. Analysts move. Dealers move. A firm of forty to seventy people in this sector may see a meaningful fraction of its staff change in a two-year window, and none of it is exceptional or a sign of anything wrong. The offboarding process is therefore not an occasional event to be handled carefully when it happens. It runs continuously, in the background, alongside everything else — which is exactly the kind of process that decays quietly if it depends on somebody remembering.

And the scope has widened. A decade ago, offboarding meant a mailbox, a network login and a laptop. Now it means a mailbox, single sign-on, a VPN, several shared drives, a document management system, a market data terminal, a CRM, an e-signature account, a handful of departmental SaaS tools that were bought on a card, a mobile device with company mail on it, and whatever credentials that person held for systems nobody else uses. Every one of those is a separate revocation. Any one of them left open is the one that shows up in a review.

The scenario: forty-eight people, eleven leavers, and no single list

Here is a composite picture — not a named client, but a shape common enough in this market to describe plainly.

A Hong Kong securities brokerage, forty-eight staff, offices in Central. Research, dealing, operations, finance and a small compliance function. IT is outsourced to a provider who handles the help desk and the infrastructure competently, and there is one internal person who is nominally the IT contact but whose actual job is operations.

Offboarding is owned by HR, and it is a paperwork process. There is a leaver form. It covers the employment side — notice, final pay, leave balance, the return of the building access card — and it has a line near the bottom that says "IT access revoked" with a tick box. The tick box is ticked by whoever from operations is free on the person's last afternoon.

That person then does what they remember to do. They ask the IT provider to disable the mailbox. They remember the VPN, usually. They may or may not remember the market data terminal, because that is billed separately and administered by the dealing desk. They will not remember the departmental project tool that the research team started using eight months ago, because they do not know it exists. They will collect the laptop if the person is in the office on their last day, and if the person is working their notice from home, or has already gone on garden leave, the laptop is "to be arranged."

There is no single list of what a given employee actually had. The information exists — it is spread across the IT provider's ticket history, an asset spreadsheet, the Microsoft 365 admin centre, three or four SaaS admin panels, and the memory of the people who set things up. It has just never been assembled into one place, per person, and kept current.

Eighteen months later, the compliance officer assembles it for the first time, because a review is coming. That exercise takes two weeks and produces the findings above. The two live mailboxes turn out to be shared mailboxes that were converted rather than deleted, and nobody re-checked the delegated access. The VPN account belongs to a contractor whose engagement ended but whose account was never in the HR leaver process at all, because contractors do not go through HR. The four missing laptops are three that are genuinely somewhere in the office and one that a leaver still has at home. The nine licences are simply nobody's job to reclaim.

The four failures underneath, in the order they compound

There is no authoritative per-person inventory. This is the root cause and everything else follows from it. Nobody can produce, on demand, a list of every account, device, licence and credential associated with one named individual. Without that list, revocation is a memory exercise, and memory exercises fail at the margins — the tool one team uses, the contractor who was never in the HR system, the second device issued during a hardware fault and never returned.

Revocation depends on someone remembering a system. Because the list does not exist, the process is "disable the things we think of." That works for the obvious ones and fails for exactly the ones that matter in a review: the long-lived service account, the shared mailbox with delegated access, the SaaS tool bought departmentally. The failure rate is not high, but it is not zero, and over eleven leavers a non-zero rate compounds into findings.

Hardware quietly disappears. Not through dishonesty. A laptop goes home during a notice period and is not collected because nobody owns collecting it. A device issued as a temporary replacement stays temporary for two years. A monitor and dock go to someone's flat during a hybrid-working arrangement and stay there after they leave. Individually trivial; collectively an asset register that is fiction, and — more importantly — devices holding company data that the firm no longer controls.

Licence spend only ever grows. Nobody reclaims seats, because reclaiming a seat requires knowing that the seat exists and that its holder has left. Nine unused licences in a firm of forty-eight is not a large sum in absolute terms, but it is a permanent, compounding overpayment and it is a precise indicator of the underlying problem: if the firm cannot see an unused licence, it cannot see an unused account either, and the second one is the one that matters.

The consequence of all four is a compliance answer that rests on assurance rather than evidence. Asked whether leavers retain access, the firm can say "no, we revoke access when people leave." What it cannot do is produce a dated record, per leaver, showing what was revoked, when, and by whom. In most reviews the difference between those two answers is the entire finding.

Brocent's perspective: offboarding fails because it is treated as an ending

The usual response to an audit finding like this is a better checklist. Longer, more thorough, with more systems on it, signed off by two people instead of one.

That helps at the margin and then decays, for a straightforward reason: a checklist is a list of things someone thought of at the time the checklist was written. It goes stale the moment a team adopts a new tool. It cannot cover contractors if contractors do not enter the process that generates it. And it produces a signature, not evidence — the artifact it leaves behind is proof that a form was completed, not proof that access was actually removed.

The more durable framing is this: offboarding fails because it is treated as a task at the end rather than a record kept all along. If joining is the event that creates the record — this person, these devices, these accounts, these licences, these credentials — then leaving is simply running that record backwards. The checklist stops being something a person composes from memory and becomes something the system produces, per individual, because the system has been maintained continuously rather than reconstructed at the exit interview.

The corollary matters as much: the artifact matters more than the checklist. What a firm needs at a review is not a completed form. It is a dated leaver report showing every account disabled, every device recovered or wiped, every licence released, and every credential handed back — generated from the same record that governs the environment day to day, so that it is inherently accurate rather than separately compiled.

What this looks like in practice

Six mechanics, each grounded in something Brocent actually runs rather than a generic process diagram.

An asset register that ties devices and licences to a named person from day one. BCS Beam, Brocent's endpoint services client, is a single signed agent installed on managed devices. It gives engineers consent-first, fully audited remote support access, and it continuously reports each device's security and health state — disk encryption, antivirus, firewall and patch status checked against CIS-aligned benchmarks, with installed software matched daily against the CVE catalog. For offboarding, the relevant property is that a managed device is a known device: it is in the record because it reports itself, not because somebody typed it into a spreadsheet.

Licence governance that surfaces seats nobody has signed into. The "one engine rather than a stack of tools" argument is not just an architecture preference — it is what makes cross-cutting questions answerable. A seat that has had no sign-in for ninety days is a fact the environment can surface on its own. That single signal catches the leaver whose account was missed, the contractor who was never in the HR process, and the genuine overspend, all in the same query.

A documented revocation sequence, not a remembered one. Mail and calendar. Single sign-on and any local directory account. VPN and remote access. Shared drives and document management. Third-party SaaS, including the departmental tools. Market data and trading system access. Service accounts and API keys the person held. Physical access. The sequence matters because some revocations depend on others — disabling the identity before you have exported what needs retaining is a common self-inflicted wound — and because doing it in a fixed order is what makes it auditable.

Device recovery, and a real answer when recovery does not happen. Where a device is returned, it is wiped and returned to stock with the record updated. Where it is not — the leaver has it at home, or is uncontactable, or the relationship ended badly — MDM provides the fallback: corporate data can be remotely wiped from an enrolled device within minutes, with a full wipe for corporate-owned hardware and a selective wipe for a personal device carrying company mail. This is the difference between "we have asked them to return it" and "the company data is off it." The second one is a fact you can write down.

Credentials handed back into customer-owned documentation, not an engineer's memory. Two of the thirteen items included at every Brocent managed IT plan tier are directly relevant here: password and credential management, and customer-owned docs and credentials. The second is the one people underestimate. Documentation and credentials belong to the customer, which means that when a person leaves — whether that person is the client's employee or the provider's engineer — the knowledge does not leave with them. A firm whose systems are documented in one engineer's head has an offboarding problem it has not noticed yet.

A dated leaver report the firm can put in front of a reviewer. The output of all of the above is a per-leaver artifact: what they had, what was revoked, when, by whom, what was recovered, and what was wiped. It is produced from the operating record, which is what makes it credible. It sits alongside the rest of the firm's security posture under managed IT security services, and the commercial structure is on the managed IT support page.

Three ways firms handle offboarding

Ad-hoc offboarding — "we'll disable the account on Friday"

• What it is: IT tasks handled by whoever is available on the leaver's last day, from memory, with no defined list and no record kept afterwards.
• What it costs: Nothing visible until something is found. Then it costs a remediation exercise, an uncomfortable conversation about how long an account was live, and a finding that is hard to close because the evidence for the past does not exist and cannot be created retroactively.
• Who it suits: A firm small enough that one person genuinely holds the whole environment in their head, and stable enough that they are not going anywhere. Both conditions have to hold.

An HR checklist with no system behind it

• What it is: A leaver form with an IT section. Systems are listed. Boxes are ticked. Signatures are collected.
• What it costs: It looks like control and produces the appearance of evidence, which is the dangerous part — the firm believes it is covered. But the list reflects what was true when it was written, it does not cover tools adopted since, it usually does not cover contractors, and a tick confirms that someone said they did something rather than that the environment changed. The gap between the form and reality is invisible precisely because the form exists.
• Who it suits: It is a genuine improvement on nothing, and it is the right first step. It stops being sufficient at the point somebody asks for evidence rather than assurance.

A managed asset-and-identity record — the model Brocent recommends

• What it is: Devices, accounts, licences and credentials tied to named individuals from the day they join, maintained continuously by the systems that manage the environment, with offboarding executed as a defined sequence against that record and a dated report produced as output.
• What it costs: A managed IT arrangement rather than a form, and the up-front work of establishing the record for people who are already there — which is the honest catch: the model works from the joining event, so an existing firm has to do one reconciliation exercise to get to a clean baseline.
• Why it holds up: Because the record is maintained by operating the environment rather than by remembering to update it, it does not decay between reviews. New tools appear in it because they appear in the environment. Contractors appear in it because they are issued access, whether or not HR has a file on them. And the evidence is a by-product rather than a project.

Where to start if this describes your firm

Not with a policy rewrite. Start with the reconciliation: take every person who has left in the last twelve to eighteen months and check them against active accounts, devices and licences. It is a two-week exercise and it is uncomfortable, but it establishes the baseline and it tells you the size of the actual problem rather than the imagined one.

Then fix the joining side, because that is where the record is created, and a clean joining process makes every future leaving process trivial. Fixing the leaving side first is the more intuitive order and the less effective one.

If you want a second pair of eyes on the reconciliation, or on what the record should contain for a firm of your size and regulatory profile, talk to us — it is a conversation about your actual environment, not a product pitch.

Frequently asked questions

How quickly should access actually be revoked after someone leaves?

The operational answer is that revocation should complete on the last working day, and the mechanism should not depend on anyone being in the office for it to happen. Whether a specific timeframe is required of your firm is a question for your compliance function and your own regulatory advisers — this article does not assert a threshold. What is worth saying plainly is that the practical constraint is almost never speed. It is completeness. Firms rarely fail because a mailbox was disabled on Monday instead of Friday; they fail because an account nobody listed stayed live for a year.

What if the employee never returns the laptop?

Then the question changes from recovering hardware to removing data, and those are separable. With the device enrolled in MDM, corporate data can be remotely wiped within minutes of the instruction — a full wipe for a corporate-owned device, a selective wipe removing only company content from a personal one. The practical caveat is that the command reaches the device when the device next connects, which is why enrolment and encryption together matter more than wipe alone. Recovery of the physical asset then becomes an HR and finance matter rather than a security one, which is a much better place for it to sit.

Who is supposed to own offboarding — HR or IT?

HR owns the event; IT owns the execution; and the failure mode is assuming that a handoff between them is a process. HR knows someone is leaving and when. IT knows what that person had. Neither list is complete on its own, and the gap between them is where contractors, departmental tools and second devices fall through. The workable arrangement is that HR triggers, the record supplies the list, IT executes against it, and the output is a single dated artifact both functions can point at.

How do we find licences we're still paying for?

The reliable signal is sign-in activity rather than the licence list. A seat with no sign-in for ninety days is either a leaver whose account was missed, a contractor nobody tracked, or a genuine overspend — and all three are worth finding. This is the same query that catches the access problem, which is why licence governance and access governance should not be treated as separate exercises. The financial recovery is real but secondary; the point is that a seat nobody signs into is a seat nobody is watching.

Does deleting a mailbox lose records we're required to keep?

It can, and this is why sequence matters more than speed. Retention requirements for business records are a matter for your compliance function and your legal advisers — we make no assertion about what applies to your firm. Operationally, the safe pattern is to preserve first and revoke second: place the mailbox under the appropriate retention or hold arrangement, convert or archive it according to the firm's policy, and only then remove interactive access. Deleting first and reconstructing later is the mistake that turns an offboarding task into an incident.

What evidence should we be able to produce at a review?

At minimum, per leaver: the date they left, the list of accounts, devices, licences and credentials they held, the date and actor for each revocation, the disposition of each device (returned and wiped, or wiped remotely), and confirmation that credentials they held were rotated. The important property is that this comes from the record that runs the environment rather than being assembled for the review — a document compiled specially for an auditor invites the obvious follow-up question about what it was compiled from.

We use an outsourced IT provider. Does that change who is accountable?

No. Outsourcing execution does not outsource accountability, and a reviewer will ask the firm, not the provider. What a provider should change is your ability to answer — the record, the documented sequence, and the artifact should all be things you can obtain on request, and the credentials and documentation should be yours rather than the provider's. That last point is worth checking in any existing arrangement: if leaving your provider would mean losing the documentation of your own environment, you have a version of the same offboarding problem one level up.

Our contractors never go through HR. How do we catch them?

By anchoring the record to access issued rather than to employment status. A contractor who is given a VPN account, a mailbox or a device is in the environment regardless of whether HR has a file on them, and a record built from what the environment actually contains will include them. This is the single most common gap we see in firms of this size, and it is also the one where the "checklist" model fails most reliably, because the checklist is generated by an HR process the contractor was never in.