How the Growth sub-phase works

Build in small lifecycles: each addition gets its own Discovery, Alpha, Beta. The checkpoints return: privacy, automation, architecture, procurement. Grow the users too: adoption, support, and scale rise together.

The official checkpoints of a digital service shows where Growth comes in the whole journey, checkpoint by checkpoint.

A person standing between two rising arrows

Growth is when the team builds again. The service is steady underneath, and the work turns to what comes next: the features the first version left out, the people the service has not reached yet, the load it has not yet carried. Each significant addition is built inside a running service, and it must not break what already works.

Before you start Growth

Growth starts when a steady service has real new capability waiting to be built. Have these ready:

THE MAKE-OR-BREAK QUESTION

Treat every significant addition as its own small lifecycle

A live service makes building feel cheap: the platform exists, the users are there, and a new feature seems one release away. That feeling skips the work that made the service good the first time. A significant addition changes what the service is, so it gets its own small Discovery, Alpha, and Beta, sized to the feature, and it brings the earlier checkpoints back: privacy, automation, architecture, procurement, among others.

See the full build cycle →

Running your service in Growth

The team you need

Growth runs two kinds of work at once, building and running, so the team holds both shapes (one person can hold more than one role):

  • Product and research run the small discoveries: who needs each addition, what problem it solves, and whether it worked.
  • Developers, supplier or in-house build the additions, as new paid work under the contract or by assignment in-house.
  • Operations keeps the running service to its floor while the building happens.
  • Support lead scales the help as the users arrive, and reports what the calls say about each new feature.
  • Business owner of the application decides which additions are worth building, and owns the scope, the money, and the contract room they consume.

Growth has no set length. It runs while there is real new capability worth building, and the team holds this shape for as long as it does.

CAUTION

When Growth goes wrong

  • A significant feature goes live without its checkpoints: the assessments still describe the service as it was.

  • Growth by endless amendment: the contract stretches until leaving the supplier stops being possible.

  • The build starves the running service: everyone is on the new feature, and the health cycle stops turning.

  • Nobody asked the users: capability grows, adoption stands still, and the roadmap is a wish list.

  • The launch is treated as small because the service is live, so the new feature reaches everyone at once, untested under load.

A REAL EXAMPLE

177 versions, and no way to add up the bill

ArriveCAN was built fast in an emergency, and speed is not what hurt it. The Canada Border Services Agency's records were so poor that the Auditor General could not determine what the app had cost; about $59.5 million was the estimate. The first contract was awarded through a non-competitive process the agency could barely document, and invoices often said too little to tell what work was billed against which task authorization.

The agency released 177 versions of the app, often with little or no documented testing. One update, in June 2022, wrongly told around 10,000 travellers to quarantine. A task described, priced, and approved; a release proven small first: the rules in this block are the discipline whose absence the audit describes.

How you know Growth is finished

Growth is finished when the scope settles: the roadmap holds no significant addition worth building next, and the work in front of the team is sustaining, improving in small steps, and renewing.

A service can return to Growth later. The next mandate reopens it the same way it opened the first time: a named addition, evidence, money, and room in the contract.

  • Onward to Maturity,

    when the scope has settled and the work turns to keeping the service healthy year after year.

  • Back toward a rebuild,

    when the additions reveal a foundation that cannot carry them, and extending has become harder than starting over. This is rare, and it is a Create-sized decision.

Before you settle into Maturity, have ready:

The official instruments in Growth

Everything official that has something happening to it during Growth, 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

  • Security categorizationAssessmentKeep currentsource

    A rating of how much injury would result if the service's information leaked, if someone altered it, or if the service became unavailable.

    Volume growth alone can raise the category, because a million low-sensitivity records in one place are not automatically still low sensitivity.

  • Threat and risk assessment (TRA)AssessmentKeep currentsource

    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.

    A change means the residual risk assessment is updated; a major change also goes back to the authorizer.

  • Security assessment and authorization, ending in the Authority to Operate (SA&A, ATO)AuthorizationKeep currentSign or acceptsource

    The formal permission for the service to run.

    Major changes need change requests approved by the operational authorities and the authorizer.

  • Business impact analysis (BIA)AssessmentKeep current

    The exercise that works out who is harmed if the service stops, how quickly that harm becomes serious, and what the service depends on.

    A new capability can change what the service is critical for, and growth in volume can change the injury.

  • Accessibility conformance and the accessibility statementStanding dutyKeep currentsource

    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.

    The duty re-attaches to any page created or updated after the date, so new features carry it.

  • Departmental architecture review board (DARB)ReviewKeep currentsource

    The department's own board, chaired by its chief information officer, that reviews a digital initiative's design against the government-wide architecture framework: look for something that already exists before buying or building, open standards, data, security and privacy.

    Major architectural changes go back to the board.

  • Cyber security event response and reportingPlanKeep currentsource

    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.

    A new component or integration changes what has to be watched.

  • Service in both official languagesStanding dutyKeep current

    The duty to offer and deliver the service in English and French, equally and at the same time.

    Every new feature and every new notification ships in both languages, at the same time.

Only if it applies

  • Privacy checklist and privacy impact assessment (PIA)AssessmentKeep currentsource

    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.

    A feature that handles personal information reopens it.

    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.

  • Algorithmic impact assessment (AIA)AssessmentKeep currentsource

    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.

    Reviewed, approved and updated whenever the functionality or scope of the automated decision system changes.

    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.

  • Project complexity and risk assessment (PCRA)AssessmentKeep currentsource

    A 64-question scoring tool that rates a project from level 1, sustaining, to level 4, transformational.

    A significant addition can re-score the project and move who is allowed to approve it.

    Applies when: Required at: $2.5 million with no approved capacity class or class 0; $5 million at class 1; $10 million at class 2; $25 million at class 3; $50 million at class 4, all tax included. Note this ladder differs from the architecture review board ladder as written.

  • Material privacy breach reportFilingKeep current

    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.

    New personal information in the service widens what a breach would cover.

    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.

  • Security Requirements Check List (SRCL, form TBS/SCT 350-103)SubmissionKeep current

    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.

    Each new requirement or requisition that touches new information needs its own check list, with new signatures.

    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 screeningAuthorizationKeep current

    The clearances a company and its individual staff must hold before touching sensitive government work.

    New supplier staff and new subcontractors are screened before they get access.

    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 authorizationAuthorizationKeep current

    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.

    New cloud services added to the environment come with their own assessment work.

    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.

  • Identity and credential assurance levelsAssessmentKeep current

    Two ratings, from one to four, of how sure the service has to be about who someone is, and how strong the sign-in has to be.

    A new transaction with higher consequences can raise the level.

    Applies when: Any service where people or businesses have accounts, sign in, or are identified. A worksheet under the authentication requirements guideline produces the level. At level three and above, multi-factor authentication follows.

  • Publishing under the canada.ca brandStanding dutyKeep current

    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.

    New pages use the mandatory templates.

    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.

Create, Live, and Sunset, with Create split into Discovery, Alpha, and Beta, and Live split into Stabilization, Growth, and Maturity.Stabilization, Growth, and Maturity: the three sub-phases of Live, from a just-launched service to one kept healthy over the long term.

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.