The 2026 Guide
Index

Security

Security runs through the whole life of a service, from the first design sketch to the day it is turned off. A service that was safe at launch drifts out of date as the threats around it change and its software ages, so security is work that never quite stops. The same five questions come round again and again: what is at risk, how do we defend it, how do we spot trouble, how do we contain it, and how do we recover. Those five make up the security lifecycle.

THE SECURITY LIFECYCLE: Identify, know what is at risk; Protect, build the defenses; Detect, spot trouble fast; Respond, contain it; Recover, restore and learn.

These are the five functions of the recognizable security lifecycle, the model the Government of Canada works in: Canada's ITSG-33 sets out the GC IT-security risk-management lifecycle, the Canadian Centre for Cyber Security publishes the guidance under it, and the same five functions are the international frame of the NIST Cybersecurity Framework.

What good looks like

  • Security is planned and funded from the start, with the risks worked out before any code is written.

  • Access follows least privilege, meaning each person and system gets only the access they need, and that access is audited.

  • Patches are applied on a schedule and the application is tested for vulnerabilities on a regular basis.

  • Monitoring and alerting flag unusual activity, because you cannot prevent everything and what counts is how fast you notice.

  • An incident response plan exists and has been rehearsed, so a problem is contained quickly rather than weeks later.

  • The service can be brought back after an incident, and the lesson is fed back into the design.

  • The service's security maturity level is known, with a clear next step to improve it.

  • Third-party components, the open-source and bought libraries the service is built on, are inventoried and watched for known problems.

Why it matters

When security fails, a service can go offline or leak people's personal information, and public trust is slow to rebuild. The most common causes are mundane: an unpatched component, a default password, a permission left too wide. Each of the five functions is a guard against a different failure, and the cycle only holds if none of them is skipped. Catching a flaw early also costs less, because one designed in and found late is the most expensive kind to undo. The Government of Canada's guide for all of this is the Guideline on Secure Application Development, which covers building security into each stage of development, secure coding, handling third-party components, and managing vulnerabilities. It is where the team goes for the how-to.

Whose job it is

Security is shared across the team, with each role holding a different part:

  • Developers write secure code and fix what the scans find.
  • Security specialists decide which threats to defend against and review the design.
  • Operations run and monitor the service once it is live.
  • The business owner of the application makes sure security is planned and paid for from the start, approves the plan for handling threats, accepts the risk that remains after the fixes, and gives the deploy go-ahead (the formal approval that lets a service go live).

A closer look

  1. 1Identify
  2. 2Protect
  3. 3Detect
  4. 4Respond
  5. 5Recover

Comparison

Two ways to do security

Pax

Meet Pax, a service manager. They built security into the grant portal from the design:

  • built a threat model to set out what could go wrong, and chose secure defaults
  • gave each person and system only the access they needed, and audited it
  • patched on a schedule and watched the third-party components for known problems
  • kept a rehearsed incident response plan

The result: when a phishing attempt came, it was caught and contained quickly, and the data stayed safe.

What Security looks like in each phase

The five functions are present throughout, but their weight shifts across the life of a service.

This is where Identify and Protect are designed in, before any code is written. The team builds a threat model to set out what could go wrong and who might attack the service (the threat model itself lives in the Identify block of "A closer look").

The team then chooses secure defaults so the safe option is the default one, and sets how the service will handle identity and access. Security requirements are written into the contract so the supplier is held to them. A weakness fixed at the design stage costs far less than one found in production.

The official instruments behind security

