The due diligence process for software suppliers in the public sector has a structural problem: the questions most commonly asked are the ones easiest to answer convincingly without meaning much. A supplier can confirm ISO 27001 certification, provide a polished capability statement, and list references — and still be genuinely difficult to hold to account when something goes wrong after go-live.

This guide is for procurement officers, project leads, and heads of digital in public sector organisations who are evaluating small or medium-sized software suppliers. It covers the questions that surface real accountability signals, what a credible answer looks like, and what responses should give you pause.

The Procurement Act 2023 explicitly requires contracting authorities to consider SME suppliers. That means evaluating them properly, not applying enterprise-scale requirements that smaller organisations cannot meet. Proportionality is the standard. The questions below are structured around that principle.

Legal and financial standing

This is the baseline. Before any substantive evaluation, a supplier should be able to confirm their legal existence and basic financial health. For an SME, this does not require the same financial scrutiny as a large enterprise — the Procurement Act's guidance on proportionality is explicit on this point.

Question
Can you confirm your Companies House registration number and when your last accounts were filed?
What a credible answer looks like

An immediate, specific answer: company number, registered address, confirmation that accounts are filed and current. This takes 30 seconds to verify at find-and-update.company-information.service.gov.uk. A supplier who cannot answer this immediately has a basic governance problem.

Red flag: vague answers about "being in the process of registering" or a company number that does not resolve on Companies House.

Question
What is your annual turnover and do you carry professional indemnity insurance?
What a credible answer looks like

Turnover consistent with a company of their stated size and project history, and confirmation of PI insurance with a policy limit proportionate to the contract value being discussed. For a contract worth £50k, requiring £10m PI insurance is disproportionate. For a contract worth £500k with significant data processing, it is not.

Red flag: PI insurance that was taken out specifically because the supplier knew this question was coming, with no history of cover.

Security posture

Cyber Essentials is the government's baseline security certification. It is mandatory for central government contracts involving personal information and is the minimum bar you should apply to public sector software procurement regardless of whether it is formally required in your context.

Question
Do you hold Cyber Essentials or Cyber Essentials Plus certification? Can you provide the certificate reference?
What a credible answer looks like

A certificate reference number that can be verified at the NCSC's Cyber Essentials certificate directory. Cyber Essentials covers five technical controls: boundary firewalls and internet gateways, secure configuration, access control, malware protection, and patch management. Cyber Essentials Plus includes a technical verification audit. Both are annual certifications. A supplier in the process of certification should be able to state when it will be complete.

Red flag: "We follow the principles of Cyber Essentials" is not certification. Do not accept it as an equivalent.

Question
Where is our data hosted, and who has access to it?
What a credible answer looks like

A specific answer: named cloud provider, region (UK, EEA, or other), and a clear statement of which people within the supplier's organisation have access to production data and under what conditions. For many public sector contracts, UK data residency is a hard requirement. A supplier should know this without being prompted.

Red flag: "Our infrastructure is secure and we take data privacy seriously" without specifics about location or access controls.

Data protection and GDPR

In most software contracts with a public sector body, the supplier acts as a data processor and the contracting authority acts as data controller. This relationship must be documented in a Data Processing Agreement (DPA) before any personal data is handled.

Question
Do you have a Data Processing Agreement template, and are you able to enter into one before contract signature?
What a credible answer looks like

Yes, with a template available for review. A DPA should set out the nature, purpose, duration, and subject matter of the processing; the type of personal data involved; the obligations of both parties; and the data subject rights process. A supplier who has worked with regulated organisations before will have a standard DPA they use routinely.

Red flag: "We are GDPR compliant" without the ability to produce a DPA. Compliance is not a document. The DPA is.

Question
Walk me through what happens if you discover a personal data breach affecting data you process on our behalf.
What a credible answer looks like

