This is a ready-to-use software-supplier qualification questionnaire built to ask for objective evidence, not just claims, so a salesperson cannot complete it in five minutes with no involvement from engineering or quality. It is distinct from a generic material or service supplier questionnaire: every question ties to a specific SDLC, traceability, or GxP-records capability a software vendor either can or cannot evidence. Replace every <<FILL: ...>> placeholder with your own specifics. A filled specimen follows. This questionnaire is educational reference, not legal or regulatory advice; confirm the current version of every referenced standard (ISO 9001, ISO 13485, Part 11 / Annex 11, SOC 2, ISO 27001) before relying on a vendor’s answer.
Instructions
Send this questionnaire to the supplier’s quality or engineering leadership, not only to sales or account management. Require attachments (certificates, redacted traceability samples, redacted test reports) wherever requested; a text answer with no attachment is a weaker response and should be scored accordingly. Score each section, then use the overall score alongside the risk tier from your supplier assessment procedure to decide whether a documentation review, remote audit, or on-site audit is also required.
Section A: Company and quality system
| # | Question | Evidence requested | Acceptable answer | Red flag |
|---|---|---|---|---|
| A1 | Do you operate a documented quality management system? | Current certificate (ISO 9001 / ISO 13485) and scope, if certified | Certified, or an uncertified but clearly documented QMS with named procedures | ”We don’t have formal certification but we’re careful” with no procedure names offered |
| A2 | Provide your top-level index of SDLC procedures | Procedure index with version and approval dates | Versioned, approved, dated procedures covering requirements through release | Undated draft list, or “we can walk you through it verbally” |
Section B: Software development and traceability
| # | Question | Evidence requested | Acceptable answer | Red flag |
|---|---|---|---|---|
| B1 | Describe your release lifecycle. How is a requirement traced to a test result? | Narrative plus the traceability sample requested in B2 | A named tool or method connecting requirement, design, code reference, and test | ”We know our product well enough not to need formal traceability” |
| B2 | Provide a redacted sample of a requirements-to-test traceability record for a recent release | Actual redacted extract | A real record showing the chain end to end | No sample provided, or a sample that does not actually connect requirement to test |
| B3 | How are defects classified, tracked, and closed? | Severity definitions and tool named | A closed-loop system with defined severities and closure evidence | Defects tracked in email or an informal spreadsheet with no closure record |
Section C: Testing and release
| # | Question | Evidence requested | Acceptable answer | Red flag |
|---|---|---|---|---|
| C1 | What testing is performed before a release (unit, integration, system, regression)? | Test strategy summary | Documented strategy covering at minimum system and regression testing, with recorded results | ”We test thoroughly” with no description of what kinds of testing or where results are kept |
| C2 | Provide a redacted test summary or validation summary for the version you intend to use | Actual redacted summary for the specific version in scope | A real summary tied to the exact version | A generic marketing “quality” document, or a summary for a different version than the one in scope |
Section D: Records, Part 11 / Annex 11
| # | Question | Evidence requested | Acceptable answer | Red flag |
|---|---|---|---|---|
| D1 | Describe audit trail, electronic signature, and access control capabilities for products holding electronic records | Feature description, and screenshots or documentation if available | Audit trail cannot be disabled by an ordinary user, e-signatures are attributable and linked to the record, access control is role-based | ”Audit trail can be turned off for performance” or no clear answer |
| D2 | Confirm whether time stamps are configurable and how the system clock is controlled | Description of clock source and configurability | Clock source stated, controlled, not freely user-editable | ”Users can set the system clock” with no control described |
Section E: Change, support, security
| # | Question | Evidence requested | Acceptable answer | Red flag |
|---|---|---|---|---|
| E1 | How are patches and changes communicated and released to customers? | Change-notification process description, including notice period for multi-tenant SaaS releases | A defined notice period, release notes with enough detail to assess GxP impact, and (for SaaS) a sandbox/staging window ahead of production | ”We’ll email you when something changes” with no committed notice period |
| E2 | Describe your security vulnerability disclosure and patching commitments | Policy or SLA reference | Defined process and target timelines by severity | No defined process, or “we handle it case by case” |
| E3 | For hosted/SaaS: provide your latest SOC 2 Type II or ISO 27001 report and describe backup and disaster recovery | Report attached; RPO/RTO stated | Current report (within the last 12 months) and stated recovery objectives | Report expired, unavailable, or backup/DR described only in general terms with no RPO/RTO |
Scoring and disposition
| Field | Entry |
|---|---|
| Section A score | <<FILL: e.g. X of 2 acceptable>> |
| Section B score | <<FILL: e.g. X of 3 acceptable>> |
| Section C score | <<FILL>> |
| Section D score | <<FILL>> |
| Section E score | <<FILL>> |
| Overall red flags identified | <<FILL: list>> |
| Reviewer recommendation | <<FILL: questionnaire sufficient / escalate to documentation review / escalate to remote or on-site audit>> |
| Reviewer (name, role, date) | <<FILL>> |
| QA concurrence (name, date) | <<FILL>> |
Filled specimen
Completed for an illustrative LIMS vendor, Category 4 configured product, high GxP and data-integrity impact.
| # | Question | Vendor answer summary | Score |
|---|---|---|---|
| A1 | QMS | ISO 9001:2015 certified, certificate attached, scope covers software development | Acceptable |
| B2 | Traceability sample | Redacted extract provided showing REQ-0412 traced through design DES-0198 to test case TC-1187, pass, release 8.4.2 | Acceptable |
| C2 | Test summary for version in scope | Validation summary provided for v8.4.2, the exact version being procured, showing 214 system tests, 6 minor defects closed | Acceptable |
| D1 | Audit trail/e-signature | Audit trail cannot be disabled by any user role; e-signatures meet the vendor’s stated Part 11 mapping document | Acceptable |
| E1 | Change notification | 30 business days notice for major releases, 5 for minor, sandbox tenant updated 10 business days before production | Acceptable |
| E3 | SOC 2 | Current SOC 2 Type II report dated within the last 9 months provided; RTO 4 hours, RPO 15 minutes stated | Acceptable |
Reviewer recommendation: “All sections score acceptable with objective evidence attached for every request. Given the high GxP and data-integrity impact of this system, escalate to a remote audit per the risk-tiered method table, using this questionnaire’s B2 and C2 evidence as the pre-read package rather than re-requesting it.”
Common inspection findings this form prevents
- A questionnaire completed entirely by sales, with no engineering or quality input and no attachments.
- Claims of traceability or testing accepted with no sample evidence ever requested or reviewed.
- A test summary reviewed for the wrong product version.
- SaaS change-notification answered vaguely, with no committed notice period later discovered to be zero when a release breaks a workflow.
- No documented reviewer recommendation connecting the questionnaire result to the next step (accept at this tier, or escalate).
How to adapt this form
- Route this to supplier quality or engineering leadership specifically; a sales contact routing it without visibility into SDLC evidence produces a weak response.
- Require the actual redacted attachments requested in B2, C2, and E3; a text-only answer to those questions should lower the score regardless of how confident it sounds.
- Tie the “escalate” decision explicitly to your risk-tiered method table so the questionnaire result and the next assessment step are linked in one traceable record.
- Re-issue Section E on any material change to the vendor’s SaaS release process, since notice commitments can change between assessments.