x3 Cybersecurity tips for projects already in flight

October 2026 is Cyber Security Awareness Month, which brings familiar reminders: use strong passwords, turn on multi-factor authentication, keep software patched and don’t click suspicious links.

All good advice. Make sure you take action!

However, that advice doesn't address many of the cyber security risks created by technology projects already in flight. Some of the biggest risks come from decisions made when businesses choose technology, design how systems will work together, configure environments, build integrations, decide who gets access, test the solution and, ultimately, decide whether it is ready to go live.

So perhaps we need to stop treating cyber security as something for IT to deal with and make it a project problem.

https://youtu.be/jeLSGQOfb0Q

Going live shouldn't be a default decision

Early in my career I saw big projects pass stage gates and continue towards go-live unless somebody was brave enough to put their hand up and argue there was a good enough reason to stop.

By that stage, there is momentum behind the date. Users have been told. Vendors are lined up. Cutover plans are in place. Everyone wants to get the project over the line.

That can make anyone raising security concerns pretty unpopular. Worse, they can quickly be viewed as a roadblock that needs to be cleared. I think we should turn that around.

Instead of asking: “Is there anything stopping us from going live?” Let's ask: “What evidence do we have that we're ready to go live?”

That puts responsibility back where it belongs: with the project team.

The project should be able to demonstrate that the solution has been appropriately designed and reviewed. That testing has provided sufficient assurance. That security findings have been addressed, mitigated or consciously accepted. And that the people, processes and controls needed to operate the system are ready.

The second most expensive time to discover a security problem is just before go-live

The most expensive time is afterwards!

Leaving security assurance until the end of a project creates unnecessary risk. Discovering a significant security issue late in a project leaves you with some unpleasant choices: delay go-live, make changes under pressure, introduce additional controls, or accept a level of risk the organisation may not be comfortable with.

A better approach is to build cyber security assurance into the project's delivery plan. Consider security requirements before detailed design. Review the solution before you're too far into the build. Harden systems and environments from the beginning. Test those controls and track findings alongside the project's other risks and issues. Retest where necessary. Rehearse to prove the operational arrangements are actually ready.

Then security isn't brought in at the end while everyone holds their breath wondering what severity the next issue will be. Security assurance becomes part of the evidence the project produces to demonstrate that it should go live.

Cyber security shouldn’t be an IT problem.

Make security a Project problem.

We recently led an organisation through the design, development and implementation of a brand-new platform, and saw this approach work in practice. From the beginning, the Board made it clear that it wasn't enough to finish the build, complete user testing and switch it on. Security was a primary objective, and providing assurance became a central part of demonstrating that the platform was ready to go live.

That included security hardening, an independent security architecture review, and a formal Certification and Accreditation (C&A) audit process.

Each provided a different layer of assurance for management, the executive team and the Board:

1. Hardening focused on making sure the systems and environments were appropriately configured and secured.

2. The architecture review challenged the overall solution, including the systems, integrations and security controls involved.

3. The C&A process provided a formal assessment of whether the platform and the controls around it were appropriate and ready to enter production.

The project needed to demonstrate that the design, testing and management arrangements were adequately prepared to support the system once it went live. After going through such a rigorous assurance process, I firmly believe that's where the burden of proof should sit.

Make the project prove it

Having recently been through this process, there's one principle I'll take into the next technology project I work on: Make the project prove it's ready.

The project should be able to demonstrate that the solution has been appropriately designed, tested, secured and prepared for operation. That's ultimately what good assurance gives management, executives and Boards: evidence on which to make a decision.

So, this Cyber Security Awareness Month, by all means change your password, check your MFA and think twice before clicking that link. But if you're running a technology project, go a step further. Make cyber security a project problem. And make the project prove it's ready!