Before signing with a software vendor, ask about eight areas: access control, data handling, secure development practice, infrastructure, incident response, subcontractors, compliance evidence such as SOC 2 or ISO 27001 reports, and GDPR with a data processing agreement. A good answer is specific, names a practice the vendor can show you, and admits what it does not have. Deal-breakers are shared credentials, production data on developer laptops, no incident process, and undisclosed subcontractors.
Most vendor security questionnaires are two hundred rows long, filled in by a salesperson in an afternoon, and read by nobody. They satisfy a procurement step and reduce no risk. The alternative is a short set of questions, asked in conversation, with evidence requested for the ones that matter. This post is for the CIO, CISO, procurement lead or program manager evaluating a software development partner. It gives the questions by area, what a strong answer sounds like, and which answers should end the conversation.
Why does this matter more for a development vendor?
A SaaS vendor holds your data in their system. A development vendor builds the system, which means they touch your source code, your environments, your integrations and often your production data, for months. Their engineers will have credentials to your cloud accounts and your identity provider. Their laptops will hold copies of your repository. A weakness in their practice becomes a weakness in your product, and it is there before you go live. The questions below are about how they work, not only where they host.
The questions, by area
| Area | Ask | A good answer sounds like |
|---|---|---|
| Access control | How are your people given access to our systems, and how is it removed? Is multi-factor authentication enforced? Are credentials ever shared? | Named accounts per person, MFA on everything, access granted per project through your identity provider where possible, removed on the day someone leaves, reviewed quarterly. Never shared logins. |
| Data handling | Will your team access our production data? Where will it be stored and processed? How do you handle data in non-production environments? | Production access limited to named people with a reason, logged. Development and test use anonymized or synthetic data. No production data on laptops. Data stays in the region you specify. |
| Secure development | How do you prevent and catch vulnerabilities in code? Do you review every change? How are dependencies and secrets managed? | Mandatory peer review, automated dependency and static analysis in the pipeline, secrets in a vault rather than in code or chat, a defined process for fixing a finding, and a willingness to show the pipeline. |
| Infrastructure | Who owns the cloud accounts? How are environments separated? How are backups done and tested? | Accounts in your name, separate production and non-production, infrastructure defined as code, backups automated and restore-tested on a schedule they can name. |
| Incident response | What happens if one of your laptops is lost or an engineer's account is compromised? When would you tell us, and how? | Encrypted and remotely wipeable devices, a written incident process, notification to you within a stated number of hours, a named contact, and an example of a past incident handled. |
| Subcontractors | Will anyone outside your company work on our project? Where? Under what agreement? | A clear yes or no, names and locations if yes, the same obligations flowed down in writing, and your right to approve or refuse. |
| Compliance evidence | Which frameworks do you follow and what can you show us? SOC 2 report, ISO 27001 certificate, penetration test results, policies? | Whatever they have, shown under NDA, plus honesty about what they do not have. A small firm with no certificate but strong, demonstrable practice is often safer than a certified one whose practice is a binder. |
| GDPR and data protection | Will you sign our data processing agreement? Where are your people and your infrastructure? What is your lawful basis for any transfer? | Yes to the DPA, with sensible exceptions. Locations stated. For EU data, processing inside the EU or UK, or standard contractual clauses with a transfer assessment. |
What does a good answer sound like?
Specific, demonstrable and slightly uncomfortable. A vendor with real practice will describe exactly how a new engineer gets access on day one and loses it on their last day, will offer to show you the pipeline that blocks a vulnerable dependency, and will tell you which of your questions they cannot answer well yet. The tell of a weak answer is that it is about policy rather than practice. "We have a security policy" is not an answer. "Every change is reviewed by a second engineer and the pipeline fails on a high-severity dependency finding, here is last week's run" is.
Ask for evidence on the three or four areas that matter most for your situation. For a customer-facing product that is usually secure development and infrastructure. For an internal system holding employee or patient data it is access control and data handling. For a regulated sector it is compliance evidence and incident response. Building software for regulated industries explains how the requirements change when a regulator is involved.
Which answers are deal-breakers?
- Shared credentials of any kind, for any system. It means no accountability and no clean removal when someone leaves.
- Production data on developer machines, or an inability to say where production data goes during development.
- No incident process, or a vague "we would let you know". If they have never thought about losing a laptop, they will not handle it well.
- Undisclosed subcontractors. If you learn about a third party from a commit author name, the relationship has a trust problem that will not stay confined to security.
- Cloud accounts in the vendor's name with no plan to transfer. This is an ownership problem and a security problem at once. Who owns the code covers what should be in your name from the first day.
- Refusal to sign a data processing agreement for a project that will touch personal data.
- A perfect questionnaire. Two hundred rows of "yes" with no caveats is a sign nobody who does the work read it.
How should the answers go into the contract?
A good answer in a meeting is worth little a year later. The obligations that matter belong in the master agreement or the statement of work: named access and removal within a set time, data residency, no production data outside agreed environments, notification of incidents within a stated period, subcontractor approval, the DPA as a schedule, and a right to audit or to receive the vendor's own audit reports. MSA, SOW and change requests explains where each belongs. If your RFP is still being written, put the questions above into it as a short required section rather than a generic matrix. How to write an RFP for custom software development shows the format.
What about certifications?
SOC 2 and ISO 27001 are useful evidence that a vendor has a management system and has had it checked. They are not evidence that the engineer on your project writes secure code. Treat a certificate as a reason to shorten your questions, not to skip them. And treat the absence of one as a reason to ask for more demonstration, not as a disqualification. Many strong engineering firms, particularly smaller nearshore ones, run excellent practice without a certificate because their clients ask for evidence directly. The location question has its own data protection angle, which nearshore vs offshore vs onshore covers.
The eight questions that reduce the most risk
- How does an engineer get access to our systems, and how is it removed?
- Where does our production data go during development?
- Show us the pipeline that catches a vulnerable change.
- Whose name is on the cloud accounts?
- When were backups last restored, and did it work?
- What happens when a laptop is lost, and when do we hear about it?
- Who outside your company will touch our project?
- Will you sign our data processing agreement?
How 7L answers these questions
7L International is a custom software development and digital transformation firm with business hubs in New York, London and Athens, and our engineering team works from inside the EU. We have supported more than one hundred organizations, including in healthcare and finance where these questions are not optional, and we would rather be asked every one of them than be chosen on a questionnaire. Our practice is named access through your identity provider, your accounts in your name, anonymized data outside production, reviewed and scanned changes, and a written incident process with a named contact. We show the evidence rather than describe it. If you are evaluating partners for an enterprise software program and want to run these questions on us, get in touch.
Frequently asked questions
Do we need a vendor to have SOC 2 or ISO 27001?
Not necessarily. A certificate shows the vendor has a security management system that an auditor has checked, which is useful evidence and shortens your questions. It does not show that the engineers on your project follow secure practice. Ask for demonstration either way: the access process, the pipeline, the backup restore, the incident procedure. A smaller firm with strong demonstrable practice and no certificate is often a safer choice than a certified one that cannot show you how the work is actually done.
Should a development vendor have access to our production data?
Rarely, and only named people with a logged reason, for example to diagnose a live issue. Development and testing should run on anonymized or synthetic data in separate environments. Production data should never be on a developer's laptop. Put this in the contract rather than relying on the conversation.
What is a data processing agreement and does a development vendor need one?
A data processing agreement sets out how a vendor handles personal data on your behalf: purpose, locations, security measures, sub-processors, breach notification and deletion at the end. If the vendor's people will see any personal data of EU or UK residents, including during testing or support, you need one. Most enterprise buyers attach their own DPA as a schedule to the master agreement.
How long should a security questionnaire for a software vendor be?
Short enough that someone who does the work answers it. Twenty to thirty specific questions across access, data handling, secure development, infrastructure, incidents, subcontractors, compliance evidence and data protection, with evidence requested on the handful that matter most for your project. A two-hundred-row generic matrix gets filled in by sales and read by nobody.
What is the single biggest security red flag in a software vendor?
Shared credentials. If engineers log in to your cloud, your repository or your test systems with a common account, there is no accountability, no clean removal when someone leaves, and usually no MFA. It almost always indicates the rest of the practice is equally informal. Walk away or require it fixed before any access is granted.