Data leaks through contractors: how it happens and what to do
A breakdown of the mechanics of data leaks through external contractors, and practical access control measures.
One of the most common data leak scenarios I encounter in incident reviews is not an external attack and not a malicious employee. It is a contractor or outsourcing firm that had access to systems that nobody revoked, restricted, or monitored properly.
The paradox is that companies pay a lot of attention to access control for permanent staff - and considerably less for people who work outside but have a direct way into the systems.
The typical mechanics of an incident
A contractor is brought in for a specific task - system implementation, module development, support. They are given access: to databases, internal tools, email or messengers. The task is done. The contract ends. Nobody revokes the access.
Six months later the same contractor is working for a competitor. Or the credentials leaked in a breach at the contractor's own company - and now someone outside has a working login to your system.
Even without malicious intent: a contractor employee leaves that company, their corporate laptop is sold or passed on - and your data or access tokens are saved on it.
Why this is a systemic problem, not a one-off failure
Most companies do not maintain a current register of who has access to which systems. When I ask for that list in an audit, it usually does not exist, or it is a year and a half out of date.
The reason is simple: creating access is a task with a specific owner and a deadline. Revoking access is a task with no owner and no deadline. Nobody puts it in the tracker. Nobody checks on it.
As a result, any company with more than 3-4 years of history has accounts that should have stopped existing long ago. Former employees. Finished projects. Departed contractors.
What to do in practice
This does not require complex technical solutions as a first step. It requires organisational discipline:
- Contractor access register. A separate list: who, which systems, from which date to which date. Updated on every change.
- Automatic expiry. Access for contractors is created with an end date - tied to the contract date. Extension requires explicit confirmation.
- Least privilege. The contractor gets access only to what is needed for the specific task. Not the entire production database, but a specific schema. Not all employee mailboxes, but the relevant folder.
- Offboarding procedure. Ending a contract must include the step "revoke all access". This should be an item on a checklist, not in someone's memory.
- Periodic audit. Once a quarter - go through all external accounts and compare against the current contract register.
Questions for a self-check
If you want to understand where you stand right now:
- Can you right now name every external contractor who has access to your systems?
- Are any of them contractors whose contracts have already ended?
- What happens if one of your active contractors is breached today?
The answers to those three questions give a clear picture of the actual risk level. And where to start.