Roshana Ghemoshu
software engineer
Roshana Ghemoshu has a keen interest in the evolving world of technology and its impact on everyday business. She enjoys exploring new trends, innovative ideas, and the ways digital advancements are shaping how businesses operate and connect with people.
Giving an outside team access to your code and data is a risk, but one you can manage. The key is to ask specific questions, get the answers in writing and check them. Use this checklist with any vendor.
1. Confidentiality and legal basics
- Sign an NDA before any code, data or documents are shared.
- Make sure the contract says who owns the code, designs and documentation. Normally, that is you.
- Confirm that everyone on the project, including contractors, is bound by confidentiality terms.
- Ask about subcontractors: who they are, and whether you must approve them first.
2. Access control
- Every person has their own account. No shared logins.
- People can see only what the project needs (this is called "least privilege").
- Multi-factor authentication (MFA) is on for code, cloud and email accounts.
- Access is removed quickly when someone leaves the project.
- Your code repositories and cloud accounts stay in your name, and the vendor is added as a user.
3. Code ownership and handover
- Source code, documents and credentials are delivered to you regularly, not only at the end.
- Third-party and open-source licences are listed.
- Build and deploy steps are written down, so another team could take over.
4. Data location and handling
- Where is your data stored and processed, and in which countries?
- Does the vendor really need real customer data? Use test data wherever possible.
- Is data encrypted when it moves and when it is stored?
- How is data deleted when the project ends, and will the vendor confirm it in writing?
5. Data protection law
This applies if you handle personal data of people in the EU or UK.
- You are usually the controller and the vendor is a processor. A written data processing agreement should set out what the vendor may do with the data.
- Sending personal data outside the EU or UK needs a legal basis, such as standard contractual clauses. Check the details with a legal adviser.
6. Secure development
- Code is reviewed before changes are merged.
- Libraries and dependencies are checked for known vulnerabilities.
- Development, testing and live systems are kept separate.
- Passwords and keys are never stored in the code.
7. Incident response
- There is a clear way to report a suspected incident, and a named contact.
- The contract sets a time limit for the vendor to notify you.
- You receive a written report after any incident.
Red flags
| Red flag | Why it matters |
|---|---|
| Refuses to sign an NDA | They do not take confidentiality seriously |
| Shared accounts | You cannot tell who did what |
| Unclear data location | You cannot know which laws apply |
| No incident process | Problems will be found late, or hidden |
| Claims you cannot verify | Ask for evidence, or treat them as untrue |
How Quark Infotech can help
We work with signed NDAs, role-based access, MFA on all systems, separate staging and production environments, and regular code reviews. You own your code and your data. We can plan a project that keeps your sensitive information safe from the first day.
Need a secure development partner? Book a free 30-minute call to go through our security practices.
FAQs
Do we need to share real customer data with the vendor?
Usually not. Test or anonymised data is safer and works for most development.
Who should own the accounts and repositories?
You should. Keep them in your name and add the vendor as a user, so you can remove access at any time.
How do we check a vendor's security claims?
Ask for the answers in writing, ask to see how a practice works (for example, a code review or access list), and put the key promises in the contract.
Enjoying this read? Help others find it too.