Everything official this subject brings with it, and where in a service's life each one comes up. The full detail, including who does the work and what the business owner personally does, is in the table on the home page.

  • Security categorizationEvery servicesourceAssessment

    A rating of how much injury would result if the service's information leaked, if someone altered it, or if the service became unavailable. The three are judged separately, on four levels from low to very high, and the result decides the size of the security control set the build has to meet.

    • DiscoveryGather
    • AlphaFill
    • GrowthKeep current
    • MaturityKeep current
  • Threat and risk assessment (TRA)Every servicesourceAssessment

    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. By doctrine it covers deliberate, accidental and natural threats alike, so it is not a cybersecurity-only exercise, though in practice the information technology one runs narrower because natural hazards are routed into continuity instead.

    • AlphaGatherFill
    • BetaFill
    • GrowthKeep current
    • MaturityKeep current
  • Physical security assessment and Authority to Occupy Facility (ATOF)Only ifAuthorization

    The second, parallel security track, for buildings, equipment and physical space rather than systems. It uses the same harmonized method, run by different people, ending in a different signature.

    • AlphaCheck
    • BetaFillSign or accept
  • Security assessment and authorization, ending in the Authority to Operate (SA&A, ATO)Every servicesourceAuthorization

    The formal permission for the service to run. Someone with the authority reads what the security work found, accepts the risk that is left, and signs. For a departmental system that signer is normally the program or service delivery manager, which is to say the business owner.

    • DiscoveryGatherSign or accept
    • AlphaSign or accept
    • BetaSign or accept
    • GrowthKeep currentSign or accept
    • MaturityKeep current
    • SunsetClose out
  • Business impact analysis (BIA)Every serviceAssessment

    The exercise that works out who is harmed if the service stops, how quickly that harm becomes serious, and what the service depends on. Its outputs are the criticality judgement and four numbers: maximum allowable downtime, minimum service level, recovery time objective and recovery point objective.

    • AlphaGather
    • BetaGather
    • StabilizationKeep current
    • GrowthKeep current
    • MaturityKeep current
  • Business continuity plan (BCP)Only ifPlan

    The written arrangements for keeping a critical service delivering at a minimum acceptable level during a disruption, and recovering it afterwards. There is one plan for the department. A critical service may have its own, sit inside a broader one, or be supported by several.

    • BetaGather
    • StabilizationKeep current
    • MaturityKeep current
  • Information technology continuity managementEvery servicesourcePlan

    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. This is the part the team owns, as distinct from the departmental business continuity plan, which is the department's.

    • BetaFill
    • StabilizationKeep current
    • MaturityKeep current
  • Cyber security event response and reportingEvery servicesourcePlan

    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. The government-wide plan sets who is told, in what order, and how an event escalates into a coordinated response.

    • BetaFill
    • StabilizationKeep current
    • GrowthKeep current
    • MaturityKeep current
  • Material privacy breach reportOnly ifFiling

    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. It goes to the Office of the Privacy Commissioner of Canada and to the Treasury Board of Canada Secretariat, and affected people are notified.

    • BetaCheck
    • StabilizationSubmit
    • GrowthKeep current
  • Security Requirements Check List (SRCL, form TBS/SCT 350-103)Only ifSubmission

    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. It is what turns a vague sense that a contract is sensitive into the clauses that actually go into the solicitation.

    • DiscoveryCheck
    • AlphaFill
    • BetaSign or acceptSubmit
    • GrowthKeep current
    • MaturityKeep current
    • SunsetKeep current
  • Supplier organization and personnel security screeningOnly ifAuthorization

    The clearances a company and its individual staff must hold before touching sensitive government work. Departments do not clear suppliers themselves; a single federal program does it, and confirms in writing that a supplier may be awarded the work.

    • AlphaCheck
    • BetaGatherSign or accept
    • GrowthKeep current
    • MaturityKeep current
  • Cloud security profile, guardrails, and the cloud authorizationOnly ifAuthorization

    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.

    • AlphaCheckGather
    • BetaFillSign or accept
    • GrowthKeep current
    • MaturityKeep current
  • Identity and credential assurance levelsOnly ifAssessment

    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. They are set from the harm that would result from getting it wrong, and they decide what the sign-in has to do, so they constrain the design from the beginning.

    • DiscoveryCheck
    • AlphaGatherFill
    • GrowthKeep current

Further reading

Security in the Government of Canada comes under the Policy on Government Security, and under its Directive on Security Management, which requires security to be managed across a system's whole life. The department gathers all of it into a departmental security plan, a three-year plan reviewed every year and approved by the deputy head, and a service's security posture, its residual risks and its continuity requirements all roll up into that plan. Its closest companion is the Guideline on Secure Application Development, on the GC network, which this thread leans on throughout. It also draws on ITSG-33 for the GC control catalogue, and the open OWASP Top 10 and NIST Secure Software Development Framework, translated to a business owner's decisions. To see where your spending buys down the most risk, the Cyber Centre's top 10 IT security actions ranks the defences that matter most, and its baseline controls for small and medium organizations is a plainer starting point for a smaller service. For the case that security is cheapest when designed in rather than bolted on, the US Cyber Defense Agency's secure-by-design principles make the argument in a business owner's terms.

See also

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.