Since June, the question I get from board members and CISOs at Canadian banks, energy operators and telecoms has changed. It used to be "Is the new federal cyber law actually going to pass?" Now it is "It passed. Are we on the clock?"
It's a fair question, and the answer is not yet. The legislation has had a long life. It started as Bill C-26 in June 2022, was amended by the Senate in December 2024, and died on the Order Paper when Parliament was prorogued on January 6, 2025. The government re-introduced it as Bill C-8 in June 2025. It received Royal Assent on June 15, 2026, as S.C. 2026, c. 9.
So it is law. But the part that matters most to critical infrastructure operators, the Critical Cyber Systems Protection Act (CCSPA), enacted by Bill C-8, is not yet in force. It comes into force on a day fixed by order in council, and as I write this in October 2026 that order has not been made. No regulations have been published, in draft or final form. The schedule that will list the designated classes of operators is still empty. Nobody has been designated, so nobody's 90-day clock has started.
I understand the temptation to wait for the order. I want to make the case for the opposite.
What the act actually does
Strip away the parliamentary history and Bill C-8 is two things joined together. Part 1 amends the Telecommunications Act to give the government security powers over telecom providers, including the power to order them to stop using specified products and services. That part is already in force. Part 2 is the one that matters for most of the organizations I work with: the CCSPA.
The CCSPA creates a federal, cross-sector, legally binding cyber security regime for critical infrastructure. Schedule 1 of the act names six vital services and systems:
- Telecommunications services.
- Interprovincial or international pipeline and power line systems.
- Nuclear energy systems.
- Federally regulated transportation systems.
- Banking systems.
- Clearing and settlement systems.
The obligations attach once the government designates a class of operators and lists it in Schedule 2. If you are in a designated class, the obligations are not vague:
- Establish a cyber security program within 90 days, then review it every year.
- Mitigate cyber risks arising from your supply chain and your use of third-party products and services.
- Report cyber security incidents to the Communications Security Establishment within the period set by regulation, which can be no more than 72 hours, and give your regulator a copy.
- Notify your regulator of material changes in your ownership, control, supply chain or use of third parties.
- Comply with any cyber security direction you receive, without disclosing it, and keep the records the act requires.
Non-compliance carries administrative monetary penalties. The act also creates offences. Directors and officers who direct or take part in an offence can be liable as parties, and individuals can face imprisonment.
One more provision changes how you have to think about resilience. The government can issue cyber security directions to designated operators, and you may be barred from disclosing a direction, or even that you received one. That raises fair questions about transparency, and I expect the debate to continue. Operationally, the lesson is simpler. You may one day be ordered to act fast and quietly, and you had better have the muscle to do it.
Why 90 days is shorter than it sounds
Here's the trap I watch organizations walk into. They read "90 days to establish a cyber security program" and they think: that's three months, we'll deal with it when the order comes.
I have spent 18 years in incident response, and Mjolnir has run 600+ engagements since 2017. Ninety days is not enough time to build a credible program from a standing start. It is barely enough time to document one you've already built. The work that actually consumes the clock, inventorying your critical systems, mapping your third-party dependencies, standing up incident detection and reporting workflows, writing and testing response playbooks, takes far longer than three months when you're starting cold.
The 90-day clock isn't time to build. It's time to prove. And you can't prove something that doesn't exist yet.
The supply chain is where I'd start
If I were advising an operator in a Schedule 1 sector today and could only push on one thing, it would be third-party risk.
The CCSPA puts supply chain risk at the centre of the regime. It requires you to mitigate it, and to tell your regulator when your supply chain materially changes. That is not an accident. The pattern I see across DFIR engagements is consistent: the breach rarely starts with the regulated institution itself. It starts with a vendor, a managed service provider, a cloud platform or a software supplier with weaker controls and trusted access. A single soft third party can become a threat to an entire operation.
For Canadian financial institutions, this should sound familiar, because OSFI got here first. Guideline B-13 on technology and cyber risk management took effect on January 1, 2024, and the updated Guideline B-10 on third-party risk took effect on May 1, 2024. If you're a federally regulated financial institution and you've done the B-13 and B-10 work properly, you have a real head start on the CCSPA. The frameworks rhyme.
If you haven't done that work, or if you're in energy, transport or telecom and don't have an OSFI-style regulator pushing you, this is the gap to close first.
You don't need to wait for the regulations
A common and understandable objection: the act doesn't prescribe a specific framework, and the regulations that will set the reporting window and other details have not been published. So how can anyone prepare for rules that don't exist yet?
The answer is that the core obligations are already written into the statute, and they map cleanly onto frameworks that already exist. NIST CSF 2.0 is a natural fit. Its six functions, including the Govern function covering supply chain risk, oversight and continuous improvement, line up well with what the CCSPA asks for. The point isn't which framework you pick. The point is that you pick one and implement it consistently, so that when the regulations land you're refining a working program instead of inventing one.
The roadmap I'd put in front of any operator right now is unglamorous and effective:
- Inventory every system that could affect a vital service if compromised. You cannot protect what you can't see.
- Map your third parties and assess each one in proportion to the risk it carries.
- Stand up incident detection and a reporting workflow that can meet a window of no more than 72 hours, and actually test that you can hit it.
- Run the self-assessment against NIST CSF 2.0, function by function, and close the obvious gaps.
- Write and exercise your playbooks. A plan you've never rehearsed is a document, not a capability.
None of this requires an order in council. All of it makes you better tomorrow, whenever the act comes into force.
The real reason to move
I'll be honest about why I keep pushing clients on this, and it isn't the penalties.
The threat actors aren't waiting for the CCSPA to come into force. The ransomware crews, the access brokers, the state-aligned groups probing Canadian infrastructure, they are operating on their timeline, not Ottawa's. The act is Canada finally writing down a baseline that serious operators should already be meeting. Treating it as a compliance deadline to be met at the last possible moment misses the point entirely.
The organizations that come through the next few years well won't be the ones with the fewest incidents. Everyone has incidents. They'll be the ones who can detect fast, respond cleanly, recover quickly, and prove they did.
That's a capability you build over quarters, not in a 90-day scramble after a designation order lands.
The clock hasn't started. Start anyway.
