Bill C-26 and the CCSPA: Critical Cyber Systems Obligations for Telecom, Finance and Energy

The Critical Cyber Systems Protection Act has stopped being a bill people argue about and become a statute designated operators have to comply with. If you run critical infrastructure in Canada, the informal security posture you assembled over the years is no longer the thing a regulator will accept.

The CCSPA is the framework that first appeared as Bill C-26 in 2022. That bill died when Parliament was prorogued. The government reintroduced it, materially unchanged in structure, as Bill C-8, which received royal assent on 16 June 2026. So when people still say “Bill C-26”, they mean the regime that is now law. This is a reading of what it demands of a technology function, for the people who will own the programme and answer for the reporting.

Law now, obligations on a phased clock

Royal assent is not the moment every duty switches on. The Telecommunications Act amendments took effect immediately, but the CCSPA itself comes into force on a phased basis by order of the Governor in Council, and much of the operational detail — which operators are designated, the precise reporting window, the content of a compliant programme — sits in regulations still to be finalised. That is not a reason to wait. The Act sets the obligations; the regulations set the parameters. The parameters can move; the obligations will not. Once your organisation is named as a designated operator a clock starts, and the work you should have done in the quiet period becomes work you are doing under a deadline.

Free · 4 minutes

Would you survive contact with a determined attacker — or an auditor?

Fourteen questions on access, patching, detection, and recovery — the basics that prevent most real incidents, and the ones most often assumed rather than verified. Banded finding on screen, full sheet by email.

Who gets designated, and by whom

The CCSPA works through classes of vital service and vital system, each with its own regulator. If you operate one of these, you are in scope:

  • Telecommunications services — overseen by the Minister of Industry.
  • Banking — the Office of the Superintendent of Financial Institutions.
  • Clearing and settlement systems — the Bank of Canada.
  • Interprovincial and international pipelines and power lines — the Canadian Energy Regulator.
  • Nuclear energy systems — the Canadian Nuclear Safety Commission.
  • Federally regulated transportation — the Minister of Transport.

The consequence of that structure is worth naming plainly. There is no single cyber regulator. A bank answers to OSFI; a pipeline operator answers to the Canadian Energy Regulator; a payments infrastructure answers to the Bank of Canada. Firms that span sectors will answer to more than one. This is a different model from a centralised designation authority, and closer in shape to the sectoral designation regimes appearing elsewhere — the critical information infrastructure obligations under Singapore’s Cybersecurity Act follow a comparable logic. If you are a multi-jurisdiction operator, map which of your Canadian entities falls into which class before designation forces the question.

The cyber security programme is an evidence obligation

Once designated, an operator must establish a cyber security programme — the Act’s term is exactly that — within a fixed period, expected to be 90 days from designation. The programme is not a policy binder. It has to address, at a minimum, five things: identifying and managing cyber risks including supply-chain and third-party risks; protecting critical cyber systems from compromise; detecting cyber security incidents; minimising the impact of incidents; and any further matter prescribed by regulation. It must be reviewed, and the review is not optional or occasional.

The word that matters for the technology function is “demonstrable”. You must maintain records of your cyber security activities and make them available for inspection. A programme that exists as an intention, or as controls nobody can evidence on the day a regulator asks, is not a programme for CCSPA purposes. Build it so every element produces an artefact: the risk register showing the taxonomy, the asset inventory that defines what a “critical cyber system” actually is in your estate, the detection coverage map, the review minutes. If you cannot produce those on demand, you have a security operation, not a compliant programme.

The 72-hour clock and what your pipeline has to produce

Designated operators must report cyber security incidents to the Communications Security Establishment — in practice through the Canadian Centre for Cyber Security — within 72 hours, with the exact window set by regulation. The reporting threshold is deliberately wide: an incident that interferes, or may interfere, with the continuity or security of a vital service or vital system. “May interfere” is the phrase that will cause the arguments. It pulls in events you would not classify as breaches in a purely security-led model, and it forces a materiality judgement inside a tight window.

That is an engineering requirement before it is a compliance one. To report within 72 hours you have to detect within hours, triage against a defined threshold, and assemble enough of a factual picture — which systems, when, what effect — to file something a regulator will accept. Reporting to CSE does not discharge your duty to your sector regulator; expect to notify both. If your telemetry cannot reconstruct an incident’s timeline, or your on-call process cannot escalate a “may interfere” event quickly, the 72-hour clock is what exposes the gap. The obligation is similar in shape to the reporting duties in the UK Cyber Security and Resilience Bill, and the same lesson applies: the window is short enough that the pipeline has to be built and rehearsed in advance, not improvised during the first real incident.

Third-party risk is a standing duty

Supply-chain and third-party risk is not a section of the annual review. The Act singles it out: where such a risk is identified, the operator must take reasonable steps to mitigate it. “As soon as identified” is a continuous obligation, not a periodic one. In practice that means your programme has to know what your critical cyber systems actually depend on — the managed service providers, the software suppliers, the identity providers, the smaller vendors that never make it onto the risk committee’s radar — and has to have a route to act when one of them becomes a problem. This is the part most operators underestimate, because the dependency map is usually incomplete and the mitigation route is usually undefined.

Directions you cannot argue about in advance

The CCSPA lets the government issue binding cyber security directions to operators — compelling specific measures, in some cases without disclosing the intelligence behind them. An operator’s recourse is judicial review in the Federal Court, after the fact, not negotiation before it. Layered on top is a penalty regime: administrative monetary penalties reaching up to CA$15 million per violation for organisations and up to CA$1 million for individuals, with each day of a continuing contravention capable of being treated as a separate violation, plus personal exposure for directors and officers who acquiesce in non-compliance. These are maxima set by the Act; applied figures will follow the regulations and enforcement practice. The point is not the ceiling. It is that the regime is built to make demonstrable compliance cheaper than the alternative.

The mistake to avoid is treating designation as the starting gun. By the time you are designated, the 90-day programme clock and the 72-hour reporting duty are already running, and neither rewards a standing start. The work that survives a supervisory conversation — the documented programme, the tested reporting pipeline, the dependency map, the records ready for inspection — is the work done before the regulator names you.

Sixteen Pillars reads critical-infrastructure cyber obligations for the boards and technology functions that have to own them — mapping designation exposure, testing whether the reporting pipeline can actually produce a filing inside the window, and writing down what is missing. Pricing is published at /pricing/. If the CCSPA is live for your organisation and you want an independent reading before designation forces the pace, the place to start is a conversation.

Sixteen Pillars is a technology governance consultancy based in Cyprus. Engagements run remote across the EU, UK, and Middle East, with on-site time where the engagement requires it.

Free interactive tool

Website compliance checklist

What your site has to do, based on what it actually does

Answer as much or as little as you like — the list builds as you go. Nothing is stored against your name and no email is required.

Free interactive tool

Interactive deadline calculator

Check which regulations apply to you and when

Regulation across the EU, UK, US and Asia-Pacific has moved considerably in the past eighteen months, and several headline dates have shifted more than once. Twelve questions, about three minutes.

Results are shown on screen — no email required. A dated summary is available to download, and can be sent on if that's more useful. What we do with your answers.

Most technology problems are not technology problems. They are control problems.

The systems exist. The investment has been made. The question is whether leadership can understand, direct, evidence, and sustain what those systems produce. Find out where control exists — and where it only appears to.

Full Governance by Sixteen Pillars

Govern your business. Prove your compliance.

A board assurance cockpit for EU-regulated financial firms — tamper-evident, hash-chained proof of governance across DORA, GDPR, NIS2, ISO 27001, the EU AI Act and MiCA. In development.

See what's coming