How to use this checklist
The aim is not to generate the longest possible questionnaire. It is to ask a smaller number of questions where the answer genuinely changes your risk position, and to notice how the supplier answers as much as what they answer.
One general principle is worth stating up front: a supplier that clearly distinguishes what is built today from what is planned is easier to work with than one that answers every question affirmatively. Ambiguity on that boundary is the most common source of disappointment after go-live.
1. Data protection and information governance
- What personal data does the platform process, and for what purpose? Expect a specific answer covering staff and school contacts, and any pupil-related data.
- Who is the controller and who is the processor for each category of data?
- Where is data hosted and processed, and is any of it transferred outside the UK?
- What sub-processors are used, and how are we notified of changes?
- What retention periods apply, and how is deletion handled when we leave?
- Can you provide the information we need to complete our own DPIA?
- How are data subject access and erasure requests supported operationally?
2. Access control and permissions
Traded services involve two very different user populations — council staff across multiple service areas, and external school users. The permission model needs to reflect that properly.
- Can permissions be scoped to specific services or teams, so a service manager sees only their own area?
- Who can see commercially sensitive information such as negotiated pricing or total income?
- How are school users authenticated, and how is access removed when a member of school staff leaves?
- Can a school control which of its own users can approve orders?
- Is there an audit trail of who viewed or changed what, and how long is it retained?
- How are administrator accounts protected, and is multi-factor authentication supported?
3. Security posture
- What certifications or independent assessments do you hold today — and which are planned rather than held?
- What security testing is carried out, how often, and by whom?
- How are vulnerabilities triaged and patched, and what timescales apply by severity?
- How is data encrypted in transit and at rest?
- What is your process if a security incident occurs, and how quickly would we be told?
- How do you manage your own staff's access to customer environments?
For an early-stage supplier, some of these answers will describe intent and roadmap rather than completed audits. That can be acceptable — what matters is that the distinction is stated openly and the direction is credible, rather than implied certification that does not exist.
4. Integrations
- How does the platform export transaction data to our finance system, and in what format?
- Has that integration been done with our specific finance product before, or would it be new work?
- Do you support single sign-on for council staff, and which identity providers?
- Is there an API, and what does it cover? Is it documented and versioned?
- How are pupil numbers or other school data brought in and kept current?
- What happens to integrations when either side upgrades?
5. Data migration and exit
Migration is where projects most often lose time, and exit is where councils most often lose leverage. Ask about both at the same point.
- 1
Scope
What data will be migrated — organisations, contacts, catalogue, contracts, entitlements, transaction history — and what will not?
- 2
Responsibility
Who extracts, who maps, who validates, and who signs off that the result reconciles?
- 3
Method
Is there a trial migration, and can we test against real data before cutover?
- 4
Effort
How much council officer time does migration realistically require, and when in the year?
- 5
Exit
If we leave, what data can we take, in what format, over what period, and at what cost?
6. Resilience and continuity
- What availability do you commit to, and how is it measured and reported?
- How is data backed up, how often, and when was recovery last tested?
- What is the recovery point and recovery time objective?
- What happens if the platform is unavailable during the annual buyback window?
- How are planned maintenance windows scheduled around the academic and buyback calendar?
- What continuity arrangements exist if the supplier itself fails?
7. Functional fit — test your hardest cases
Demonstrations naturally showcase straightforward scenarios. Ask for your awkward ones:
- Our most complex pricing arrangement — can it be configured as a rule rather than a manual override?
- A trust that purchases centrally on behalf of several schools with different delivery locations.
- A mid-year cancellation with a partial credit.
- A school that requires internal approval and a purchase order before an order is valid.
- A service with an entitlement allowance that must be tracked and reported.
- Running the full annual buyback cycle ourselves without supplier involvement.
8. Implementation and support
- What does the implementation plan look like, with named responsibilities and realistic durations?
- What council resource is required, from which teams, and when?
- What training is provided for council staff, and what support material is available for schools?
- What are support hours and response commitments, and do they change during buyback?
- Do we get a test environment, and can we trial configuration changes safely?
- How are new releases communicated and scheduled?
9. Commercial model
- How is pricing structured, and what drives it up over time?
- What is included and what is chargeable extra — implementation, migration, integrations, additional modules, support tiers?
- What contract term is proposed, and what are the break and exit provisions?
- How are price increases governed over the life of the contract?
- What procurement route is available to us, and does a suitable framework apply?
10. Supplier transparency
Finally, a small set of questions that reveal a great deal about how the relationship will feel in practice:
- Which of the capabilities we have discussed are live today, which are in development, and which are roadmap intentions?
- How is the roadmap shaped, and how would our requirements be considered?
- How do you handle a request you cannot or will not build?
- What have you got wrong recently, and what changed as a result?
Service Street is an early-stage platform, and we take the same approach to these questions that we would want from a supplier: a clear statement of what exists today, what is being built, and what remains a roadmap intention — including on security and certification, where we do not claim assessments we have not completed.
In summary
Good due diligence in this market focuses on data protection, permission design, integration reality, migration effort, continuity through the buyback window and functional fit against your hardest cases — and it treats candour about current versus planned capability as a positive signal rather than a weakness.