Skip to main content

What are you looking for?

Explore our services and discover how we can help you achieve your goals

UK software delivery: the assurance pack, accessibility and the defect route

A UK buyer's first question is usually not "can you build it?" but "what evidence will you give our procurement, security and accessibility reviewers?" Decide whether you are buying for a public-sector body or a private organisation, list the evidence each reviewer needs, and agree how defects found in testing are decided before the build starts.

Submit a project Explore custom engineering

Reviewed by Huy Nguyen (David), CEO · Updated 14 Oct 2026 · 10 min read

star

OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier that would like your project. It sets out the evidence Netbase can put in front of UK reviewers, the official UK references your advisers will use, and the decisions that stay with you. The guides index lists the guides for other markets.

Contents

Are you buying for a public-sector body or a private organisation?

The answer changes the accessibility and procurement questions more than anything else in the brief.

  • Public-sector bodies. GOV.UK publishes accessibility requirements for public-sector websites and apps, including testing, an accessibility statement and a route for users to report problems. Your team decides how they apply to your service and which exemptions, if any, you rely on.
  • Private organisations. The public-sector regulations are not a template to copy wholesale. You still decide which accessibility standard you commit to, for which users and journeys, and who signs off.
  • Both. The ICO's guide to data security describes risk-based technical and organisational measures for the confidentiality, integrity and availability of systems. Your advisers decide what applies; engineering turns their decisions into access roles, environments, logging and recovery tests.

Mixed services, such as a private supplier running a service for a council, should record which set of requirements each journey follows.

What can Netbase put in a supplier evidence pack?

Procurement and security reviewers ask for specific statements. These are the ones Netbase can provide, in the wording registered for publication.

  • Security practices. Security practices include secure code review and version control, role-based access control, MFA for admin dashboards, contributors under NDA, and NDAs and DPAs on request.
  • Information security management. Netbase JSC holds ISO 27001 certification for information security management, and Netbase JSC holds a SOC 2 Type II attestation. No certificate or report number, date, auditor or audit scope is published, and neither extends to the system built for you or its hosting.
  • Data privacy practices. Netbase's compliance practices are GDPR alignment for data privacy in Europe, HIPAA-aligned methodologies for healthcare data handling, and CCPA compliance for clients with U.S. customer bases. Your own UK GDPR position remains your organisation's responsibility.
  • Intellectual property. For custom development the client owns the IP created for it; Netbase productized modules and products are licensed, not transferred. The IP ownership guide covers the contract clauses.
  • Language. Netbase delivery communication is in English.
  • Named records. Two delivery records name their clients. The 4over4 print-commerce conversion record covers a product recommendation engine and an automated conversion of uploaded Adobe Illustrator files to SVG, which is file-format automation rather than AI. The Netztech migration record covers a Magento 1 to Magento 2 Commerce migration in 35 working days, including 11 extensions.
  • Client reviews. Netbase JSC's Clutch profile carries client reviews from businesses in Romania, Spain, Sweden, France, Denmark, the Netherlands and Belgium.

Netbase has also delivered product personalisation on print stores for print-commerce clients in several countries, the United Kingdom among them; that list describes a delivery footprint, not a local presence.

On Trustpilot, a customer of Netbase's NB Designer product wrote: "We've been using the NB designer over the last few years and had nothing but rave reviews from customers who use it. We've also received excellent and timely support from the team at Netbase." — Sam Coldwell, Trustpilot review, United Kingdom, 2024-07-26, five stars. The review concerns the product and its support, not a custom delivery project for a UK buyer.

What should the evidence pack contain?

Give each reviewer a row, so nothing is assumed and nothing is promised twice.

Reviewer What they ask for What the supplier provides Who decides
Procurement Company details, references, contract terms, IP position Registered company statements, named records, draft contract clauses Procurement lead
Security Development controls, access model, incident contacts Security practices, ISO 27001 and SOC 2 Type II statements, access matrix for this project Security owner
Data protection Data map, processor terms, retention and deletion DPA on request, data-flow sheet for the system Data protection lead with advisers
Accessibility Standard adopted, test approach, defect log Test plan per journey, test results, open defects with severity Service owner
Operations Support, change and recovery route Runbook, escalation contacts, handover plan Operations lead

Ask for the pack before shortlisting, not after selection. The data security and compliance guide lists the contract questions behind the security and data rows.

How should accessibility testing run?

  1. Choose the journeys

    Sign-in, application or checkout, document download, error recovery and contacting support are a common starting set.

  2. Name the standard and the owner

    Record which standard you adopt and who accepts results for each journey.

  3. Test during the build

    Include keyboard-only use, screen readers, zoom and colour contrast in each increment rather than in a final audit.

  4. Log every finding

    Journey, observed behaviour, impact, severity and proposed fix.

  5. Decide each open finding

    Fix before release, fix by a dated follow-up, or accept with a documented reason.

  6. Update the statement

    If you publish an accessibility statement, the open findings and dates come from this log.

