Hire Software Developers 7
Back to blogs

Vendor Security Questionnaire: What to Ask a Dev Shop

A large badge casting a shadow across only a small part of a wide field of blocks, representing how narrowly a security certification's scope actually reaches

Vendor Security Questionnaire: What to Ask a Dev Shop

48% of breaches involve a third party. Your board has seen that slide. The number is real and it comes from the Verizon DBIR, but it doesn't mean what the room heard: the metric bundles three different situations together, and one of them is simply that you ran a vendor's vulnerable software.

The same gap opens when a vendor emails you its SOC 2 twelve minutes after you ask. Fast, professional, and silent on the only thing that matters: what the report covers. Nobody on the thread is going to raise it.

Closing that gap is what most vendor security questionnaires never do. Here's the move that beats a 300-row spreadsheet: for every credential a vendor offers, ask what it covers, who chose that coverage, and over what window.

A vendor security questionnaire is a structured set of questions a buyer sends a prospective supplier to establish what security controls that supplier operates, what its credentials actually cover, and what it will commit to in the contract.

Key takeaways

  • The 2026 Verizon DBIR's 48% is the share of breaches with third-party involvement, and that metric "combines three different kinds of business relationship archetypes" [V1][V3]. Only one of them looks anything like handing a dev shop a repository [V5].
  • A second, unrelated 48% sits in the same report: ransomware "grew again to 48% of all breaches, up from 44% from the previous year" [V9]. Say which one you mean.
  • SOC 2 is an attestation report, not a certification. The vendor picks the scope, the categories and the type, and a type 1 "does not contain an opinion on the operating effectiveness of controls" [S1][S2][S5][S3].
  • ISO/IEC 27001 certification is optional, and ISO wants the full reference: "certified to ISO/IEC 27001:2022" [K2][K3]. Check the scope and awarding body in the accreditation body's own database where one is published — UKAS's, for one — not in the PDF you were sent [K6][K7].
  • No measured research shows that security questionnaires reduce breach incidence [F6]. Use them for what they do instead: discovery, risk allocation, contractual leverage.

What the 48% third-party number actually counts

The 2026 DBIR says that "breaches with third-party involvement have increased by 60% from last year's dataset, reaching 48% of total breaches" [V1], drawn from more than 31,000 incidents, over 22,000 of them confirmed breaches [V2]. Real finding, real dataset. It's also a construct, and the DBIR says so: the metric "combines three different kinds of business relationship archetypes," concerned with where initial access happened and where the breached data was stored [V3].

One archetype is a vendor in your software supply chain, where the data and the vector were both yours and the vector existed only because a vendor's product was vulnerable [V4]. Another is a vendor hosting your data. The third is a vendor with a connection into your environment, used for lateral movement [V5]. Only that last one resembles handing a dev shop a repository.

The 2025 edition was blunt about that seam: "Not every definition of third-party involvement in breaches would consider the usage of vulnerable software a third-party matter" [V6]. Exploitation of vulnerabilities is now the most common initial access vector, at 31% [V8]. Credential abuse sits below it, at 13% [V8]. A large slice of that 48% is "somebody's shipped software had a CVE and you were running it."

Two cautions. First, name which 48% you mean, because the same report carries two of them: ransomware "grew again to 48% of all breaches, up from 44% from the previous year" [V9]. Second, the trend line is young. The 2025 edition found "third-party involvement of some sort in 30% of all breaches we analyzed, up from roughly 15% last year" [V7]. Three editions, not a decade. And if you quote the window, use the DBIR's own phrasing: its 2026 executive summary says "this report's dataset covers Oct 2024 through Nov 2025" [V14].

The genuinely useful third-party findings are duller. Only 23% of third-party organisations fully remediated missing or improperly secured MFA on their cloud accounts [V10]. Not a questionnaire answer. That's how a vendor behaves after signature.

SOC 2 vs ISO 27001: what does each one actually attest?

Neither one attests that a vendor is secure. SOC 2 is an attestation report on controls the vendor itself chose to scope — not a certification [S1][S2]. ISO/IEC 27001 is a certification, and holding one is optional [K2]. Where a vendor is certified, what you want back is the version, the scope and the awarding body [K3][K6].

