The Evidence Cupboard: Building UK Public-Sector App Credentials Before the Tender Lands

Public-sector app deals rarely fall over at the demo. They fall over in the gap between what the buyer can see and what the buyer can evidence. A council, NHS trust or arm’s-length body can like the product, trust the team and still stall the award because the security answers are thin, the data-protection schedule is vague or the accessibility claim is a PDF with a tick-box and no test trail.

The fix is not a last-minute bid scramble. It is an evidence cupboard: a small, maintained set of artefacts that maps directly to how you build. If you leave public-sector paperwork until the Invitation to Tender (ITT) lands, you end up writing policy prose at midnight. If you build it alongside delivery, the tender becomes a sorting exercise.

The demo is the easy bit

Most UK app teams know how to show a journey, talk through architecture and answer questions about roadmap. Public-sector buyers are doing something different. They are assembling an audit trail. They need to know who processes what, where data sits, how access is controlled, what happens when something breaks and whether the supplier can still answer the same questions in eighteen months.

That is why a polished prototype can lose to a plainer product with better evidence. The buyer is not just choosing an app. They are choosing a supplier they can defend to procurement, legal, information governance and, sometimes, a scrutiny committee.

What the buyer opens before your pitch

The exact order varies, but the categories are consistent across councils, NHS trusts, police bodies and other public-sector buyers.

Security questionnaires. These often start with Cyber Essentials or Cyber Essentials Plus, then move into access control, patching, incident response, encryption, logging and supply-chain risk. ISO 27001 helps, but it does not answer every question on its own. Buyers want to see the control in practice, not just the certificate.

Data-protection schedules. Expect questions on lawful basis, data mapping, retention, sub-processors, international transfers, subject rights and breach notification. A Data Protection Impact Assessment (DPIA) may be requested, especially where health, children’s data or location tracking is involved. If your app relies on third-party analytics, crash reporting or push notifications, those suppliers need to appear in the schedule.

Accessibility evidence. A statement saying the app is accessible is not evidence. Public-sector buyers increasingly expect a clear target, usually WCAG 2.2 AA, plus a testing approach that includes manual checks and assistive technology, not only automated scans. A short accessibility conformance report with known gaps is more credible than a perfect claim with no method behind it.

Social value commitments. Councils in particular may ask how the contract delivers local economic, environmental or community benefit. That could mean local hiring, apprenticeships, carbon reporting or support for voluntary groups. The commitment needs to be measurable and tied to delivery, not a paragraph of good intentions.

Financial standing, insurance and references. These are familiar bid gates, but they still trip up small teams. Keep current certificates, insurance schedules and two or three reference contacts ready. Make sure the reference story matches the evidence in the rest of the pack.

Turn build artefacts into bid evidence

The useful shift is to stop treating procurement paperwork as a separate workstream. Map it to the build.

In discovery, produce the first data map and a DPIA screening note. Agree the accessibility target and the browsers and devices you will test. Record the sub-processors you expect to use before architecture hardens around them.

In architecture, write the security summary in plain English. Note hosting location, backup approach, identity model, administrative access and incident escalation. If you use a UK hosting provider, be precise about which layers are UK-hosted and which are not. Buyers can spot a loose claim.

In build, keep test evidence as you go. Accessibility checks, penetration test scoping, vulnerability remediation and retention rules should generate artefacts that can be reused in a bid. A pen-test summary written for the client is often 70% of the security questionnaire answer already.

At launch, finalise the DPIA, retention schedule, support model and exit plan. The exit plan matters more than teams expect. Public-sector buyers want to know how data comes back, how it is deleted and what happens to integrations if the contract ends.

The cupboard, not the scramble

A practical evidence cupboard is a folder structure with named owners and review dates. It might include company documents, security summaries, data-protection schedules, accessibility reports, social value commitments, delivery references and handover examples. Keep a reusable narrative for each section, then tailor the specifics to the tender.

Do not dump generic policy PDFs into a bid portal and hope volume wins. Buyers are looking for direct answers. A two-page security summary with clear evidence links is more useful than a forty-page policy pack with no mapping to the questions asked.

NHS trusts and councils do not ask the same questions

A council may lean hard on social value, local spend and accessibility. An NHS trust may ask for the Data Security and Protection Toolkit (DSPT) position, clinical safety documentation where relevant, and a more detailed data-protection trail. A combined authority or transport body may care about resilience and public liability. Build the core cupboard once, then keep sector-specific appendices.

Keep the claims boring and true

The temptation in a tender is to overclaim. Resist it. If a sub-processor is outside the UK, say so. If a WCAG audit found issues, list them with a remediation date. If your support hours are office hours, do not imply 24/7 cover. Public-sector buyers are not looking for perfection. They are looking for consistency between the sales deck, the contract and the build.

A pre-tender routine

Once a quarter, review the cupboard as a team. Check certificates and insurance dates. Update the sub-processor list. Re-run a short accessibility check. Make sure the security summary still matches the architecture. Add one new piece of delivery evidence from a recent project. Then, when a tender lands, you are editing rather than inventing.

That is the quieter advantage in UK public-sector app work. The team with the evidence cupboard rarely looks flashy in the demo. It just keeps passing the checks that decide the deal.