Lines of questioning — Beta technical

Point 8 — Iterate and improve frequently

Ask:

• How does a change reach private beta, and how often has that happened in the last month?
• When did you last roll a release back, and how long did it take?
• Which Alpha code, if any, survived, and where is the decision to keep it?

Evidence to request: pipeline definition, release log, a rollback record.

Answers that indicate Met: small releases through automation, rollback demonstrated.

Answers that indicate Not Met: production access by hand, or no way to undo a deploy.

Point 9 — Create a secure service which protects users' privacy

Ask:

• What personal data does private beta process, and where is the DPIA that describes that processing?
• What runs in CI: dependency scanning, secret scanning, infrastructure policy, or a dynamic scan? What fails the build?
• Who can access production data, and how is that list reviewed?
• What is the highest-severity finding still open, and who owns it?

Evidence to request: DPIA, CI security job output, access model. Do not request exploit steps.

Answers that indicate Met: DPIA, automated scanning, and rollback all exist and match the service. Red line B5 is clear.

Answers that indicate Not Met: real user data and any of those three missing.

Point 11 — Choose the right tools and technology

Ask:

• Which ADRs record the stack, and which options did they reject?
• What is expensive to change in the next six months, and did you test that cost in Alpha?
• How would you leave the hosting provider or the primary supplier?

Evidence to request: ADRs, the buy-versus-build note carried forward from Alpha.

Answers that indicate Met: a reader can see why this stack, why not the alternative, and how data gets out.

Answers that indicate Not Met: architecture lives in a slide with no rejected options.

Point 12 — Make new source code open

Ask:

• Where is the public repository, and what licence is on it?
• What is closed, and what is the written exception?
• Can a civil servant build and deploy without the supplier's private registry?

Evidence to request: repository URL, licence, exception log, a build the department has run.

Answers that indicate Met: new code is open now, not promised at launch.

Answers that indicate Not Met: closed by default, or open minus the commit history.

Point 13 — Use open standards and common platforms

Ask:

• Are you using GOV.UK One Login, Notify, Pay, and Forms? If not, where is the tested reason?
• Which open standards do your APIs and data exports follow?
• What did you build that a common platform already does?

Evidence to request: ADRs for each platform, or a clear "no payment taken" for Pay.

Answers that indicate Met: adopted, or rejected with a constraint the team can show. Red line B6 is clear.

Answers that indicate Not Met: a homegrown notifier, identity provider, or form runner with no comparison.

Point 14 — Operate a reliable service

Ask:

• What alerts exist, who receives them, and what did they do last time one fired?
• What are the hours a private beta user can get help?
• How are backups taken, and when is the restore drill booked? A drill result is not required for Beta. A design and a date are.

Evidence to request: alert route, support hours, backup approach, drill date.

Answers that indicate Met: the team has noticed a fault themselves during private beta, or can show monitoring that would.

Answers that indicate Not Met: users are the monitoring.

Point 5 — audit slice

Ask for the independent WCAG 2.2 AA audit statement: who did it, against which build, and which issues remain open. If it is missing, fire B2.

If user research has already fired B1, say explicitly that the audit does not mark point 5 Met.