Start with the vocabulary; it's load-bearing. The Trust Services Criteria are established by the AICPA's Assurance Services Executive Committee "for use in attestation or consulting engagements" [S1], and the AICPA's own publication is titled SOC 2 Reporting on an Examination of Controls at a Service Organization [S12]. Attestation. Examination. Report. No certificate, no expiry sticker.

It's narrower than the phrase suggests in three ways, each of them the vendor's choice.

Scope. The criteria may be applied across an entire entity, at a subsidiary, division or operating unit level, within one function, or for one type of information [S2]. All of those produce a report that says SOC 2 on the front.

Coverage. The practitioner "may report on any of the trust services categories of security, availability, processing integrity, confidentiality, or privacy, either individually or in combination" [S5]. Security-only is a legitimate scope, and silent on confidentiality and privacy. Even Security is scoped to systems "protected against unauthorized access, unauthorized disclosure of information, and damage to systems" [S6] — not "we are secure."

Window. A type 2 covers design and operating effectiveness "throughout a specified period"; a type 1 "does not contain an opinion on the operating effectiveness of controls" [S3] and omits the tests of controls and their results entirely [S4]. A type 1 tells you the controls existed on a date.

The opinion is conditional on its face. In the AICPA's illustrative SOC 2 type 2 report, controls "operated effectively" to provide "reasonable assurance" the applicable criteria were met [S7]. The same report concedes in its Inherent Limitations paragraph that "controls at a service organization may not always operate effectively to meet the applicable trust services criteria" [S8], and restricts itself: "This report is not intended to be and should not be used by anyone other than these specified parties" [S10].

ISO/IEC 27001 does the same job with different nouns. Certification is optional: "companies implementing ISO/IEC 27001 can decide whether they want to go through a certification process" [K2]. ISO is also specific about how to quote it: standards "should always be referred to with their full reference, for example 'certified to ISO/IEC 27001:2022' (not just 'certified to ISO 27001')" [K3]. A certificate from an accredited body "may bring an additional layer of confidence" [K4]. Verify it yourself: UKAS's database publishes "Details of the organisation, scope and the awarding Certification Body" [K6], built partly to make it "easier to identify (and therefore prevent) fraudulent certificates" [K7].

None of which makes certifications worthless. An independently examined artefact beats a vendor's word. It's just scoped, and reading the scope is your job.

The one question that replaces the spreadsheet

One question, three clauses: what does it cover, who chose that coverage, and over what window?

It works on a SOC 2 because the AICPA hands you the answer sheet: the scope levels [S2], the five categories [S5], the two types [S3]. Three answers tell you whether the report covers the part of the business that will hold your code. It works on ISO because the version, the scope statement and the awarding body are all published [K3][K6]. Verify in the accreditation body's database where one is published, not in the PDF you were sent [K7].

The NCSC's supplier assurance list asks whether the supplier holds certifications "such as Cyber Essentials, Cyber Essentials Plus or ISO27001" [Q2], then asks the only follow-up that matters: "If so, does the scope of the certifications cover the parts of the service you will be using and how you will be using it?" [Q3]. No survey quantifies how often scope turns out narrower than buyers assumed [F8]. So ask per vendor.

Where your data goes, and who else touches it

Settle one question before you send a DPA: does this vendor process personal data on your behalf? Where it doesn't, GDPR Article 28 isn't engaged, and your instruments are the NDA, the IP assignment and access control [F12]. Test that premise rather than assuming it, because a repository carries commit author names and email addresses, and fixtures and config files are not always synthetic.

Where it is engaged, Article 28 — in the text as retained in UK law — says a controller "shall use only processors providing sufficient guarantees to implement appropriate technical and organisational measures" [G1], and mandates a written contract with eight terms, from documented instructions and Article 32 security through to deletion or return and audits [G2][G3].