Under UK GDPR Article 33, a data controller must report a breach to the ICO within 72 hours of becoming aware of it. A data processor (the supplier) must notify the controller "without undue delay" — in practice, this means as quickly as possible, and certainly within a timeframe that allows the controller to meet their 72-hour obligation. A credible supplier will describe an internal detection and notification process, not just reference the legal requirement.

Red flag: "We would contact you straightaway" with no description of what detection, internal escalation, or documentation looks like.

Delivery credibility

This is the area where generic capability statements are least useful and direct questions are most useful. A supplier's track record on difficult deliveries tells you far more than a reference list of projects that went smoothly.

Question
Describe a delivery that encountered significant problems. What went wrong, what did you do, and what was the outcome?
What a credible answer looks like

A specific, named situation — not a hypothetical — where something genuinely went wrong. The answer should cover what the problem was, how it was identified, what the supplier communicated to the client during the problem, and what was done to resolve it. The resolution does not need to have been perfect. The communication and accountability during the difficulty is what matters.

Red flag: "We have always delivered on time and on budget." No software delivery at any meaningful scale has this history. It means the supplier either has no relevant experience or is not being honest.

Question
Who specifically would be working on this project, and what is your current capacity?
What a credible answer looks like

Named people, their roles, and an honest account of their current commitments. For SME suppliers, the difference between "we have this capacity" and "we have this capacity if we win no other work in the same period" is significant. A supplier with one active delivery and a second in the proposal stage has different capacity than one with three concurrent deliveries at varying stages. Ask directly.

Red flag: "Our team" without names, or assurances that they will "staff appropriately" without explaining from where.

Post-launch accountability

The question public sector buyers most frequently fail to ask before contract signature is the one they most urgently need answered six months after go-live: who do I call when something breaks, and what happens when I do?

Question
What is your support model after go-live? Specifically: who is the named contact, what are the response times for production issues, and what is the escalation path?
What a credible answer looks like

Named contact (not "the support team"), specific response commitments — for example, acknowledgement within two hours for a production issue affecting users, resolution within a defined window depending on severity — and a clear escalation path if the named contact is unavailable. This should be documentable in the contract. If a supplier resists committing these specifics to writing, that is the answer to the question.

Red flag: "We are always available" with no SLA, no named contact, and no escalation structure.

Question
What happens to our data and our access to the system if the contract ends or the supplier ceases trading?
What a credible answer looks like

A clear exit and data portability plan: how data is exported, in what format, within what timeframe, and at what cost. For custom software, whether the source code is held in escrow or whether ownership transfers to the client on contract end. These questions are uncomfortable to ask and essential to answer before, not after, the contract is signed.

Red flag: "We would work something out." This means no plan exists.

A practical due diligence checklist

The following is a minimum verification checklist for an SME software supplier at pre-contract stage. Each item should be evidenced, not asserted.

Item How to verify
Companies House registration find-and-update.company-information.service.gov.uk — confirm active status, registered address, filed accounts
Cyber Essentials certification Request certificate reference number and verify at the IASME Cyber Essentials certificate directory
Professional indemnity insurance Request current certificate of insurance from the supplier's broker
GDPR compliance Request DPA template; confirm ICO registration if applicable; review data processing addendum
Data hosting location Written confirmation of provider, region, and access controls
Post-launch support model Written SLA with named contact, response times, and escalation path
Exit and data portability Written exit plan included in contract or as a schedule
Contracts Finder listing Confirms active procurement engagement with UK public sector

On proportionality. The Procurement Act 2023 is explicit that financial and technical requirements must be proportionate to the contract being procured. Applying large-enterprise financial thresholds, requiring multi-year trading histories, or mandating certifications that cost more than the contract value to obtain are direct barriers to SME participation that the Act's intent is to remove. The questions above are proportionate. They can all be answered by a well-run small company.

Due diligence is not about eliminating risk. It is about understanding it clearly enough to make an informed decision. A small supplier with a transparent, specific answer to every question above represents a known risk. A large supplier with polished non-answers to the same questions does not represent less risk — it represents unknown risk with a better-looking proposal.