Vendor security questionnaire for a QA supplier

Why a testing vendor needs its own questionnaire

A testing vendor is rarely treated as a high-risk supplier, yet its people often get more access than most other third parties. Testers read source code, run builds in your CI pipeline, log into staging environments, create accounts in your cloud tools and handle test data that is sometimes copied from production. Automation engineers may hold tokens that can trigger deployments.

Generic supplier questionnaires ask about data centres and payroll systems. Those questions matter less here. What matters is how the vendor controls the people and devices that reach your systems, and what happens to the data they touch. ISO/IEC 27036 frames this as matching the security requirements to the specific supplier relationship, and NIST SP 800-161 makes the same point for supply chain risk: assess the supplier against the access and function it actually has.

Start from a standard set, then cut it down

You do not need to invent questions. The CSA Consensus Assessments Initiative Questionnaire (CAIQ) is public and maps to common control frameworks. Use it, or your own organisation's standard set, as the pool. Then remove what does not apply to a service that has no hosting role, and keep the domains that do.

Domain	Keep for a QA vendor?	Why
Identity and access management	Yes, in full	Testers get named accounts in your systems
Endpoint and device security	Yes	Code and data sit on tester laptops and test devices
Human resources security	Yes	Screening, confidentiality terms, offboarding
Data security and privacy	Yes	Test data, screenshots, logs, recordings
Supply chain management	Yes	Subcontractors, freelancers, cloud device services
Security incident management	Yes	Notification to you, with time and content
Application and interface security	Partly	Only if they build tooling that runs in your pipeline
Data centre and physical security	Mostly no	Unless they host your data or test devices

Mark each remaining question as either "evidence required" or "self-attested". Keep the evidence-required list short enough that you will actually review it.

Questions to add for testing work

Standard sets miss several risks that are specific to testing. Add these.

• Production data. "Will your testers ever need production data? If so, how do you mask, subset or synthesise it, and who approves any exception?"
• Credentials in test code. "Where do your automation scripts store credentials and tokens, and how do you keep them out of the repository?"
• Screenshots and recordings. "Do your tools capture screenshots, videos or logs that could contain personal data? Where are they stored and for how long?"
• Devices. "Which physical or cloud devices will run our app, who else uses those devices, and how are they wiped between clients?"
• AI and code tools. "Do you use any AI or code-generation tools on client work, and which of our data is sent to them?"
• Offboarding speed. "When a tester leaves our account, how quickly is their access to our systems removed, and who confirms it?"

Evidence you can sample

A questionnaire is only as good as the answers you check. Pick a handful of answers and ask for the record behind them. Useful samples:

• A redacted access review for another client, showing named accounts and the date access was last reviewed.
• An offboarding ticket showing the time between a leaver's last day and account removal.
• The device or endpoint policy, with the section on encryption and client data.
• The ISO/IEC 27001 certificate with its scope statement, or the SOC 2 report under NDA, with the audit period and the systems in scope.
• The list of subprocessors and subcontractors used on client work.

If the certificate or report covers a different legal entity, a different office, or a hosting product rather than the testing service, it does not answer your questions. See how to verify ISO 27001 and SOC 2 for the steps.

Personal data and contract terms

If testers will see personal data, the vendor is a processor and GDPR Article 28 requires a contract with specific terms: acting only on your documented instructions, confidentiality, security measures, subprocessor approval, assistance, deletion or return, and audits. The questionnaire should confirm the vendor will sign those terms, and your contract should contain them. Details on test data are in test data and GDPR.

Every gap the questionnaire finds has one of three outcomes: the vendor fixes it before signature, the contract adds an obligation with an audit right, or you record the risk and who accepted it. Do not leave gaps as comments in a spreadsheet nobody reads after signing.

How this fits the selection

Send the security questions with the rest of your vendor questions, not as a late surprise after you have chosen. The questionnaire generator includes a security section built from these sources, and the due diligence checklist covers certificate and entity checks. The selection path shows where the security review sits in the overall timeline, so it does not delay the contract.