Diagram of an accessibility testing pipeline: choose journeys, name the standard and owner, test during the build and log every finding, then decide each finding, fix and retest before release, and update the statement (opens the full-size diagram in a new tab)
Diagram of an accessibility testing pipeline

Worked scenario: a defect found in acceptance testing

During user acceptance testing of a council-facing booking service, a tester using a screen reader finds that the error message on the date-of-birth field is not announced. Sighted users see a red message; screen-reader users hear nothing and cannot tell why the form will not submit.

  1. Log

    Finding recorded with journey, assistive technology, browser, steps to reproduce and severity "blocks completion"

    Owner
    Tester
  2. Assess

    The supplier confirms the cause: the message is not linked to the field and not announced

    Owner
    Supplier lead engineer
  3. Decide

    The service owner rules that a blocking defect in a core journey must be fixed before launch

    Owner
    Service owner
  4. Fix and retest

    The fix is applied to every form using the same component, then retested with the same assistive technology

    Owner
    Supplier and tester
  5. Record

    The log shows the finding, the decision, the fix and the retest result

    Owner
    Service owner
  6. Pattern check

    The team searches for the same component elsewhere and adds a test to the next increment's checklist

    Owner
    Supplier QA

A minor defect in a secondary journey might instead be accepted with a dated fix. The point is that the buyer decides and the log records it.

Which questions should you ask a supplier?

  • What exactly is in your security statement? A good answer uses precise wording and says what the statement does not cover.
  • Which records can we read, and which clients are named? Look for named records you can check.
  • Who owns the code and designs? Expect a clear IP position before contract.
  • How do you test accessibility during the build? Look for per-journey tests with assistive technology, not a final scan.
  • Who decides whether a defect blocks launch? It should be your service owner.
  • Where do contributors work, and how is access removed? Expect an access matrix and an offboarding step.
  • What does handover include? Expect a runbook, the defect log and the credentials you will hold.

What usually goes wrong?

  • A company-level statement read as project assurance. Signal: nobody tested this system's controls. Owner: the security owner.
  • Accessibility left to a final audit. Signal: a long defect list a week before launch. Owner: the service owner.
  • Public-sector rules copied into a private scope. Signal: effort spent on duties that do not apply, while real users are missed. Owner: the product owner with advisers.
  • Defects closed without a decision. Signal: "won't fix" with no reason. Owner: the service owner.

How this guide is sourced and where it stops

This guide uses the GOV.UK public-sector accessibility requirements and the ICO guide to data security, both accessed on 2026-09-27, and company statements and delivery records approved in the OutsourcingVN claim register. It is written for procurement, product and technology leads preparing a UK brief. Your advisers decide which duties apply. Netbase JSC's head office is in Hanoi, Vietnam, and it is the company's only office, so UK projects are delivered remotely.

Plan the next step for your project

Common questions

No. They apply to public-sector bodies, with some exemptions set out in the guidance. A private organisation still chooses an accessibility standard and journeys to test, but it should state its own commitment rather than copying the public-sector regulations, and record who accepts the results.

Ask for its development controls in writing, its company-level information security statements, an access matrix for your project and a data processing agreement. Then test the controls that matter for your system during acceptance, because company-level statements describe the supplier, not the software it builds for you.

Many requirements concern evidence rather than location: security practices, data processing terms, IP ownership, English communication and named references. Check each requirement in your procurement route, and ask the supplier to show which it can evidence and which it cannot.

The organisation that runs the service. The supplier provides test results, the defect log and fix dates; the service owner decides what the statement says and keeps it current after launch, because later content and feature changes affect it too.

It depends on the number of journeys and on how many defects are found early. Testing accessibility in each increment keeps the final acceptance window short, because the last round confirms fixes instead of discovering problems for the first time.

Plan the first release

Bring your sector context, the journeys you want tested, your procurement route and the names of your service, security and data protection owners. The total software delivery cost worksheet helps compare proposals that include testing and remediation, and the methodology explains how the statements on this page are recorded. For other markets, the Singapore guide covers phased redevelopment and Myinfo data, and the Mauritius guide covers continuity and reconciliation. In continental Europe, the Netherlands guide covers Peppol e-invoicing and the Dutch supervisory authority, and the Germany guide covers works-council consultation and German e-invoicing formats.

Custom Product Engineering is the service for a bounded build, and global delivery explains how remote delivery is organised. OutsourcingVN is Netbase's own outsourcing-services platform: submit a project with your first service journey, and a person will reply with whether discovery or a bounded implementation is the right next step.

Custom product engineering for a bounded release outcome Custom product engineering for a bounded release outcome

One defined release of your product, built to named outcomes and handed over with acceptance evidence.

Learn More
line

Tell us what you want to build or automate.

Submit a project