Most vendor security reviews ask whether a policy exists. A competent supplier can answer yes to every question on a standard questionnaire while working in a way you would not accept if you watched it for a day.
The questions below are harder to answer from a document, which is the point. They apply to any engineering supplier; they matter more when the team is distributed, because you cannot walk past anyone’s screen.
Where does the code actually live?
Not the policy — the practice. Is the repository in your organisation’s account or theirs? Do engineers clone to personal machines, and if so, is disk encryption enforced or merely recommended?
Ask what happens to a local clone when someone leaves the project. The honest answer for most suppliers is “nothing”, and that is worth knowing rather than assuming.
If they use a managed development environment where code never lands on a laptop, that is a genuinely strong answer and they will volunteer it.
Who has access, and how quickly is it removed?
Access accumulates. The questions that reveal how a team really operates:
- How many people currently have production access, by name?
- What is the interval between someone leaving and their access being revoked? Ask for the actual last instance, not the target.
- Is production access standing, or requested per task and time-limited?
- Is multi-factor authentication enforced on the identity provider, or optional?
“We review access quarterly” is a weaker answer than it sounds. A quarterly review means someone could retain access for up to three months after they should have lost it.
What touches production data?
The most common real-world exposure is not an attacker. It is a copy of production data sitting in a development environment because someone needed realistic test data.
Ask directly whether production data is ever copied to non-production environments, and if so, whether it is masked, who can do it, and where those copies are now. A supplier that has thought about this will describe a seeding or anonymisation process. One that has not will hesitate, which is itself informative.
How are secrets handled?
Ask where API keys and credentials live. Acceptable answers involve a secrets manager or the platform’s own mechanism. Unacceptable answers involve environment files shared over chat, which remains extremely common.
Follow up: what happens when a credential is accidentally committed? A team that has a rotation procedure has almost certainly needed one. A team that says it has never happened is either very small or not looking.
What is the incident process, specifically?
Not whether they have one. Who is contacted, within how long, and on what channel. Whether that channel works outside the overlap window. Who at your organisation they are supposed to reach, and whether that person’s details are recorded anywhere.
The gap that hurts is not detection — it is the two hours spent working out who to tell while nobody is authorised to act.
What about subcontractors?
Ask whether any part of the work is subcontracted, and if so, whether the subcontractor is bound by the same terms you just agreed. This applies to confidentiality and IP assignment as much as to security.
A vendor that subcontracts is not automatically a problem. A vendor that subcontracts without saying so is.
Match the depth to the data
A team building an internal reporting tool and one touching payment or health data warrant different scrutiny, and applying maximum process to both wastes effort where it is not needed.
Decide what the worst realistic outcome is for this specific engagement, then ask proportionately. The questions above are the floor for anything touching customer data.
Common questions
What should I ask an offshore development team about security?
Where code physically lives and whether laptops hold clones, how quickly access is revoked when someone leaves, whether production data ever reaches development environments, how secrets are stored, the specific incident contact path, and whether any work is subcontracted.
Is offshore development less secure?
Not inherently. The practices that matter — access control, secrets management, data handling, incident response — are independent of location. What distance changes is your ability to observe them informally, so the questions have to be more specific.
What is the most common real security gap?
Production data copied into a development environment for realistic testing, and then left there. It is far more common than an external attack and it is easy to ask about directly.
Is a signed security policy enough?
No. A policy document answers whether something is written down, not whether it is practised. Ask for the most recent actual instance — when access was last revoked, when a credential was last rotated — rather than the stated target.
We contract through our US entity with engineering in Islamabad, and we expect these questions. See custom software development or read who owns the code in offshore contracts.