The EDPB's guidance is where the useful buyer moves live: a processing agreement "should not merely restate the provisions of the GDPR" but give concrete detail on how the requirements will be met [G4]. So a DPA that reads like a photocopy of the regulation is a finding, not a deliverable. The Article 28(1) obligation "is a continuous obligation," verified at intervals including through audits [G7]. And audit-fee clauses that are "clearly disproportionate or excessive" make that audit right "purely theoretical" [G11]. If a vendor's DPA prices your audit out of existence, that clause is your questionnaire answer.

The EDPB does list "recognised international certifications, like ISO 27000 series" among documents that help here [G5]. Then it calls the assessment "a form of risk assessment" made case by case, and declines to publish an exhaustive list [G6]. Certification helps; it doesn't discharge the assessment.

Then geography. Transfers to an adequate country flow "without any further safeguard being necessary" [G15]. As at 20 August 2026 the list runs Andorra, Argentina, Brazil, Canada (commercial organisations), the Faroe Islands, Guernsey, Israel, the Isle of Man, Japan, Jersey [G16], New Zealand, the Republic of Korea, Switzerland, the United Kingdom, the United States (commercial organisations in the EU-US Data Privacy Framework), Uruguay and the European Patent Organisation [G17]. Check it on the day: Brazil is a recent addition and the UK's two 2021 decisions were renewed in December 2025 [G18]. Without adequacy, the 2021 SCCs remain the current clauses, with an additional set for importers directly subject to the GDPR still in development [G12][G14]. A DPA citing the pre-2021 clauses is stale paperwork [G13].

The question almost nobody asks a dev vendor: will live customer data ever sit somewhere your production controls don't reach? PCI DSS is the clearest precedent, and deliberately narrow. v4.0 rescoped the test-data requirement from "testing or development" to "pre-production" at 6.5.5 [P1] and clarified that "live PANs are not used in pre-production environments except where all applicable PCI DSS requirements are in place" [P2]. That rule is about live card numbers, not all personal data, so borrow its shape and not its authority. The ICO's AI guidance makes the same move for training data: de-identify it before it is extracted from its source [I2]. NIST's SSDF supplies the environment half: controls "to separate the environments from each other and from production environments" [N2], plus minimal human access to build systems [N4].

Three software vendor due diligence questions that aren't about security

Who owns the code. In the US, when a work is made for hire, "the party that hired the individual is considered both the author and the copyright owner" [C1]. A commissioned work qualifies only if it fits one of the statute's listed categories, there's a written agreement, the parties expressly agree it's a work made for hire, and all parties sign [C3]. Circular 30 is absolute about the consequence of missing one: "if a work fails to satisfy any of these requirements, it is not a work made for hire" [C4]. And the statute lists exactly nine eligible categories, none of which is computer software [C2].

All of that is US law. Elsewhere, the durable move is the question rather than the doctrine: does the contract contain a present assignment of all IP in the deliverables, signed by every individual who writes code? That last clause carries the weight, because the employee-versus-contractor line turns on agency factors [C5] — and a subcontractor three layers down may not be covered by what your vendor signed.

Who else touches it. Sub-processor authorisation is a term you can enforce [G9]. The NCSC gives you the operational version: which offshore locations, what controls apply there, and whether you'll be told if locations or offshore subcontractors change [Q9]. One more from the same list: is the supplier required to build a right to audit into its own subcontracts, where those affect your service [Q11]?

What happens on the way out. Article 28 already requires deletion or return of personal data [G3]. The NCSC's is broader: what the contract provides for secure deletion or return of your data and assets at exit, including transfer to another supplier [Q10]. Ask while you still have leverage.

The best vendor security questionnaire is already written, and free

Two documents cover most of what a mid-market buyer needs, and neither costs anything. The UK NCSC publishes a list of supplier assurance questions grouped into governance, incidents, network, data, offshoring, personal data, personnel, physical, testing and contract sections [Q1]. Will the supplier "connect, or have access to, your data, IT network or premises," and "how will this be limited, controlled, and monitored?" [Q5]. Do their users have "the minimum level of access to data and networks required to do their job and no more" [Q4]? Do you log their remote access sessions "to reflect the work done" [Q6], and do they penetration-test independently and remediate what turns up [Q8]? Then the one most buyers skip: how will you monitor changes in their risk profile over time [Q12], which is the continuous-obligation point again [G7].

