How the Beta sub-phase works
The official checkpoints of a digital service shows where Beta comes in the whole journey, checkpoint by checkpoint.
Private Beta and Public Beta
There are two parts to Beta: private and public.
Private beta. Beta starts private. A limited number of people are invited to use the real service, so the team can get feedback and improve it while the audience is still small enough to apologise to.
Public beta. Once the service has been improved and the team is confident it can be run at scale, it opens to anyone who needs it. If it replaces an existing service, it runs alongside the old way until launch.
If the service is replacing an existing one, keep the old service running until the new one is properly live. Beta is not the moment to switch it off. If the service is new, there is nothing to keep running, and this does not apply.
Neither private beta nor public beta is a launch. Launch is when the service becomes the official one for everyone, and the old way is retired when there is one. That is what ends Beta.
Before you start Beta
THE CONTRACT
The contract you sign will outlive the service
When you buy, the contract, whenever in the journey it was signed, is what the department has to live with. Signature is the moment the department has real leverage, because nothing has been committed yet.
Everything that makes a service possible to leave later is won or lost at signature:
- exit rights and data portability, written in from the start
- the code in a repository the department controls, from day one
- the end date, and the real lead time for renewing or re-competing
- the accessibility clauses, and an accessibility conformance report from the supplier. In Canada the accessibility check happens when you buy, so a service bought without those clauses is a service you will pay twice to fix.
A service that was never designed to be left is expensive to leave, and by then the department has no leverage at all. Procurement covers how to buy, and what a good contract looks like sets out the clauses.
What to build and prove in Beta
The team you need
Beta is the longest and most expensive part of Create. Expect months, and expect the cost to be dominated by the build or the configuration.
Keep the Alpha team on. The people who did the research and the prototyping carry the empathy, the context, and the momentum. Handing the service to a fresh team at the moment it becomes real throws all three away.
The minimum roles to sustain Beta. One person can hold more than one.
- Product owner decides what is in the first real version and what waits, and holds the authority to say no.
- Delivery manager keeps the build moving and holds the timeline against the launch date.
- Developers or a supplier team build or configure the real service.
- Designer takes the service from a proven idea to something people can actually use.
- User researcher runs the proving with real users, and keeps finding what is broken.
- Operations stand up what the service runs on, and prepare to run it.
- Contracting authority signs the contract, and is the one person who can hold the supplier to the exit clauses.
- Business owner of the application accepts the risk that remains, funds the work, and gives the go-ahead to launch.
CAUTION
When Beta goes wrong
Some of the signs to watch for:
The prototype was promoted.
Alpha's throwaway code became the real service, and it carries every shortcut taken when it was meant to be discarded.
The contract was signed in a hurry.
No exit rights, no data portability, the code in the supplier's repository. The department is now renting its own service.
Proving was skipped.
The service went from prototype to everyone, so its first real users are the entire public.
Nobody owns the dashboard.
The service is live and blind, and the only party who can see it is the supplier.
The team that built it is not the team that will run it,
and nothing was written down.
Launch became the goal.
The date is being defended rather than the service, and quality is being traded away to hit it.
A REAL EXAMPLE
Phoenix skipped the pilot and launched for everyone at once
In 2016, the Government of Canada replaced its 40-year-old pay system with Phoenix. To hold the date and the budget, the planned pilot, one department going first, was dropped, critical pay functions were removed, and system testing was cut short. The department knew about serious weaknesses, and Phoenix went live anyway, for everyone, in two waves.
Within months, tens of thousands of public servants were paid wrong or not paid at all: wrong cheques, missed cheques, people checking their own stubs with a calculator. The backlog grew to hundreds of thousands of pay cases, and fixing the system has cost several times what building it did. The Auditor General called it an incomprehensible failure of project management and project oversight. The invited group, the capped volume, the go decision made on evidence: what this page asks of Beta is what Phoenix skipped.
How you know Beta is finished
The finish criteria. Beta is done when the service has been through private beta and then public beta, has been used by real people at scale, and has held up. It delivers the whole journey, end to end. The service meets the accessibility standard and what the testing found has been fixed, the privacy assessment is done, the dashboard is live, and the support is staffed.
The department can carry it after launch
This is the test the guide exists for. The department can support the service and keep improving it, every year, until it is replaced or retired. If it cannot, the service is not ready to launch, however well it demos.
Support means named people with time in their week, money in a budget that renews, and somewhere for a user to go when the service fails them. A launch with none of those produces a service that degrades from its first day and has nobody whose job it is to notice.
The launch decision runs against the criteria you already wrote
The go and no-go criteria were agreed at the start of Beta, before a launch date existed. The decision at the end of Beta is reading the evidence against them, and that is all it should be. Rewriting the criteria once the date is in a minister's calendar defeats the point of having written them.
when the service launches and becomes the official one for everyone. The work turns from building it to steadying it.
when proving with real users shows the approach does not work, and it needs rethinking before more money goes into it.
Stop,
when the evidence says the service should not launch at all. This is rare and it is expensive, and it is still cheaper than launching something that does not work.
Off-ramp to-do. Alpha's list was about the build: everything on it was something a supplier could be asked to deliver. This one is about the department, and by that the guide means commitments no supplier can make on the department's behalf: people with the service in their objectives, budget that renews without anyone arguing for it again, and authorizations that belong to a named official. Each item has to be true on the day the service stops being a project and becomes someone's long-term responsibility. Before you move to Stabilization, have ready:
Launch
Beta ends here. The service becomes the official one, real people depend on it, and the department owns it from this point until it is replaced or retired.
The official instruments in Beta
Everything official that has something happening to it during Beta, and what that something is. The tag says what stage the instrument reaches here, not that it is finished.
Placing an instrument in a sub-phase is this guide's own editorial choice, anchored where possible on a real deadline in the instrument itself. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.
Every service
The exercise that lists what could go wrong, ranks each by how likely it is and how much damage it would do, and states the risk left over after safeguards.
Second pass, against the system that was actually built. Its results go into the residual risk assessment the authorization rests on.
- Security assessment and authorization, ending in the Authority to Operate (SA&A, ATO)AuthorizationSign or acceptsource
The formal permission for the service to run.
The authorizer approves the detailed design, approves production installation on larger projects, then signs the Authority to Operate before operations commence. It does not expire and is not renewed on a clock.
- Business impact analysis (BIA)AssessmentGather
The exercise that works out who is harmed if the service stops, how quickly that harm becomes serious, and what the service depends on.
Hand over the dependency list: the systems, suppliers, staff, facilities and partner services this one depends on, including where another organization is relied on.
Conformance of the service itself to the Canadian accessibility standard for information and communication technology, plus a published statement that names what does not conform, what the alternatives are, and when the gaps close.
Tested against the standard, findings fixed, and the statement published no later than the day the obligation first applies.
The written consent from Library and Archives Canada without which no government record may be destroyed, plus the department's own schedule saying how long each kind of record is kept.
The retention and disposition schedule is set. Any gaps are flagged before launch rather than discovered at retirement.
The service team's own recovery arrangements: how this system gets back up, in what order its parts are restored, and proof from testing that the restore actually works.
Backups, restore procedure and restoration priorities exist and have been tested at least once before launch, rather than being assumed.
The duty to have a way of spotting, containing and reporting a cyber incident before one happens, and to report it up the government-wide chain when it does.
Know before launch who to call at 2am, how the service is monitored, and what the escalation path is. Editorial placement: the duty is standing rather than tied to launch.
- Service in both official languagesStanding dutyFillSubmit
The duty to offer and deliver the service in English and French, equally and at the same time.
Both languages launch together. Where a Treasury Board submission is involved, the Official Languages Appendix goes with it.
The decision about where the service runs, made against a government-wide preference order rather than a local preference.
The hosting arrangement is in place and the decision is on the record.
- Access to information readiness, and the duty to documentStanding dutyFill
Everything the service records is subject to an access request, and decisions of business value have to be documented in the first place.
Records are structured and retrievable, not scattered across systems nobody can search.
Only if it applies
- Physical security assessment and Authority to Occupy Facility (ATOF)AuthorizationFillSign or accept
The second, parallel security track, for buildings, equipment and physical space rather than systems.
Where software will operate building equipment, the assessment and authorization have to be complete before implementation, and starting early is advised in the source.
Applies when: Only if the service touches physical space: new accommodation, hardware in people's hands, kiosks, or software that operates doors, gates, lighting or heating. A cloud-hosted service with no hardware usually stays clear of it.
- Business continuity plan (BCP)PlanGather
The written arrangements for keeping a critical service delivering at a minimum acceptable level during a disruption, and recovering it afterwards.
Before launch, the service's recovery steps and workarounds go to the coordinator so the plan covers it from day one. Editorial placement: the directive sets no launch checkpoint.
Applies when: Only if the business impact analysis marks the service critical, meaning disruption would cause a high or very high degree of injury. One department reads that as needing to recover to minimum service levels within 72 hours.
A structured look at what personal information the service collects, why it is allowed to, where it flows, how long it is kept, and what happens to people if it goes wrong.
Approved and filed before real personal information is collected.
Applies when: Triggers are broad. A new or substantially modified program that creates, collects, uses, discloses, retains or disposes of personal information brings it into scope. So does using it for an administrative purpose, contracting the program out or transferring it, bringing in a third party, changing the technology that processes it, or automating a decision. No dollar or user-count threshold.
A questionnaire the department fills in about itself, scoring how much an automated decision could affect people's rights, health, economic interests or the ongoing sustainability of an ecosystem.
Completed, approved and published before production. At impact level two and above a peer review is also required, and its findings published before launch.
Applies when: Only if the service makes or supports an automated decision about a person: scoring, ranking, recommending, or auto-approving. A later efficiency feature can trigger it without anyone noticing.
A supplier's written statement of how far their product meets the accessibility standard, clause by clause, with the gaps named.
Provided at contract award and verified, not taken on trust. A remediation roadmap covers what it does not meet.
Applies when: Only when buying. An in-house build has no supplier and no report; the equivalent duty is the department's own conformance assessment against the standard.
- Material privacy breach reportFilingCheck
The report a department must make when personal information is lost, accessed or disclosed in a way that could reasonably be expected to cause serious injury.
Know, before launch, who in the department makes the materiality call and how fast they need to hear from the team.
Applies when: Only when a breach involving personal information is judged material, on sensitivity of the information, number of people affected, and whether it is a systemic problem. A cyber incident touching personal information can trigger both this and the cyber reporting route at once.
- Official languages in what you buyStanding dutySign or accept
The obligation to write official languages requirements into the contract, so a supplier is contractually bound to deliver both languages rather than being asked for French later as a change request.
The clauses are in the signed contract and the deliverables are checked against them.
Applies when: Whenever a supplier delivers, hosts or supports any part of a service that reaches the public, or produces content on the department's behalf. Guidance is set through a contracting policy notice.
- Security Requirements Check List (SRCL, form TBS/SCT 350-103)SubmissionSign or acceptSubmit
A short form that states, for one specific contract, exactly what security the supplier and its people need: what level of information they will touch, what screening each role needs, and whether the company may hold government information at its own offices.
The project authority signs their block; the security officer signs theirs. Clearance is confirmed before award, and supplier screening can take months, so a late start delays the contract, not the paperwork.
Applies when: Only where the supplier or its people will access Protected or Classified information or assets, enter restricted sites, or connect electronically to departmental systems, which includes any access to personal information the department holds. Where there are no security requirements, no check list is produced and the department certifies that instead.
- Supplier organization and personnel security screeningAuthorizationGatherSign or accept
The clearances a company and its individual staff must hold before touching sensitive government work.
Confirmed before award. Individual screening can run months, and new staff joining mid-contract need it too.
Applies when: Every procurement whose Security Requirements Check List identifies a security requirement, and the same applies to subcontractors at every tier. Organization screening covers Protected A, B and C; a facility clearance is for Classified.
- Cloud security profile, guardrails, and the cloud authorizationAuthorizationFillSign or accept
The extra security work a cloud-hosted service carries: a ready-made control profile to build against, a set of guardrails to be in place within the first days of a new cloud environment, and a security assessment that has to account for what the cloud provider does versus what the department does.
Guardrails in place in the new environment, the security assessment done against the split of responsibility, and the authorization signed before operations commence.
Applies when: Only for cloud-hosted services. The Protected B control profile is the usual starting point. The Cyber Centre separately assesses cloud service providers, so a department inherits that assessment rather than repeating it, and assesses only its own configuration and use.
- Government of Canada credential and sign-in servicesStanding dutyFillSubmit
The shared sign-in services a department uses instead of building its own: the government-branded credential service, the commercial bank-based option, and the newer federated sign-in platform.
Onboarding, attestation and testing in the acceptance environment take real calendar time and are a common launch delay.
Applies when: Any external-facing service where clients sign in. Onboarding to the federated platform involves a compliance attestation and testing in a client acceptance environment.
- Publishing under the canada.ca brandStanding dutySubmitSign or accept
The rules for anything the public sees: the domain, the global header and footer, the Government of Canada signature and wordmark, the mandatory page templates, the information architecture, and the content style guide.
The domain is approved by the Principal Publisher and the official web analytics tool is in place. Start the domain request before any launch date is promised to stakeholders.
Applies when: Every external-facing website and web application. Two sign-offs: inside the department the head of communications is accountable for external-facing sites, and outside it the Principal Publisher, which is Employment and Social Development Canada through Service Canada, controls the canada.ca domain and must approve every domain and sub-domain.
- Mobile: responsive by default, native app by justificationStanding dutyFill
The rule that a public-facing service works properly on a phone, and that building a downloadable app instead of a responsive web page has to be justified.
Tested on real devices before launch. A native app additionally goes through the central publishing process.
Applies when: Every public-facing website and web application.
- Proactive publicationFilingSubmit
Publication that happens without anyone asking.
The contract that buys the build is published once awarded.
Applies when: Triggered by what the service does rather than by its size. Any contract over $10,000 triggers contract publication; a grants or contributions program triggers the other.
Assumptions this page makes
You are already working to the Government of Canada Digital Standards, design with users, iterate and improve frequently, work in the open, use open standards, address security and privacy, build in accessibility, empower staff, be good data stewards, design ethical services, and collaborate widely, and to the law on privacy, security, official languages, and accessibility. The standards say how the government works in the digital world. The six Government of Canada digital competencies say what every public servant has to be able to do to work that way, and the team page covers them. This guide builds on those.