The 2026 Guide
IndexAsk the guideFR

How the Maturity sub-phase works

Where this fits

CreateLiveSunset
StabilizationGrowthMaturity
Keep the cycle turning: monitoring, patching, research, filings. Renew before it ends: funding and contracts, months of runway. Watch for the exit: the signals that point to Sunset.

Checkpoints a GC digital service has to pass shows where Maturity comes in the whole journey, checkpoint by checkpoint.

A person standing calmly between two growing plants

A mature service runs every day because a team keeps it running. Parts age out of support, people change jobs, and the funding and the contract move toward their end dates, and none of it pauses because the service seems fine. The team stays ahead of it all on a cycle: watching, patching, researching, filing, renewing. Most of a service's life is spent in Maturity, and so is most of its work.

Before you start Maturity

Maturity is entered from Stabilization when a service already has the scope it needs, or from Growth when the scope settles. Have these ready:

THE MAKE-OR-BREAK QUESTION

Start every renewal before it feels urgent

Nothing in Maturity fails as predictably as a renewal started late. Funding envelopes end on a date. Contracts end on a date. Both need months of lead time, because a funding decision moves at the speed of approvals and re-competing a contract takes longer still. Start late and you have one option left: extend with the current supplier on the current terms. Every emergency extension deepens the lock-in. Put every end date on a calendar the team actually looks at, with the start-by date beside it.

See how contract renewals are planned →

Running your service in Maturity

The team you need

A mature service runs on a smaller team than a build, and the shape holds for years (one person can hold more than one role):

  • Operations keeps the service up, patched, and monitored, and releases the fixes.
  • Support lead helps people through, and reports what the calls are saying.
  • Developers, supplier or in-house a steady slice of capacity for fixes and small improvements. The slice can be small; a service that stops improving ages toward a forced replacement.
  • Business owner of the application owns the renewal calendar, the yearly filings, and the decision that Maturity is ending.

Maturity is measured in years, so everyone on this list will eventually move on. What carries across the changes is what was written down: the runbooks, the known errors, and the reasons behind the decisions. Treat the writing as part of the job. The service team covers keeping the capability.

CAUTION

When Maturity goes wrong

  • Improvement stops: the service is patched but never made better, and it ages toward a forced replacement.

  • A renewal starts late, and the only option left is an emergency extension on the supplier's terms.

  • The health cycle turns on paper: the boxes tick, the dashboard is read, and nothing changes as a result.

  • Nobody from outside ever looks at the service, so the team stops seeing its own gaps.

  • The knowledge leaves with the people: the team can still operate the service but no longer understands it.

A REAL EXAMPLE

The forced replacement was named Phoenix

The pay system Phoenix replaced had run for about 40 years, and by the end, replacing it was no longer a choice the government could defer.

A replacement that can no longer wait gets run as an emergency: a fixed date, and pressure to be fast and cheap. The corners cut under that pressure became the Phoenix disaster. Keeping a service improving while improving is still optional is what spares whoever comes next from inheriting its problems, multiplied.

How you know Maturity is finished

Maturity has no finish line of its own. It ends when something outside the routine changes: a new mandate arrives, or the signals say the service's time is ending. Either way the crossing is work, and it starts while the current money and team are still there.

The decision to leave is made on evidence and written down

The evidence already exists: the dashboard, the running costs, and the review with clients and partners that comes round at least once every five years. The case for leaving is assembled from records the team already keeps.

The business owner of the application makes the call and records the reason, with the review findings, the dashboard and the costs attached. That record is what the next funding request is built on, and the first thing whoever inherits the service reads.

The money for what follows is set aside before the current funding ends

The next piece of work costs money. A return to Growth needs a new funding decision for the build; a retirement is months of funded work in its own right. Neither can be paid for out of an envelope that has already ended.

Start the request while the current envelope is still paying for the service. A funding decision moves at the speed of approvals, and extensions bought in the meantime are bought on the supplier's terms.

The knowledge and the registers are ready to hand over

Whoever follows inherits the service through what was written down. Bring the runbooks, the known errors, the decisions and the contract's end-of-term obligations up to date before the crossing, because the people holding the unwritten version leave with it.

Both register entries have to match reality at the crossing, because whoever follows will close or transfer them. The closing itself happens at Sunset.

  • Back to Growth,

    when a new mandate or a significant new capability needs building. The earlier checkpoints come back with it.

  • Forward to Sunset,

    when the signals hold: the need met elsewhere, the users leaving, the policy basis gone, or the platform ending. Retiring a service well is its own piece of work, and it starts while the money is still there.

  • Back into a Stabilization-like window,

    after a major replatform or a serious failure, while the service steadies again. This is rare.

Whichever exit, leave in good order. Before you move on, have ready:

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.

The official instruments in Maturity

Everything official that has something happening to it during Maturity, 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 full instruments table.

What the tags mean

Keep current
The service changed, or the clock came round. Re-run it, re-test it, or refresh the record.