The second is CISA's Secure Software Development Attestation Form, released in March 2024 for producers of software used by the US federal government [N10]. Four items, signed by a CEO or a designee who must be an employee with authority to bind the corporation [N11]: software developed and built in secure environments, with environment separation, logging of trust relationships, and MFA plus conditional access [N12]; a good-faith effort to maintain trusted source code supply chains using automated tools [N13]; provenance maintained "to the greatest extent feasible" [N14]; and automated vulnerability checking before releases and on an ongoing basis, plus a disclosure program with timely handling [N15]. A producer may instead submit an assessment by a FedRAMP-certified 3PAO [N16], and must notify the agency if it stops using those practices [N17].

That page carries an archive banner, so check its current federal standing before you treat it as a live mandate. As a borrowable minimum bar it holds up anyway, because it is short, it has a named signatory who can bind the company, and it matches SSDF's call for a disclosure policy [N8] researchers can actually find [N9]. Most bespoke questionnaires manage none of those three.

Now the uncomfortable part. No measured research shows that security questionnaires reduce breach incidence [F6]. That absence is itself a finding. The nearest peer-reviewed work is about internal cybersecurity audit, not SOC 2 and not buyer questionnaires: Slapničar and colleagues built a cybersecurity audit index and found it correlated with cyber-risk-management maturity but "is not related to the probability of a successful cyber attack" [O1]. Set that beside the AICPA's own Inherent Limitations paragraph [S8], though, and the picture holds: these artefacts document a control environment. They don't operate it. The questionnaire-fatigue figures everyone quotes trace back to vendor marketing pages with no named survey, sample or date [F7].

Use questionnaires for what they demonstrably do: discovery, risk allocation, contractual leverage. Not prevention.

The 15-question checklist to send any development vendor

Fifteen questions, each with the reason it earns a slot. This is the whole vendor security questionnaire. Lift it, and pair it with the code audit checklist when you need to judge the code itself.

  1. What does your SOC 2 cover — which entity, which systems, which categories? Scope runs from entity-wide down to a single data type; coverage can be any subset of the five categories [S2][S5][Q3].
  2. Is it a type 1 or a type 2, and what were the exact dates? A type 1 carries no operating-effectiveness opinion and no test results [S3][S4].
  3. Who's named in the restricted-use paragraph, and can we read the report under NDA? The detail is in the tests, not the cover page [S10].
  4. Which version of ISO/IEC 27001, which body, and is it accredited? Accreditation adds a layer of confidence, and UKAS, for one, publishes the scope [K3][K4][K6].
  5. Will you process personal data on our behalf? If no, the instruments are an NDA and an IP assignment; if yes, eight contract terms become mandatory [F12][G3].
  6. Does anyone need production access, on whose account, and is it the minimum? Least privilege caps the blast radius [Q4][Q5].
  7. Do we log your remote access sessions, with logs reflecting the work done? Unlogged vendor access is the DBIR archetype that resembles your situation [Q6][V5].
  8. Will live customer data ever appear in a non-production environment? PCI DSS says no for live card numbers without full controls; the ICO's AI guidance says de-identify training data before extraction [P2][I2].
  9. How are development and production separated, and who reaches the build systems? Segmentation and minimal toolchain access are the named practices [N2][N4].
  10. Which sub-processors, in which countries, and will you get our written authorisation before that changes? Prior authorisation is enforceable; the change notice is not automatic [G9][Q9].
  11. If data leaves the EEA, under which mechanism — adequacy or the 2021 SCCs? The adequacy list moves, and pre-2021 clauses are stale [G15][G12][G13].
  12. Have you had a material security breach or compromise you need to declare? This is the NCSC's wording, and asking it in writing puts the answer on the record before you sign [Q7].
  13. Do you penetration-test independently, remediate findings, and run a disclosure programme? Remediation is where third parties stall: at third-party organisations, resolving 50% of weak-password and permission-misconfiguration findings took almost eight months [Q8][N8][N9][V11].
  14. Does the contract assign all IP in the deliverables, signed by everyone who writes code? In the US, work made for hire fails entirely if one condition is missed [C1][C4].
  15. At exit, what happens to our data, our code, and your access? Deletion or return is a required DPA term, and it is negotiable only before signing [G3][Q10].

