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 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 requires contracting authorities to have regard to the particular barriers SMEs may face, and to consider whether those barriers can be removed or reduced (section 12(4)). Conditions of participation must also be proportionate, having regard to the nature, complexity and cost of the contract (section 22). That means evaluating smaller suppliers properly, not applying enterprise-scale requirements they cannot meet. 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. Section 22 of the Act requires conditions of participation to be proportionate to the contract.
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.
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-backed baseline security certification. Under Procurement Policy Note 014 (February 2025), central government departments, their executive agencies, non-departmental public bodies and NHS bodies must require it where a supplier handles personal information of citizens or government staff, or supplies ICT systems designed to store or process data at OFFICIAL level. Outside that scope, it is still the sensible minimum bar for public sector software procurement.
A certificate reference you can check yourself on the NCSC certificate search, run by IASME at iasme.co.uk, which lists certificates issued in the last 12 months. Cyber Essentials covers five technical controls: firewalls, secure configuration, security update management, user access control, and malware protection. Under the current requirements (version 3.3, April 2026), fixes for vulnerabilities a vendor rates critical or high risk must be applied within 14 days, and sign-in to cloud services must always use multi-factor authentication. Cyber Essentials Plus assesses the same controls and adds vulnerability testing. Certificates must be renewed every 12 months. 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.
A specific answer: named cloud provider, region (UK, EEA, or other), the provider's country of incorporation, 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.
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.
Under UK GDPR Article 33, a controller must report a notifiable breach to the regulator without undue delay and, where feasible, within 72 hours of becoming aware of it. Since 30 September 2026 the regulator is the Information Commission, still widely known as the ICO. A processor (the supplier) must notify the controller without undue delay, which in practice means quickly enough for the controller to meet its own deadline. 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.
A specific situation, not a hypothetical, where something 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.
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?
Named contact (not "the support team"), specific response commitments, for example acknowledgement within two hours for a production issue affecting users and 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.
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. For a configured third-party platform, who holds the licence and the configuration. 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 the certificate reference and check it on the NCSC certificate search at iasme.co.uk |
| Professional indemnity insurance | Request current certificate of insurance from the supplier's broker |
| GDPR compliance | Request DPA template; confirm registration with the Information Commission (ICO) if applicable; review data processing addendum |
| Data hosting location | Written confirmation of provider, region, provider's country of incorporation, 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 |
| Central Digital Platform registration | Under the Procurement Act 2023, suppliers register on the Central Digital Platform and receive a unique identifier. Ask for it. |
On proportionality. Section 22 of the Procurement Act 2023 requires conditions of participation to be proportionate, having regard to the nature, complexity and cost of the contract. Applying large-enterprise financial thresholds, requiring multi-year trading histories, or mandating certifications that cost more than the contract value to obtain are exactly the barriers to SME participation that section 12 asks contracting authorities to consider removing. 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.