Choosing a QA vendor for regulated software

Your product sits under regulation: health data, financial services, public sector or another field where auditors, regulators or customers will ask how it was tested and who had access to what. A testing vendor becomes part of your control environment. You need evidence, not assurances, and you need test documentation that someone outside your team can follow.

What changes in criteria and weights

Test strategy and documentation, security posture and certifications, and test data handling rise to 5; subcontracting transparency, audit rights and the contracting entity and jurisdiction rise to 4. Capacity and speed to start drops to 2, because a vendor that starts fast without the right controls creates findings you will have to explain later.

Criteria whose weight differs from the default
Criterion	Default weight	Weight here
Test strategy and documentation	3	5
Security posture and certifications	3	5
Test data and personal data handling	3	5
Subcontracting transparency	3	4
Audit and information rights	3	4
Contracting entity and jurisdiction	3	4
Capacity and speed to start	3	2

Weights run from 0 (not scored) to 5. Every other criterion keeps its default weight of 3. The scoring template loads these weights when you choose this situation.

Which tools, in which order

RFP generator: Set the compliance context in the RFP so every vendor answers against the same obligations, data classes and documentation you need.

Vendor questionnaire: Filter by this situation to ask how the vendor scopes its certifications, creates test data and documents test results for audit.

Due-diligence checklist: Verify each certificate and report yourself: accreditation, scope, dates, exceptions and the entity that holds it.

Proposal red-flag checker: Catch proposals that ask for production data, offer a SOC 2 Type I as if it were Type II, or skip data processing terms.

Reference-call script: Ask references in regulated work whether the vendor's documentation held up in an audit or regulator review.

Scoring template: Score with the regulated weights so documentation and data controls count for more than speed or price.

Contract clauses: Put data processing, subprocessor approval, audit rights, incident notification and the ban on production data into the contract.

Typical mistakes

Accepting a certificate logo without checking that its scope covers the sites and teams that will do your work.

Letting testers use copies of production data because building synthetic data takes longer.

Signing the service agreement before the data processing terms, so they are negotiated after access is already granted.

Not asking who the subcontractors are, so an unknown party ends up with access to regulated data.

Receiving test evidence as screenshots in chat instead of documented results traceable to requirements.

Forgetting that the contract must give you, and in some sectors your regulator, the right to audit the vendor.

Map your obligations before you write the RFP

List the rules that apply to your product and what each one means for a testing supplier: whether the vendor will be a data processor, whether health information is involved, whether sector rules on outsourcing apply, and what your own customers require in their contracts with you. Put that list in the RFP so vendors answer against it rather than against a generic security page.

Verify, do not collect

Every certificate and report the vendor cites should be checked by you. For ISO/IEC 27001, confirm the certificate on the accreditation records and read the scope. For SOC 2, ask for the Type II report under a confidentiality agreement, check the period, and read the exceptions. Where neither exists, assess controls directly with a questionnaire and evidence.

Keep regulated data out of testing

Design the engagement so the vendor tests with synthetic or masked data in environments you control. Make any use of production data subject to written approval, and state that in the contract. This removes a large part of the regulatory exposure rather than trying to manage it.

Ask for documentation an auditor can follow

Ask for a test plan, test cases traceable to requirements, and test completion reports in a structure such as the one described in ISO/IEC/IEEE 29119-3. Agree where these records live, who can change them, and how long they are kept.

Questions buyers ask

Is an ISO/IEC 27001 certificate enough?

It is useful evidence, not a complete answer. Check it on the accreditation body's records, confirm the scope covers the delivery sites and services you are buying, and still ask how test data, access and incidents are handled for your engagement.

What is the difference between SOC 2 Type I and Type II?

A Type I report describes controls at a point in time. A Type II report tests whether those controls operated over a period. For an ongoing service, ask for Type II, read the exceptions, and check which complementary controls the report expects you to run.

Do we need a business associate agreement with a US testing vendor?

If the vendor will create, receive, keep or transmit protected health information on your behalf, US health privacy rules treat it as a business associate and a written agreement is required. The simpler path is to design testing so the vendor never sees that information.

Which EU rules affect the contract?

If the vendor processes personal data for you, GDPR Article 28 sets out what the processor contract must contain. EU financial entities also have specific contract requirements for ICT services under DORA Article 30, and banks follow the EBA outsourcing guidelines.