Every service

  • Security categorizationAssessmentKeep currentsource

    A rating of how much injury would follow a leak, an unwanted change to the information, or an outage.

    Reviewing the category of the business activities the service supports is the first authorization-maintenance activity, on the department's cycle.

  • Threat and risk assessment (TRA)AssessmentKeep currentsource

    The exercise that lists what could go wrong, ranks each one by how likely it is and how much damage it would do, and states the risk left over once the safeguards are in place.

    Re-assessed as the threat picture moves, at a frequency set in the departmental security plan.

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

    The formal permission for the service to run in production.

    Authorization is maintained throughout the operational life: control performance reviewed, threat environment re-assessed.

  • Business impact analysis (BIA)AssessmentKeep current

    The exercise that decides how critical the service is, and produces four numbers with it: maximum allowable downtime, minimum service level, recovery time objective and recovery point objective.

    Refreshed on the department's own cycle. Public Safety Canada recommends a full refresh of the analysis and the plan in year one, with reviews in years two and three.

  • 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.

    Statement refreshed every 12 months and retained electronically for four years.

  • GC Service InventoryRegisterKeep currentsource

    The government-wide register of what services exist, who they serve, how digital they are, and how much volume they handle.

    Updated annually, with every data element reviewed, typically collected over the summer for the previous fiscal year.

  • Application Portfolio Management (APM)RegisterKeep current

    The register of the applications behind the services, rated for business value, technical condition, support cost and criticality, and sorted into tolerate, innovate, mitigate or eliminate.

    Updated through the year. Where owners are not engaged, the data goes incomplete and support costs go untracked.

  • Records retention and disposition authorityRegisterKeep currentsource

    The written consent from Library and Archives Canada without which no government record may be destroyed.

    Disposition happens regularly through the life of the service, not only at the end.

  • Information technology continuity managementPlanKeep currentsource

    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 works.

    Re-tested on the department's cycle. An untested backup has not been shown to work.

  • 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.

    Response arrangements are exercised and kept current with the service.

  • Service in both official languagesStanding dutyKeep current

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

    Carried through the department's annual official languages review, and again on funding renewal.

  • Application hosting decision, and the public cloud defaultReviewKeep currentsource

    The decision about where the service runs, made against a government-wide preference order: software as a service before platform before infrastructure, and public cloud before hybrid before private before non-cloud.

    Revisited as the technology ages, and again where custom support has to be extended to keep something supported.

  • Access to information readiness, and the duty to documentStanding dutyKeep current

    Everything the service records can be asked for under an access request, and decisions of business value have to be documented in the first place.

    Summaries of completed requests are published monthly by the department.

  • Open data and open informationFilingKeep current

    The expectation that data and information of business value are released openly by default, in reusable formats, unless something specific stops it.

    Releases and the institution's information description are kept current.

Only if it applies

  • Business continuity plan (BCP)PlanKeep current

    The written arrangements for keeping a critical service delivering at a minimum acceptable level during a disruption, and recovering it afterwards.

    Tested. There is no mandated interval in the directive, which requires only regular testing in accordance with departmental practices; large departments are measured on a two-year testing window. The testing obligation lands on service owners in practice.

    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.

  • 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 could happen to people if it goes wrong.

    Updated as the service changes, rather than left to go stale.

    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 scored questionnaire about how much an automated decision could affect a person's rights, health or economic interests, or the ongoing sustainability of an ecosystem.

    Updated on a scheduled basis.

    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.

  • Accessibility conformance report (ACR)AssessmentKeep currentsource

    A supplier's written statement of how far their product meets the accessibility standard, clause by clause, with the gaps named.

    Updated after significant software updates, and at minimum annually, with changes marked.

    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.

  • Official languages in what you buyStanding dutyKeep current

    The obligation to write official languages requirements into the contract, so the supplier is contractually bound to deliver both languages.

    Renewals and amendments carry the clauses forward.

    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)SubmissionKeep currentsource

    A short form that states, for one 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.

    Renewals, re-competitions and amendments carrying a security requirement each need one.

    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 currentsource

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

    Clearances expire and are renewed. Work cannot continue on lapsed screening.

    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 currentsource

    The extra security work a cloud-hosted service carries: a ready-made control profile to build against, guardrails that have to be implemented, validated and reported within the first 30 business days of getting a cloud account, and a security assessment that accounts for the split between what the provider does and what the department does.

    Configuration drifts. The guardrails and the assessment are re-checked.

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

    The shared sign-in services a department can use in place of building its own: the government-branded credential service, the commercial bank-based option, and the newer federated sign-in platform.

    Platform changes and credential migrations land on the service.

    Applies when Any external-facing service where clients sign in. Joining a shared platform involves compliance checks and testing before go-live, and the platform's own team sets what those are.

  • Publishing under the canada.ca brandStanding dutyKeep currentsource

    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.

    Analytics-based optimization is a continuing duty, not a launch task.

    Applies when Every external-facing website and web application. Inside the department the head of communications is accountable for external-facing websites and for mobile applications, and the directive holds both to its Appendix D, the Standard on External-facing Websites and Mobile Applications. The same directive requires the official web analytics tool administered by Service Canada.

  • Responsive web, or a native mobile appStanding dutyKeep current

    The rule that a public-facing service works properly on a phone, and that choosing a downloadable app over a responsive web page has to be justified.

    Re-tested as devices, browsers and operating systems change.

    Applies when Every public-facing website and web application.

  • Proactive publicationFilingKeep current

    Publication that happens without anyone asking, as a statutory duty.

    Amendments and renewals are published on the same cycle.

    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.

  • Benefits realization plan and project close-out reportSubmissionKeep currentsource

    The written statement of what good this project is supposed to do, and the later report confirming what was actually delivered and whether the promised benefits arrived.

    Whether the promised benefits actually arrived is tracked after the project is over.

    Applies above Universal for anything that counts as a project under the projects and programmes directive, with no dollar trigger. Baseline reporting to the Office of the Comptroller General starts at $25 million.

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.