Protecting Source Code from Departing Engineers: An IT Services Playbook

Indian IT services companies handle hundreds of customer engagements simultaneously. Each engagement contains source code, architecture diagrams, customer data, and intellectual property that belongs to the customer (under standard MSAs) or to the services company itself. A departing senior engineer who walks out with these assets creates two problems at once: customer-contract violations and competitive harm.

This post is the practical playbook used by Indian IT services CISOs to prevent the most common exfiltration patterns during the notice period.

The pattern: what departing engineers actually do

Aggregated signals from 30+ Indian IT services deployments show a remarkably consistent exfiltration pattern:

The pattern is recognisable because most exfiltration is opportunistic rather than premeditated — engineers grab things they think will be useful at their next job. That very predictability is what makes detection feasible.

The five controls that matter

Control 1: Repo-access audit on a rolling 30-day window

Every commit, clone, and download from Git (GitHub, GitLab, Bitbucket, or your internal Git server) creates an audit trail. Most companies have the data and ignore it. The actionable check:

• For each engineer, weekly: did they access any repository outside their team's normal portfolio?
• For repos they did access: did clone volume spike vs their 90-day baseline?
• Cross-reference with HR: anyone on notice period gets weekly review automatically

Control 2: USB lockdown for engineering teams

Engineers are the highest-risk user category for USB exfiltration. Block USB writes by default for the engineering OU; whitelist specific devices and roles where required (see our USB control guide).

Don't rely on a generic "USB blocked" policy. Configure file-type inspection — block writes of code-file extensions (.py, .js, .ts, .java, .go, .cs, .cpp, etc.) outright, even on whitelisted devices.

Control 3: Cloud-upload monitoring with code-specific patterns

Personal Dropbox / Drive / OneDrive / WeTransfer / GitHub-personal uploads from work endpoints. The combination of (a) engineer in notice period plus (b) any new cloud destination plus (c) upload size over 50 MB is a near-certainty signal.

For code specifically: monitor uploads to github.com when the destination isn't a sanctioned company repository. A push from work-laptop to a personal GitHub account is almost always either a deliberate exfiltration or a sloppy git-config (still investigate).

Control 4: Notice-period UEBA

The single highest-leverage control. When HR submits a resignation, automatically tag the user in your monitoring system as "notice period" — and reweight UEBA signals on that user for the duration:

• Off-hours activity score: ×2
• Repo-access-outside-scope: ×3
• USB events: ×3 (and alert immediately on any)
• Cloud-upload events: ×2.5
• Large-file moves: ×2

Result: a user who would normally score 60 on baseline behaviours scores 150-180 once tagged. Alerts fire on subtle patterns instead of waiting for blatant ones.

Control 5: Exit-day revocation playbook

The day-of-exit checklist matters because the residual-access problem is the most common cause of post-separation incidents. The exit checklist:

1. Revoke SSO / IdP access (Azure AD, Okta) — central control
2. Revoke Git access (GitHub, GitLab orgs) including personal-token revocation
3. Revoke VPN profile
4. Reset shared-account passwords if the engineer had access (and document why shared accounts existed at all)
5. Recover company laptop with forensic imaging if exfiltration is suspected
6. Revoke access to customer-managed environments (customer's AWS / Azure / GCP roles)
7. Notify customer security team where customer NDAs require it
8. Run a residual-access audit 7 days after exit — any logins post-revocation indicate missed accesses

The legal layer: what to put in place before you need it

Three documents that make post-incident legal recovery practical in India:

• Robust NDA at hiring — covers confidential information, IP assignment, post-termination obligations. The NDA + employment contract together are the legal basis for IPC Section 405 (criminal breach of trust) and Section 408 (criminal breach of trust by clerk or servant) in egregious cases.
• Specific customer-data clauses in the customer MSA flowed down to engineers — gives the customer standing to push for resolution and is often what brings real consequence pressure.
• Documented monitoring consent — the audit logs are admissible evidence only if collection was consented to. See our consent form template.

Civil suits (NDA enforcement, injunctive relief) take 18-36 months in Indian courts. Criminal complaints under IPC are faster (police FIR + chargesheet) but still resource-intensive. Prevention is dramatically cheaper than litigation — every documented incident we've seen recovered, the recovery cost exceeded what monitoring would have cost for the same engineer for 10 years.

The org-chart conversation

Engineers as a population react badly to "you are being watched because we don't trust you." The frame that works:

"Our customer contracts require us to demonstrate that source code stays inside approved repositories. The monitoring is to protect us — and you, as authorised users — from being on the wrong side of an unrelated security incident. We don't read your screens; we audit anomalous data movement. The system catches a 4 AM bulk-download from a stolen laptop the same way it catches anything else."

For the full communication playbook, see our discussion guide.

FAQ

What about engineers who genuinely need to clone customer repos for legitimate work?

Repo access is allowed; monitoring is about detection of anomaly versus baseline, not blanket prevention. An engineer who routinely clones Customer A's repos doesn't generate alerts. The same engineer suddenly cloning Customer B and C and D unrelated to their projects in a single week does.

How do we handle BYOD developer machines?

The clean policy: no source code on personal devices. Provide company laptops to anyone with code access. Where BYOD is unavoidable, restrict code access to VDI sessions monitored at the VDI layer.

What about open-source contributions by engineers in personal time?

Permitted but needs documented IP carve-out. Many engineers contribute to OSS projects; the company policy should distinguish OSS contributions (personal time, personal account, personal credit) from work output (company time, company account, work-for-hire).

Does this work for remote / WFH engineers?

Yes — endpoint monitoring runs identically on WFH machines. The control surface doesn't change; the connectivity does. See our remote-productivity guide for the broader frame.

How does Headx help with this specifically?

Headx captures repo activity, USB events, cloud-upload patterns, and ties them to UEBA scoring per user. Tagging users as "notice period" automatically lifts their UEBA weights. See the integrations page for Git provider hooks.