Read that back and notice what it's mostly about: scope, access and contract, not badges. That's deliberate, because most of those questions have a structural answer as well as a procedural one.

That's how You-Source is set up. Engineers work inside your environment, under your access controls. Code and data don't leave your environment without your explicit approval. NDA before access. 100% you own the code. Which means questions 6 through 9 and 14 — the whole access block, plus who owns the code — get answered by how the engagement is built rather than by a certificate [T17]. None of that excuses you from reading a scope paragraph. It means fewer of your answers depend on one.

The certificate was never the point. The scope paragraph is.

Frequently asked questions

What is the difference between SOC 2 and ISO/IEC 27001?

SOC 2 is an attestation report — an examination of controls the vendor itself chose to scope, against criteria the AICPA's Assurance Services Executive Committee established "for use in attestation or consulting engagements" [S1][S2][S12]. ISO/IEC 27001 is a certification, and obtaining one is optional [K2]. Where a vendor is certified, ISO asks for the full reference — "certified to ISO/IEC 27001:2022" — and UKAS, for one, publishes the scope and awarding body so you can verify them yourself [K3][K6]. There is no such thing as a SOC 2 certificate.

What is the difference between a SOC 2 type 1 and a type 2?

A type 2 covers design and operating effectiveness "throughout a specified period" [S3]. A type 1 "does not contain an opinion on the operating effectiveness of controls" [S3] and omits the tests of controls and their results entirely [S4]. A type 1 tells you the controls existed on a date; ask for the exact dates either way.

Do I need a DPA with a development vendor?

Only where the vendor processes personal data on your behalf. Where it doesn't, GDPR Article 28 isn't engaged, and your instruments are the NDA, the IP assignment and access control [F12] — though "code only" is a premise worth testing, since repositories carry commit author names and email addresses. Where it is engaged, Article 28 — in the text as retained in UK law — mandates a written contract with eight terms, from documented instructions and Article 32 security through to deletion or return and audits [G2][G3].

Is there a free vendor security questionnaire I can use?

Two, and neither costs anything. The UK NCSC publishes a list of supplier assurance questions grouped into governance, incidents, network, data, offshoring, personal data, personnel, physical, testing and contract sections [Q1]. CISA's Secure Software Development Attestation Form sets four items signed by a CEO or a designee who must be an employee with authority to bind the corporation [N10][N11] — that page carries an archive banner, so treat it as a borrowable minimum bar rather than a live federal mandate.

Do security questionnaires actually prevent breaches?

No measured research shows that security questionnaires reduce breach incidence [F6]. The nearest peer-reviewed work is about internal cybersecurity audit: Slapničar and colleagues built a cybersecurity audit index and found it correlated with cyber-risk-management maturity but "is not related to the probability of a successful cyber attack" [O1]. These artefacts document a control environment; they don't operate it.

Sources

Dev Team as a Service
back to top

Related Articles

Table with coffee, table, phone, bag and people

The API and Integration Backlog Nobody Staffs

Your integration backlog looks delegable because a published API is a clean seam. Published isn't stable. Build the contract before you hand it over.

Table with coffee, table, phone, bag and people

Vendor Security Questionnaire: What to Ask a Dev Shop

A vendor security questionnaire that works: what the SOC 2 covers, who chose that scope, over what window - plus 15 questions you can lift whole.

Table with coffee, table, phone, bag and people

Code Audit Checklist: What a Senior Reviewer Actually Checks

A code audit checklist for inherited code, in comprehension order: map, dependencies, security, then the green lights that prove less than you think.

Book 30 min with Albert
Smiling man with short dark hair and glasses wearing a black suit, white shirt, and black tie against blue background.
Tell Albert what you're shipping.
He'll read this before joining the call. Phone number comes next, on the calendar step.
↳ info@you-source.com
↳ 4-hour response
Please wait while we retrieve meeting schedules.
Oops! There's a problem with your request. We're working on fixing it. Please try again later.