The final post in STEP Software’s October Cybersecurity Awareness Month series

Nothing says Halloween quite like discovering something dangerous has been lurking in your systems for years.

Unfortunately, this year’s real-world cybersecurity horror story is not fiction. It is PHP, one of the internet’s most widely used programming languages, and a reminder that even familiar, dependable technology can harbour serious vulnerabilities.

On October 21, 2026, the PHP development team released security updates addressing two critical vulnerabilities that could allow attackers to execute code remotely without authentication. Both received a CVSS v4.0 severity score of 9.2. The flaws affect PHP installations serving web requests, with the PHP team identifying particular risk in certain server configurations.

The official PHP security announcement urges users to update immediately. The Canadian Centre for Cyber Security’s advisory also directs administrators to review the issue and apply necessary updates.

And yes, government websites in Europe were reportedly taken offline as operators responded to the threat, according to Reuters.

That is a rather unpleasant Halloween trick.

The Vulnerability Lurking Beneath the Surface

PHP powers websites, content management systems and business applications across the internet. It is used in platforms including WordPress, Drupal, Joomla and Magento.

The problem is not that PHP is inherently insecure. Like any software, it needs maintenance, security updates and responsible configuration.

The latest incident involves two serious flaws in PHP’s internal memory and request-handling processes. According to the official PHP advisory, one involves memory corruption during an out-of-memory condition, while the other involves stale internal state that can persist after memory has been freed.

In practical terms, these vulnerabilities could allow an attacker to execute code on an affected server without first logging in.

That could put application data, connected systems and business operations at risk.

The wider lesson is important: a vulnerability in a shared software component can become a business problem for every organization relying on it.

You might have a modern website, a well-designed application and sensible security policies. But if the underlying runtime is vulnerable, those other precautions may not be enough.

Your PHP Application Might Be Older Than Your Security Plan

Here is where the Halloween metaphor gets uncomfortably realistic.

Many organizations do not have a complete inventory of the software running their business. They know about their main website, their customer portal and the applications their IT team actively maintains.

But what about:

• The forgotten application-built years ago?
• The internal reporting tool?
• The customer-facing portal maintained by a third party?
• The custom application that still works beautifully, provided nobody touches the code?

These systems can become cybersecurity blind spots.

Common warning signs include:

• Unsupported PHP versions: Older releases may no longer receive security fixes from the PHP project.
• Unmaintained dependencies: Libraries and frameworks can introduce vulnerabilities even when the application itself has not changed.
• Incomplete documentation: Your team may not know which components are installed, who owns them or how to update them safely.
• Unclear vendor responsibilities: Everyone assumes someone else is monitoring vulnerabilities and applying patches.
• Limited testing capacity: Teams postpone updates because they cannot confidently predict what an upgrade might break.

PHP’s official guidance notes that PHP 8.1 and older no longer receive updates from the project, although some distributions and long-term support vendors may provide backported fixes. Organizations must verify their actual support arrangements rather than assume an older installation is protected.

The official PHP security release information is the place to start.

What Should Businesses Do Right Now?

If your organization uses PHP, do not wait for the next routine maintenance window to find out whether you are affected.

Start with these five steps:

1. Identify your exposure. Inventory PHP applications, versions, hosting environments and dependencies. Include business-critical custom software and applications managed by external vendors.
2. Confirm the fix. Review the PHP security announcement and your operating system or hosting provider’s security guidance. The PHP team lists fixed releases including PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Confirm the correct package and supported upgrade path for your environment.
3. Prioritize internet-facing systems. Assess exposure, business criticality and the potential consequences of compromise. If immediate patching is not possible, follow authoritative security guidance on restricting access or temporarily isolating affected systems.
4. Test and verify. Apply the update, restart the relevant services where required, and confirm that the installed runtime is patched. Test critical application workflows and review logs for suspicious activity.
5. Review the wider application. Patching the runtime is essential, but it does not automatically resolve outdated dependencies, insecure application logic, excessive permissions or other weaknesses.

Do not assume that updating WordPress or another content management system automatically updates the PHP runtime underneath it. These are separate components, and responsibility for updating them depends on your hosting and deployment arrangements.

When the Fix Is More Complicated Than the Patch

For some organizations, updating PHP is straightforward. For others, it opens a rather large skeleton-filled closet.

An older application may depend on a PHP version that is no longer supported. An upgrade might affect database connections, integrations, libraries or business-critical workflows. Documentation may be incomplete, and the original developers may have moved on.

Simply applying an update without understanding those dependencies can introduce operational problems. Doing nothing leaves the organization exposed.

This is where STEP Software can help.

Our Legacy Software Division helps organizations stabilize, maintain and modernize existing applications. Our Advisory Division can help assess software risks, review code and establish practical remediation priorities.

Depending on the application, the next step may involve:

• A software audit to identify vulnerabilities, unsupported components and technical debt.
• Targeted remediation and testing to help make a PHP upgrade safer.
• Additional specialist capacity through staff augmentation when internal teams are already stretched.
• A longer-term modernization plan that reduces risk without automatically requiring a complete replacement.

Our approach is practical: understand the system, establish priorities and determine the safest route forward. Sometimes that means modernizing. Sometimes it means stabilizing a system that still delivers real business value.

Either way, the objective is to replace uncertainty with an actionable plan.

The Final Scare: Thinking the Job Is Done

This October, STEP Software has explored cybersecurity health checks, software supply chain risks and cybersecurity debt. The PHP vulnerabilities bring those themes together.

A critical flaw can emerge in software that organizations have trusted for years. A third-party dependency can become a serious exposure. An application nobody has reviewed recently can suddenly demand urgent attention.

Security is not a one-time project, and passing an audit last year does not guarantee protection today.

Organizations need an ongoing process for tracking software assets, monitoring advisories, maintaining dependencies, testing updates and assigning responsibility. Our article on the questions to ask your software vendor before signing is a useful place to strengthen that conversation.

For further guidance on protecting your organization, visit Canada’s Get Cyber Safe resources.

No Tricks. Just Better Software Security.

Halloween is a fine time for ghosts, ghouls and things that go bump in the night.

It is not a great time to discover that your business-critical application has been running vulnerable software for months.

If your organization uses PHP, check your exposure and act on the current security guidance. Then take a closer look at the legacy applications, dependencies and vendor arrangements that could create your next cybersecurity surprise.

Need help understanding the condition of your software or planning your next steps? Talk to STEP Software.

Because the scariest vulnerability is not always the one nobody has fixed.

Sometimes, it is the one nobody knew was there.

The post PHP – It’s Scary! first appeared on STEP Software.

If you lead an IT team, this conversation probably feels familiar.

You have unsupported software that needs attention, dependencies that have not been reviewed, legacy applications that nobody wants to touch, and security findings that keep getting pushed to next quarter. Your team knows these issues will not resolve themselves but when budget season arrives, the pushback begins.

Cybersecurity debt can be difficult to explain to people who see only the cost of fixing it, not the risks associated with leaving it to grow.

October’s Cyber Security Awareness Month is a good time to alter that conversation. With 2027 budget planning well underway, the objective now is not to convince leadership to spend more on security simply because the threats are growing. It is to show them which risks the business is carrying, what those risks could cost left unaddressed, and what a realistic plan to reduce them looks like.

Cybersecurity Debt is Already on Your Balance Sheet

Cybersecurity debt accumulates when vulnerabilities, outdated dependencies, weak access controls, undocumented integrations and other security weaknesses remain unresolved.

Some of this debt is visible in vulnerability reports. Some sits in legacy applications that have not been independently assessed in years. Some exists because a third-party vendor changed a component, a developer left, or an application became too complicated for your current team to maintain confidently.

The problem is not that every outstanding issue represents an imminent breach. The problem is that you cannot prioritize risk effectively if you do not know its extent, ownership or business impact.

This is where cybersecurity debt differs from a conventional maintenance backlog. A delayed feature might inconvenience users. An unresolved security weakness could expose customer information, interrupt operations or create a route into other connected systems.

STEP Software has explored the related challenge of technical debt and its impact on IT teams, budgets and modernization. Cybersecurity debt adds another dimension: the longer you postpone understanding and addressing certain weaknesses, the less control you may have over when they demand attention.

The Financial Case Is Getting Harder to Ignore

According to IBM’s 2026 Cost of a Data Breach Report, the average cost of a data breach in Canada reached CA$7.11 million, a record high in the study. The average breach involved approximately 28,500 compromised records and took 205 days to detect and contain.

These figures represent the study’s average, not a prediction of what a breach would cost your organization. However, they demonstrate the financial scale of the problem.

The Verizon 2026 Data Breach Investigations Report found that exploitation of software vulnerabilities accounted for 31% of breaches, making it the leading initial access method in the report.

For technical leaders, the budget implication is straightforward. If known weaknesses remain unresolved because teams lack time, expertise or funding, the organization is effectively accepting risk without necessarily measuring it.

That is a difficult position to defend when something goes wrong. It is also an opportunity to make a more compelling case before it does.

Stop Asking for a Bigger Security Budget, Start Showing What It Will Buy

A request for additional cybersecurity funding becomes much easier to evaluate when it is connected to specific outcomes.

Instead of asking for a general increase in security spending, build your 2027 proposal around three priorities:

1. Find Out What You Are Carrying

Fund an independent assessment of business-critical applications, particularly legacy and custom software where documentation is incomplete, or ownership is unclear. Establish which vulnerabilities, dependencies and architectural weaknesses deserve attention.

STEP’s software audit services can help identify security concerns, outdated components, maintainability issues and technical debt. The result should be a prioritized view of the work, not simply another list of problems.

2. Put a Price on Remediation

Separate urgent fixes from work that can be scheduled. Estimate the effort, cost, dependencies and business impact of addressing each priority. Identify risks that require immediate action and those that can be managed through planned maintenance.

This gives finance leaders something concrete to evaluate what that investment addresses, what the organization will spend, and what exposure remains if the work is deferred.

3. Fund Prevention, Not Just Cleanup

Include ongoing vulnerability management, software maintenance, documentation, dependency reviews and security testing in the operating budget. Otherwise, today’s remediation project can become next year’s backlog.

Track measures such as the age of unresolved critical vulnerabilities, time to remediate, unsupported components and the percentage of critical applications with current security assessments. These indicators help demonstrate progress and explain future funding requirements.

Your Vendors Can Add to the Debt or Help You Pay It Down

Third-party software development and support can be part of the solution, but outsourcing does not automatically reduce risk.

A vendor that delivers poorly documented code, introduces unnecessary dependencies or leaves security responsibilities unclear can create more work for an already stretched IT team.

The right partner can provide specialist expertise, independent assessment and additional capacity to address a backlog without requiring permanent headcount increases.

NIST’s Cybersecurity Supply Chain Risk Management guidance emphasizes assessing suppliers and communicating cybersecurity expectations throughout the supply chain.

For 2027 planning, review whether your vendors can help you reduce measurable risk. Ask how they manage vulnerabilities, document dependencies, test code and support applications after deployment.

STEP’s Advisory Division offers guidance on software assessments, code reviews and practical action planning while our Legacy Software Division helps organizations stabilize, maintain and modernize existing applications. This unique combination of skills offers clients options to modernize without a full rip and replace.

Staff Augmentation support can be particularly valuable when the expertise required to resolve a security issue is not available internally, or when the internal team is already committed to keeping critical systems running. It is also a budget conscious method of keeping systems secure while ensuring your modernization efforts don’t lose focus.

Make Your 2027 Budget a Risk Decision

Cyber Security Awareness Month reminds us that security is everyone’s responsibility. For IT leaders, that includes making sure the business understands the risks embedded in its own technology.

You do not need to eliminate every vulnerability or modernize every legacy system in 2027. But you do need a defensible plan that identifies the most important risks, assigns ownership, funds the right interventions and measures whether the backlog is shrinking.

That’s a much stronger budget conversation than simply asking for money to improve cybersecurity.

At STEP Software, we help organizations understand the condition of their software and determine practical next steps, whether that means a security audit, targeted remediation, better documentation or a longer-term modernization plan.

Before your 2027 budget is finalized, ask yourself three questions:

• Do we know where our biggest cybersecurity debt sits?
• Can we explain the business consequences of leaving it unresolved?
• Do we have a funded plan to reduce it?

If the answer to any of these is no, the first investment may not be another security tool. It may be getting a clearer picture of the software you already own.

Because when you are asking leadership to fund risk reduction, evidence is a much stronger argument than fear.

Drop us a line if you need help answering any of these questions..

The post Cybersecurity Debt: Risks & Budget 2027 first appeared on STEP Software.

Cyber Security Awareness Month can sometimes feel like an annual reminder to change your password, turn on MFA and stop clicking suspicious links.

Those are still good ideas for the whole year, not just October.

But for IT professionals, cybersecurity has become a much bigger conversation.

Canada’s 2026 Cyber Security Awareness Month theme is “Your best defence is you.” This year week three focuses on protecting information, including information used when banking, shopping, and accessing online services. Get Cyber Safe is encouraging organizations to think about practical ways to protect information and strengthen cyber security habits.

For IT teams, there is another practical question worth asking:

“Do we really know everything our software is connected to?”

Because your software supply chain is probably much bigger than you think.

Your Application Is Not an Island

Modern business applications rarely exist on their own.

They may connect to:

• Open-source libraries and frameworks
• Third-party APIs
• Cloud services
• SaaS platforms
• Databases
• Payment processors
• Identity providers
• Customer portals
• Vendor systems
• Internal legacy applications
• Mobile applications
• Analytics platforms
• AI services

And somewhere underneath all of that may be a 15-year-old application that nobody wants to touch because, technically speaking, it still works.

Sound familiar?

The problem is not necessarily that any individual component is insecure. The problem is understanding the relationships between those components and knowing what happens when one of them develops a vulnerability.

NIST describes software supply chain security as involving practices such as software bills of materials, vendor risk assessments, open-source software controls and vulnerability management. Its 2026 guidance on cybersecurity supply chain risk management also emphasizes documenting systems, controls, responsibilities and the people who manage and access them.

In other words, cybersecurity is increasingly about understanding the ecosystem, not just protecting the perimeter.

Vulnerabilities Are Moving Faster

There is an incredibly good reason IT professionals should care about this now.

Last week we discussed Verizon’s 2026 Data Breach Investigations Report which found that 31% of breaches began with exploitation of software vulnerabilities, making it the leading initial breach entry point for the first time in the report’s history.

Even more concerning, Verizon reports that AI is helping attackers accelerate the process of identifying and exploiting vulnerabilities, potentially shrinking defensive windows from months to hours.

That changes the economics of “we will patch it when we get around to it.”

If your team does not know what software components are in your environment, which versions are running, which systems depend on them and who owns remediation, you may already be behind the clock.

The Legacy Software Problem

This is where things get particularly interesting.

Legacy software is not inherently insecure.

In fact, many legacy applications continue to run some of the most crucial functions inside an organization. STEP Software has written extensively about this because replacing a stable legacy system simply because it is old can be an expensive and unnecessary exercise.

The risk comes when an organization no longer understands the application well enough to manage it confidently.

Maybe the original developers have left.

Maybe the documentation is incomplete.

Maybe an old framework is still being used because changing it could break three other systems.

Maybe an API was added five years ago, and nobody remembers exactly why.

Maybe the application contains third-party components that have not been reviewed in years.

All those maybes are not just technical debt they are cybersecurity debt.

STEP’s software audit approach looks beyond a simple vulnerability scan. A comprehensive software audit can examine architecture, code quality, dependencies, security vulnerabilities, performance, documentation, licensing, and maintainability.

That broader view matters because fixing the wrong thing can be almost as frustrating as not fixing anything.

Do You Have a Software Ingredient List?

One increasingly useful tool in software supply chain security is the Software Bill of Materials, or SBOM.

Think of an SBOM as an ingredient list for software.

IBM explains that an SBOM provides information about the components and relationships that make up a software product, in a machine-readable format. This inventory helps organizations identify vulnerabilities and understand where those components came from.

This becomes particularly useful when a newly discovered vulnerability affects a widely used library.

Instead of asking:

“Do we use that?”

Instead, your team should be asking:

“Where do we use that, which applications are affected, who owns them and what version are they running?”

That’s a much better question.

Your Vendor Is Part of Your Security Strategy

The software supply chain also extends to the companies building, maintaining, and supporting your systems.

When was the last time you asked a software vendor:

“How do you manage vulnerabilities in your code?”

What about:

“How do you manage open-source dependencies?”

Or:

“What happens when a critical vulnerability is discovered in a component your application uses?”

None of these are unreasonable questions. In fact, are increasingly basic questions about software ownership and risk.

About this time last year we explored this very topic in 10 Cybersecurity Questions to Ask Your Software Vendor. We included questions about secure development practices, open-source components, security testing, incident response, documentation, and post-production support.

We see these answers as a business survival guide, and the right software partner should welcome these questions.

Sometimes the Problem Is Not the Software

Here’s the uncomfortable part, sometimes the software itself is not the biggest problem.

Sometimes the problem is that nobody has a complete picture of how it works.

That could mean missing documentation, undocumented integrations, unclear ownership, outdated dependencies, or an internal team that is stretched too thin to investigate the system properly.

STEP has previously discussed the connection between software documentation and cybersecurity, and how undocumented systems can create hidden attack surfaces and make incident response much harder.

Simply put, if nobody knows how something works, nobody can confidently secure it.

So, What Should IT Teams Do?

First, take a breath, we’ve got you!

You don’t need to rip out your legacy applications or replace every vendor. And you certainly do not need to launch a six-month modernization program because someone discovered an outdated version of Java.

Instead, start with visibility.

Ask:

1. What applications are business critical?
2. What systems and vendors do they connect to?
3. What third-party and open-source components do they depend on?
4. Who owns each application and its security risks?
5. When was the code last independently assessed?
6. What happens when a critical vulnerability is discovered?
7. Which systems have documentation, and which rely on institutional knowledge?

The answers may be reassuring; they may also reveal a few things worth investigating.

That is exactly what a good cybersecurity health check or software audit should do.

Cybersecurity Is Becoming a Software Conversation

October’s annual focus on cybersecurity awareness is a useful reminder that everyone has a role to play in protecting information. And for IT professionals, that responsibility increasingly extends into the software itself.

The applications your organization depends on are part of your security perimeter. The vendors who build them are part of your security ecosystem. The APIs and open-source components they depend on are part of your attack surface. And the legacy systems everyone hopes will quietly keep working for another five years? They are part of the conversation too.

At STEP Software, our Advisory Division helps organizations assess software, audit code, evaluate vendors and turn complicated technology problems into practical action plans. Our Legacy Software Division helps organizations stabilize, support, and modernize older systems without unnecessary disruption.

Because sometimes the first step toward better cybersecurity is not buying another security tool.

It is understanding what you already have.

Your Turn

IT professionals, what is the biggest blind spot you see in software supply chain security today?

Is it third-party vendors?

Open-source dependencies?

Legacy applications?

Documentation?

Or simply not knowing who owns the risk?

Drop us a line, let’s compare notes.

The post Your Software Supply Chain Is Bigger Than You Think first appeared on STEP Software.

October is Cyber Security Awareness Month, making it a good time for businesses to review more than passwords, phishing awareness and employee training.

It’s an excellent time to revisit your cybersecurity strategy and shine some light on the software your business depends on daily.

When was the last time your organization conducted a cybersecurity health check or security audit of its legacy software, custom applications and business-critical code?

If you don’t have a definitive answer, it may be time to look under the hood.

Your Software May Be Working, But It Is Secure?

Legacy software often gets a bad reputation, but the reality is, many older applications continue to run critical business operations reliably for years.

The problem is, left unchecked, that software can accumulate risk over time.

• Frameworks become outdated.
• Dependencies stop being supported.
• Developers move on.
• Documentation disappears.
• Integrations multiply.
• Authentication requirements change.
• Security vulnerabilities discovered in components that were once considered acceptable in the original version.

Custom software can face many of the same challenges.

Custom builds are designed specifically for your organization, and there may not be an off-the-shelf security assessment telling you where the vulnerabilities are. If the original development team is no longer available, understanding the application’s architecture and security controls can become even more difficult.

The software may still work but the looming question is whether you know what risks are hiding inside it.

Vulnerability Exploitation Is Now a Leading Way Attackers Get In

This is not theoretical.

Verizon’s 2026 Data Breach Investigations Report found that 31% of breaches began with exploitation of software vulnerabilities, making vulnerability exploitation the leading initial access vector in the report. Verizon analysed more than 31,000 security incidents and 22,000 confirmed breaches across 145 countries.

For organizations running legacy or custom applications, that statistic should prompt a straightforward question:

Do we know which vulnerabilities exist in the software we operate?

Not knowing is a business risk.

What Does a Cybersecurity Health Check Actually Look At?

A cybersecurity health check, software security audit or code audit can provide an independent assessment of how secure and maintainable an application really is.

Depending on the system, an assessment can examine:

• Source code and potential security vulnerabilities
• Outdated frameworks, libraries, and dependencies
• Authentication and authorization
• User privileges and access controls
• Encryption and sensitive-data handling
• APIs and external integrations
• Database security
• Application configuration
• Logging and monitoring
• Third-party and open-source components
• Known attack surfaces
• Documentation and knowledge gaps
• Development and deployment practices
• Opportunities for remediation or modernization

This aligns with guidance from the National Institute of Standards and Technology (NIST), which identifies maintaining inventories of software, services, and systems as a critical component of cybersecurity risk management. NIST specifically includes custom applications, open-source software, APIs, and cloud-based applications within the software inventory organizations should maintain.

In other words, cybersecurity starts with knowing what you have.

An Audit Should Lead to Decisions, Not Just a Scary Report

A useful cybersecurity health check should do more than produce an extensive list of vulnerabilities.

Business leaders need to know:

• What is dangerous vs. a warning?
• What needs to be fixed immediately?
• What can be addressed through normal maintenance?
• Which risks are architectural?
• Does the application need modernization, or does it simply need better security controls and maintenance?

The answers matter and will determine how quickly you need to act.

A business should not automatically replace a stable legacy application simply because it is old. Likewise, it should not continue operating critical custom software indefinitely without understanding its security exposure. A software security audit provides the information needed to make that decision.

STEP Software’s audit approach examines areas including security, vulnerabilities, outdated frameworks, dependencies, architecture, technical debt, performance, and maintainability, helping organizations create a clearer roadmap for remediation or modernization.

The Cost of Finding Out After a Breach Is Much Higher

Cybersecurity is often treated as an IT expense, but a breach very quickly turns it into a business expense.

IBM’s 2026 Cost of a Data Breach Report found that the average cost of a data breach in Canada reached $7.11 million, the highest level recorded in the Canadian study. The report also found that the average breach involved approximately 28,500 compromised records and took an average of 205 days to complete its lifecycle.

Those numbers do not mean every software vulnerability will result in a multimillion-dollar breach. They do, however, demonstrate why understanding and prioritizing cyber risk before an incident happens matters.

There is also a supply-chain consideration. IBM found that supply-chain compromise was Canada’s largest breach cost driver, adding approximately CA$368,000 to the average cost of a breach.

Your software ecosystem is rarely isolated, we touched on this last month on our blog Bill C-36: Is your Business Ready?

Consider how many connections to vendors, APIs, cloud platforms, databases, payment systems, customers, and other business partners your current software has.

Every connection deserves consideration.

Why an Independent Software Audit Can Help

Internal IT teams are often the people keeping the business running. They know the systems, the history, and the workarounds. They may also be too close to the environment to conduct a comprehensive independent assessment.

A third-party software security audit can provide another perspective.

STEP Software’s Advisory division provides security and quality audits, code reviews and software assessments, including audits focused on performance and security. STEP also works extensively with legacy environments and custom software.

STEP’s legacy software practice is specifically focused on stabilizing and modernizing older systems while minimizing unnecessary disruption.

This rare combination matters.

The objective is not simply to identify a vulnerability. It is to understand what the vulnerability means for the business and what should happen next.

Cyber Security Awareness Month Is a Good Reminder to Look Under the Hood

The Canadian Centre for Cyber Security recognizes Cyber Security Awareness Month every October, encouraging Canadians and organizations to understand cyber risks and take practical steps to improve their security.

This October, consider adding one more question to your cybersecurity checklist:

“When was the last time we had our critical software independently assessed for security risk?”

If the answer is years ago, or nobody knows, that does not necessarily mean you have a crisis. But it does mean you have an information gap and information gaps are exactly what a cybersecurity health check, software security audit or code audit can help close.

Start With What You Already Have

Your legacy software may not need to be replaced and your custom application may not need to be rewritten. But your business should understand the risks associated with both.

A cybersecurity health check can establish a baseline, identify vulnerabilities, uncover technical debt and help leadership prioritize the next steps.

At STEP Software, we help clients move from “We think the system is secure” to “We understand the risks, we know what needs to be fixed and we have a plan.”

This October don’t just ask whether your people are cyber-aware, ask whether your software is. And if you need help finding the answers, drop us a line, we’ve been helping companies stay one STEP ahead for over 20 years.

The post It’s Time for a Cybersecurity Health Check first appeared on STEP Software.

When was the last time you read a book purely because you wanted to?

Not a technical manual. Not an industry report. Not an email that somehow became a 14-page attachment.

A book.

Maybe it was last night. Maybe it was six months ago. Maybe your reading list consists entirely of articles you saved and fully intend to read “someday.”

You are not alone.

The good news is that global literacy has improved dramatically over the long term. The less encouraging news is that reading proficiency and reading for pleasure are declining in important populations. For businesses, particularly in an increasingly AI-driven workplace, literacy matters.

Literacy Is More Than Knowing How to Read

UNESCO reports that 88% of the world’s population aged 15 and older can read and write, while approximately 739 million adults still lack basic literacy skills. Four in ten children in low- and middle-income countries are also not reaching minimum reading proficiency. UNESCO’s global literacy data puts the numbers into perspective.

The OECD’s PISA 2022 assessment found that average reading performance across OECD countries fell by 10 points between 2018 and 2022, with reading performance already showing a downward trend in some countries before the pandemic. OECD PISA 2022 results document the decline.

Canada’s picture is somewhat better, but hardly something to ignore. Statistics Canada found that 19% of Canadians aged 16 to 65 were in the two lowest literacy proficiency levels in 2022, while 14% were in the highest two. Statistics Canada’s 2022 literacy results also point out that people at the highest levels can integrate information across dense texts and reason by inference.

That last bit is particularly interesting in an AI economy. Because reading isn’t simply decoding words; it’s understanding what those words mean, deciding what matters, recognizing what is missing and figuring out what to do next.

And Fewer People Are Making Time to Read

A 2025 study of more than 236,000 Americans found that daily reading for pleasure fell from 28% in 2004 to 16% in 2023, a relative decline of about 3% per year. It’s important to note that the researchers included books, e-readers, and audiobooks in their definition of reading for pleasure. The full iScience study makes an important distinction: the decline cannot simply be explained by people abandoning paper books for digital formats.

The changing formats of reading material may be part of the solution.

Audiobooks: Same Book, Different Door

There is no scientific prize for reading with your eyes.

A September 2026 study of 130 university students found similar performance between print and audio for recall and inference, although print produced stronger results for overall gist and vocabulary. The study in Contemporary Educational Psychology suggests that the medium affects how people process information, but audio is certainly not ‘not reading.’

For many people, its biggest advantage is accessibility.

Audiobooks can turn a commute, walk, workout or household chore into reading time. They can also provide an important alternative for people who experience barriers with traditional print, including some people with visual impairments, dyslexia or other accessibility needs.

And Canadians are using them.

According to BookNet Canada’s 2025 research, audiobook checkouts through OverDrive’s Canadian library network increased 11% from 2024 to 2025, and audiobooks accounted for 41% of digital library checkouts.

Print isn’t disappearing. In fact, 71% of Canadian book borrowers still preferred print in 2025.

That’s the point.

Accessible reading doesn’t have to mean replacing print. It means giving people more doors into literature.

Your Library Card Just Got an Upgrade

One of those doors is sitting in your phone.

In 2025, readers using the global Libby and Sora network borrowed 820.5 million digital titles, up 10.9% year over year. More than 379 million were e-books, and audiobook borrowing reached record levels. OverDrive’s 2025 digital lending report shows just how significant digital library access has become.

And Libby isn’t just about downloading a book and disappearing into your headphones.

Libby Reads gives libraries a way to make an e-book and audiobooks available to everyone simultaneously, without waitlists, creating opportunities for shared reading, discussion, and community engagement. OverDrive’s Libby Reads announcement describes it as the next chapter in more than a decade of library-led shared-reading programmes.

That is technology doing something rather lovely; it’s using software to make literature more accessible, while helping people connect with other people.

Why Should Technology People Care?

This is where reading stops being a nice hobby and becomes a business conversation.

Technology professionals spend their days interpreting information.

Developers read requirements, documentation, code, error messages, API specifications and security advisories. Architects interpret business needs. Cybersecurity teams evaluate threats. AI practitioners assess data, model behaviour and increasingly complex systems.

And none of these jobs exist in a vacuum.

The better you understand people, language, context and diverse ways of thinking, the more perspectives you can bring to a technical problem. Those diverse perspectives matter even more in the AI era.

Generative AI can produce code, summarize documents, and suggest solutions at remarkable speed. A 2025 series of randomized field experiments involving 4,867 software developers found a 26.08% increase in completed tasks among developers using an AI coding assistant. Microsoft Research’s study provides compelling evidence that AI can increase developer productivity.

But productivity is not the same thing as judgement.

Microsoft’s AI Where It Matters report with 860 developers found that AI adoption varies significantly by task, with developers placing particular importance on reliability, security, transparency and maintaining control depending on the work involved. illustrates why human oversight remains important as AI takes on more software work.

In other words, the faster AI can generate answers, the more important it becomes to have people who can ask:

• How do we know?
• Is the requirement correct?
• Is the data reliable?
• Does this code solve the actual problem?
• What assumptions are hiding underneath that very confident AI response?

Being well read doesn’t magically answer those questions. But reading broadly exposes people to more ideas, perspectives, arguments, and evidence. It helps build the intellectual context that allows technology professionals to challenge assumptions rather than simply accepting the first plausible answer.

A software developer who reads outside programming may understand users and business problems differently. An AI practitioner who reads history, philosophy, science, fiction, or social sciences encounters different models for thinking about people and systems. A technology leader who reads broadly has more context when evaluating unfamiliar technology.

In an AI time, that context is becoming a competitive skill and a business advantage.

Read Something. Anything.

There is something wonderfully rebellious about reading for pleasure.

No dashboard.

No notification.

No productivity metric.

Just several hundred pages of somebody else’s thoughts.

A 2026 review in Psychological Medicine found converging evidence connecting reading engagement with cognitive performance, brain health and well-being, including associations with reduced stress, greater empathy, and slower cognitive decline. The 2026 review is a useful reminder that reading isn’t merely an old-fashioned pastime.

So read the technical manual, read the industry report, read the AI-generated summary.

Then read something completely unrelated:

• a novel
• a biography
• a history book
• a mystery
• a cookbook
• terrible science-fiction novel you secretly love

Try it in print, on an e-reader, through an app on your phone, or pop on your noise cancelling headphones and dive into a multicast audio performance of an old classic.

Because in a world where AI can generate more information than any human could possibly consume, being able to read, understand, question, and connect information may be one of the most valuable human skills we have left.

And that sounds like a surprisingly good reason to pick up a book.

Epilogue

Its one thing to write about the prowess of reading it’s another to lead by example.

At STEP Software we pride ourselves in being able to tackle the most complex business challenges by turning them into elegant software, perhaps it is because we are a group of voracious readers.

With that in mind, here’s a list of some of our team’s favourites, TBR’s (to be read) and what they are currently reading.

Enjoy!

Drop us a line if you want to talk books, technical challenges or how we can help turn your ideas from fantasy to reality.

The post A Novel Idea for AI first appeared on STEP Software.

There is a slightly surreal quality to the AI conversation right now.

One moment, businesses are being told that artificial intelligence can transform productivity, accelerate software development, improve decision-making, and help solve some of the world’s hardest scientific problems.

The next moment, the very people building that technology are publicly warning society that advanced AI could pose an existential threat to humanity and economists are warning of pending financial collapse.

Is any of this even true?

Is AI the technology that will help businesses work smarter, solve problems faster and unlock new opportunities? Or are we accidentally building the thing that ends civilization and triggers the next financial crisis?

The uncomfortable answer is that nobody knows.

AI may be uncharted territory, but the similarities to the 90’s dot com bubble burst are eery.

This uncertainty is precisely why business leaders and technology leaders need to be paying attention and

Existential Crisis or a Bubble About to Burst

Recent headlines are not simply internet speculation or clickbait.

In September 2026, Anthropic researcher Evan Hubinger publicly said he believed there was a greater than 10% chance that AI could kill all humans within the next decade. Former Google DeepMind researcher Bilal Chughtai subsequently made similar public warnings, saying he believed AI had the potential to kill humanity and that the window for avoiding such an outcome could be narrowing.

Then came OpenAI CEO Sam Altman, saying he considered even a 10% chance of AI causing human extinction unacceptable and argued that companies and governments should take the possibility seriously. He also said OpenAI would focus on safety and alignment rather than pursuing an IPO in 2026.

These are not fringe conversations they are happening among executives and researchers at some of the world’s leading AI companies.

Critics are saying this apparent ‘about face’ by AI CEO’s is a ‘duck and cover’ strategy to ensure that they can save face if the AI bubble bursts. And they might be on to something here.

The Harvard Business Review recently estimates the AI CapEx boom to be between 1% and 2% of the US GDP. To put that into perspective, it’s in the range of $315 to $620 billion, for 2026 alone.

Academia and global financial experts may be ringing different warning bells than the AI executives, but both have merits for todays tech leaders. Perhaps now is a suitable time to repeat the words of Winston Churchill:

Those that fail to learn from history are doomed to repeat it.

AI Does Have Real Benefits

It would be remarkably difficult to argue that businesses should simply walk away from AI.

The technology is already producing measurable benefits.

Stanford’s 2026 AI Index reports productivity gains in several structured areas, including customer support, software development and marketing. It also finds that AI is increasingly being used in scientific research, with AI systems helping researchers generate hypotheses, analyse data and explore complex scientific problems.

Stanford researchers also note that AI is helping accelerate scientific discovery by allowing researchers to work through enormous datasets, generate hypotheses and explore possibilities that would otherwise require significantly more time and resources.

Business adoption numbers tell a similar story.

McKinsey’s 2026 State of AI survey found that nearly nine in ten respondents reported regular AI use in at least one business function. Eight in ten said AI had improved their individual productivity, while half said it helped them make better decisions.

Those are not insignificant benefits.

At the same time, McKinsey found that enterprise-wide financial returns remain much less consistent. Only 37% of respondents reported positive EBIT impact from AI, while approximately 6% qualified as high performers based on significant AI impact.

That tells us something important.

AI is useful but AI is not magic.

Avoiding AI is Not a Strategy

For business leaders, the response to existential AI concerns should not be to put AI in a box and hope it goes away; that’s increasingly unrealistic.

Competitors are adopting it.

Employees are using it.

Customers are experimenting with it.

Developers are incorporating AI-assisted coding into their workflows.

And AI capabilities are becoming embedded into software products that businesses already use.

McKinsey’s 2026 research found that organizations are increasingly scaling AI agents and coding agents. Nearly one-third of respondents said their organizations had decided not to purchase at least one software product or feature because they could build the functionality internally using AI coding tools.

Ignoring AI therefore carries its own business risks:

• Potential missed productivity improvements.
• Risking falling behind competitors.
• Setting the stage for shadow AI among employees.
• Forfeiting the opportunity to establish sensible governance before usage becomes widespread.

The choice is not necessarily AI vs. no AI, it’s now managed AI adoption vs. unmanaged AI adoption.

The Risks Are Not Imaginary

Recent headlines deserve attention because AI capabilities are moving into areas that were previously considered highly specialized.

OpenAI’s own recent safety reporting illustrates this.

In July, OpenAI reported that long-running models demonstrated novel failures during internal testing that were not captured by existing pre-deployment evaluations. The company temporarily paused access, developed new evaluations, and added additional monitoring before restoring limited access.

OpenAI has also reported incidents involving model behaviour extending beyond intended testing boundaries during third-party cybersecurity evaluations.

In September, OpenAI introduced a new framework for reporting model misalignment and disclosed six examples of unexpected or concerning behaviour observed over the preceding six months. The company said increasingly capable AI systems require broader and better-informed alignment research.

Anthropic has reported its own concerns.

Its September 2026 threat intelligence report describes cases in which malicious actors used Claude for cyber operations, surveillance, influence operations, scams, biological research and other harmful activities. Anthropic says it disrupted those activities and strengthened its safeguards as a result.

Businesses should not wait for science fiction scenarios to become real before taking AI safety seriously.

The risks already appearing in the real world include:

• Cybersecurity attacks
• Fraud and scams
• Privacy violations
• Automated misinformation
• Unsafe software generation
• Over-reliance on AI-generated decisions
• Data leakage
• Autonomous actions taken with insufficient oversight

Those are business risks in real-time.

The hypothetical extinction scenario belongs in a different category, but it is still worth discussing, especially because the systems are becoming more capable.

The Existential Question for Business Leaders

Perhaps the most useful question is not:

“Will AI destroy humanity?”

Business leaders cannot answer that.

A better question is:

“How do we benefit from increasingly capable AI without giving up appropriate human control?”

That’s a question organizations can act on.

It means:

• Establishing governance around AI use.
• Understanding what employees are putting into AI systems.
  • Prioritizing AI literacy, for all staff.
• Reviewing vendors and their data practices.
• Testing AI-generated software.
• Keeping humans involved in consequential decisions.
• Monitoring autonomous agents rather than assuming they will behave exactly as expected.
• Having security controls around AI credentials, APIs and access.

And it means knowing when an AI system should not be used, at all.

AI Needs an Adult in The Room

There is a tendency to frame AI safety as something that belongs exclusively to AI companies and governments.

Assuming this narrative is bad for business and the average business needs to step up their game. We touched on the need for proactive safety guardrails last week in our blog Bill-C6: Is Your Business Ready?

It’s time for IT to be asking the tough questions:

• Who is allowed to use AI?
  • For what?
  • With what data?
  • Using which tools?
  • Under whose authority?
• What happens if the AI is wrong?
  • Who reviews the output?
• What happens when the system takes an action nobody expected?
• What happens when the AI-generated code reaches production?

These are governance and engineering questions; these are critical business-technology questions.

The Technology Industry Cannot Afford Either Extreme

There are two tempting responses to the current AI conversation.

The first is blind enthusiasm:

“AI is inevitable. Just use it.”

The second is existential panic:

“AI might destroy humanity and Crash the markets. Stop everything.”

Neither is particularly useful to a business trying to make sensible technology decisions.

The more productive position sits somewhere between the two; use AI where it creates measurable value:

• Understand its limitations.
• Protect sensitive data.
• Test what it produces.
• Keep humans responsible for consequential decisions.
• Monitor emerging risks.
• Manage AI technical debt.
• Build governance alongside adoption.

And keep asking tough questions, because the goal should not be to eliminate AI from the business. The goal should be to make sure the business remains capable of controlling how AI is used while making strategic and stable financial decisions.

So, Are We Having an Existential AI Crisis?

Maybe.

But perhaps the more useful interpretation is that we are having an existentially important conversation about AI.

The technology has enough potential to transform businesses, accelerate research and change the way people work. It also has enough emerging capability to create new categories of cybersecurity, privacy, economic and societal risk.

Both things can be true.

For business and technology leaders, this means AI strategy cannot simply be about adoption.

It needs to include AI governance, cybersecurity, software quality, data management, human oversight, and risk management. And for organizations that are still trying to figure out where AI belongs, there is no shame in starting small.

Experiment.

Measure.

Learn.

Build guardrails.

Then scale what works.

The biggest mistake may not be using too much AI; it may be assuming we already know exactly what AI is going to become.

At STEP Software, we believe technology should solve business problems, not create new ones. Whether that means integrating AI into existing software, modernizing a legacy platform, reviewing AI-generated code or simply figuring out where AI makes the greatest business sense, thoughtful technology strategy matters more than chasing the latest headline.

Drop us a line if AI is causing you existential dread, or you’re curious how STEP can help.

This article discusses emerging AI risks and public statements from researchers and technology executives. References to potential existential risks are presented as attributed assessments, not established predictions or scientific certainties.

The post AI: Proceed, Pause or Panic? first appeared on STEP Software.

Privacy legislation has a habit of sounding like something the legal department will worry about later. Until someone asks IT where the customer data is stored. Then things get interesting.

Canada’s proposed Bill C-36, the Protecting Privacy and Consumer Data Act (PPCDA), represents a significant proposed modernization of Canada’s federal private-sector privacy framework. Introduced on June 15, 2026, the bill is designed to replace Part 1 of the Personal Information Protection and Electronic Documents Act, better known as PIPEDA, with a new privacy regime designed for today’s data-driven economy.

As of September 2026, Bill C-36 is proposed legislation and has not yet come into force. Its provisions would come into force on dates established by order in council.

For business and technology leaders, however, waiting until legislation becomes law before examining the implications could be an expensive strategy.

The proposed changes reach into data governance, cybersecurity, artificial intelligence, vendor management, employee information, software architecture and the way organizations think about personal information.

Why Bill C-36 Should Matter to Business Leaders

The proposed legislation starts from a relatively straightforward principle: organizations should be able to use personal information for legitimate business purposes, but individuals should have meaningful privacy protections.

The bill would establish rules governing the collection, use and disclosure of personal information in commercial activities, while explicitly recognizing privacy as a fundamental right. The Privacy Commissioner of Canada welcomed the proposed recognition of privacy as a fundamental right, along with stronger enforcement powers and privacy impact assessment requirements.

That creates a shift in mindset.

Privacy is no longer simply a compliance checkbox.

It becomes part of business operations.

For business leaders, that means asking a very practical question:

“Do we actually know what personal information our organization collects, why we collect it, where it goes, who can access it and how long we keep it?”

If the answer involves a long pause and several people looking at the IT department, it may be time for a data audit.

The Proposed Privacy Management Program

One of the most significant changes for organizations is the proposed requirement to establish and maintain a privacy management program.

Bill C-36 would require organizations to maintain policies, practices and procedures covering areas such as protecting personal information, handling information requests and complaints, training employees and explaining privacy policies and procedures. The organization would also need to consider the volume and sensitivity of the personal information under its control.

This is where privacy becomes an operational issue.

A privacy policy sitting in an employee handbook is one thing.

A functioning privacy management program is something else.

Technology teams will very likely be the ones responsible for supporting the systems that make these programs work.

Support could look like:

• Data inventories
• Access controls
• Audit logs
• Retention rules
• Data deletion
• Encryption
• Identity management
• Backup management
• Vendor controls
• Data classification
• Privacy impact assessments
• Documentation

In other words, the legislation could turn “Where is that data?” from an awkward question into a formal business requirement.

The Third-Party Software Problem

Modern organizations rarely manage all of their corporate data themselves.

Customer relationship management platforms, payroll systems, cloud services, marketing platforms, HR systems, analytics tools, AI platforms and outsourced software development can all involve personal information.

Bill C-36 proposes that organizations remain accountable for personal information under their control even when a service provider handles that information.

The bill would require organizations transferring personal information to service providers to ensure, through contracts or other means, that the provider offers an equivalent level of protection.

That has implications for vendor selection.

The cheapest software vendor may turn into the most expensive option once privacy risk is considered.

Business leaders should be asking:

“What happens to our data when it leaves our systems?”

And:

“What happens when we want it back?”

Those two questions should be part of procurement and contract creation, not something discovered after signing on the dotted line.

AI Makes This Even More Complicated

This is where Bill C-36 becomes particularly relevant to today’s technology environment.

The proposed legislation specifically addresses automated decision systems, which it defines broadly to include technology using rules-based systems, regression analysis, predictive analytics, machine learning, deep learning, neural networks and other techniques.

Organizations using an automated decision system to make a prediction, recommendation or decision about an individual that could have a legal or similarly significant effect would have transparency obligations.

On request, an individual could be entitled to an explanation identifying the type and source of personal information used and the reasons or principal factors behind the prediction or decision. The individual would also have an opportunity to make representations to an employee capable of reviewing the decision.

This is a very different technical requirement from simply saying, “Our AI made the decision.”

It creates a potential need for:

• Data lineage
• Decision logging
• Model documentation
• Human review processes
• Explainability
• Version control
• Auditability

For organizations experimenting with AI in hiring, lending, insurance, customer service, fraud detection, employee management or other decision-making environments, this deserves serious proactive, attention.

The AI model may be the clever part; the documentation around it may become the important part.

What About Employees?

This is where organizations need to be careful about oversimplifying Bill C-36.

The proposed legislation applies to employee and applicant personal information where the organization collects, uses or discloses that information in connection with operating a federal work, undertaking or business.

That means the employee provisions are not simply a blanket new federal privacy regime covering every Canadian employer. For organizations that fall within the proposed federal scope, however, employee data becomes an important consideration.

Think about the amount of information an organization may hold about its people:

• Payroll information
• Benefits information
• Performance records
• Attendance information
• Recruiting information
• Employment history
• Training records
• Device information
• Access logs
• Location information
• Workplace communications
• Security information
• Potentially sensitive HR information

Technology teams often touch many of these systems without being the owners of the information. That creates a shared responsibility between HR, legal, security, IT and business leadership.

The question is no longer simply whether the organization has the information; it’s whether the organization can explain why it has it, how it uses it and who has access to it.

The Role of Employees

Bill C-36 is not only about what organizations can and cannot do. It also introduces protections for employees who raise concerns about potential violations.

The proposed legislation would prohibit an employer from dismissing, suspending, demoting, disciplining, harassing or otherwise disadvantaging an employee because they acted in good faith to report a suspected contravention, refused to participate in conduct that would contravene the legislation or took steps required to prevent a contravention. The bill explicitly includes independent contractors within its definition of employee for this provision.

For technology teams, this is significant.

Consider these scenarios:

• A developer who notices customer information being copied into an AI tool.
• A security professional who discovers that a vendor has inappropriate access to production data.
• A database administrator who realizes that personal information is being retained indefinitely.
• An employee who discovers that a system is making significant decisions about people without adequate oversight.

These are all privacy concerns and compliance is not just a legal issue, it’s becoming an engineering ethics issue.

Data Retention a Potential Technology Problem

One of the less glamorous parts of privacy compliance may also be one of the most technically difficult.

Data deletion.

Bill C-36 contains proposed provisions dealing with retention, disposal and requests for disposal of personal information. It also establishes a proposed framework for data mobility.

The problem is that deleting data is rarely as simple as pressing delete.

What about:

• Production databases?
• Backups?
• Data warehouses?
• Archived records?
• Analytics platforms?
• Logs?
• Third-party SaaS platforms?
• Development environments?
• Test databases?
• AI training datasets
• Shadow AI instances?

If an organization does not know where its data is replicated, it cannot confidently say that the data has been deleted. This is one reason data architecture and privacy architecture increasingly need to be considered together.

The Cost of Doing Nothing

The proposed legislation would introduce stronger enforcement mechanisms, including compliance orders, a private right of action and potentially significant penalties for certain offences. The bill proposes maximum fines for indictable offences of the greater of $25 million or 5% of an organization’s gross global revenue, and for summary conviction offences, the greater of $20 million or 4% of gross global revenue.

Those are maximum penalties, not automatic fines.

But the message is clear.

Privacy is becoming a board-level risk, and because privacy failures increasingly involve technology, it is also becoming a technology leadership issue.

What Should Businesses Do Now?

While Bill C-36 is not yet law, organizations should not treat the proposed provisions as today’s mandatory requirements. Business leaders can, and should, however, use the legislation as a useful stress test.

Business and technology leaders should consider conducting a practical review of:

1. Data inventory

What personal information do you collect and where does it live?

2. Data flows

Where does information move between internal systems, vendors, cloud platforms and other jurisdictions?

3. Access

Who can access sensitive information and why?

4. Retention

How long are you keeping information, and can you actually delete it when appropriate?

5. Vendors

Do your contracts and technical controls adequately address third-party handling of personal information?

6. AI

Are automated decision systems documented, explainable and subject to appropriate human oversight? Is there documentation of burgeoning AI technical debt?

7. Employee information

If you are subject to the proposed federal employee provisions, do HR and IT systems adequately protect employee and applicant information?

8. Documentation

Could someone outside the original development team explain how your most important data moves through the organization?

That last question is more important than it sounds.

Privacy Is Becoming Part of Good Software Engineering

The interesting thing about Bill C-36 is that much of what it encourages is already good technology practice.

• Know your data.
• Limit access.
• Document systems.
• Minimize unnecessary information.
• Protect sensitive information.
• Understand your vendors.
• Build security into architecture.
• Know how automated decisions are made.
• Do not keep data forever simply because storage is cheap.

None of these ideas should be revolutionary.

What is changing is the level of accountability surrounding them.

For business leaders, the takeaway is not to panic over a bill that has not yet become law. It is to recognize the direction of travel.

Canada’s privacy framework is being modernized for a world of cloud computing, artificial intelligence, automated decision-making and enormous volumes of personal information.

The organizations that treat privacy as a technology architecture issue will be in a much stronger position than those that treat it as paperwork. Because ultimately, good privacy management is not just about compliance. It is about knowing your data well enough to protect it.

And in 2026, that is becoming an important differentiator in business and an assessment of corporate capability.

At STEP Software, we help organizations assess, document, modernize and improve the software systems that manage critical business data. When privacy requirements expose gaps in legacy architecture, data flows or system documentation, the right technology strategy can often address the business problem without requiring an unnecessary rip-and-replace project. Reach out to our advisors if you would like to chat more about data privacy concerns in your business.

Disclaimer: This article is intended for general informational purposes and is not legal advice. Bill C-36 is proposed legislation and may be amended during the parliamentary process. Organizations should obtain legal or privacy advice about their specific obligations.

The post Bill C-36: Is Your Business Ready? first appeared on STEP Software.

Wars, sanctions, supply chain disruptions, changing trade agreements, economic nationalism, cybersecurity threats and increasingly competitive relationships between major economies have moved from the pages of international news into boardrooms and budget meetings.

For Canadian tech companies, there’s an additional layer; the increasingly complicated relationship between Canada and the United States.

The temptation is to think, “We are a software company, tariffs are somebody else’s problem.” But unfortunately, it is not quite that simple.

Geopolitical Risk is Now Business Risk

The World Economic Forum’s Global Risks Report 2026 puts the issue rather bluntly. Geoeconomic confrontation is ranked as the top global risk for 2026, with interstate conflict, societal polarization, misinformation and cyber insecurity also among the leading concerns. Half of the more than 1,300 experts surveyed expect the next two years to be turbulent or stormy.

That matters to technology leaders because modern businesses are built on interconnected systems.

Your application may run in one country, use cloud infrastructure from another, depend on an open-source project maintained somewhere else, process data across several jurisdictions and serve customers on both sides of a border.

The code may be Canadian.

But the dependency graph is decidedly international.

This dependency creates several areas where geopolitical instability can become an IT issue.

1. Supply chain resilience

Software has made business more digital, but it has not made business independent of physical supply chains.

Servers, networking equipment, laptops, storage, semiconductors and other technology infrastructure still move through international supply chains. So do many of the components that support the digital economy.

The World Economic Forum identifies geopolitical confrontation and military conflict as major threats to global supply chains.

For technology leaders, this raises practical questions:

• How dependent are we on a single hardware supplier?
• What happens if a critical component becomes unavailable?
• How quickly can we replace a technology vendor?
• Where is our data stored, really?
• Which countries are involved in our technology supply chain?
• What happens if a supplier becomes subject to sanctions or export restrictions?

These are no longer hypothetical questions reserved for multinational corporations.

These now belong in technology risk assessments.

2. Cybersecurity is becoming geopolitical

Cybersecurity has always been a business concern. However, geopolitical instability makes it considerably more complicated.

Canada’s National Cyber Threat Assessment warns that state-sponsored cyber operations against Canada and its allies extend beyond traditional espionage. Threat actors are increasingly attempting disruptive activities, including denial of service, data theft, data manipulation and attacks designed to support military or political objectives.

The assessment specifically identifies Russia, China and Iran as significant state-sponsored cyber threats to Canada, while warning that Canadian organizations can also be exposed through supply chain compromises and cloud-based services.

That means cybersecurity strategy cannot simply be about protecting the corporate network anymore.

Technology leaders should also understand:

• Third-party software exposure
• Cloud and SaaS concentration risk
• Software supply chain vulnerabilities
• Identity and credential management
• Disaster recovery dependencies
• Vendor access
• Data sovereignty
• Business continuity if a critical technology provider becomes unavailable

In other words, the geopolitical environment is making the IT architecture itself part of an organization’s risk profile.

3. Then there is the Canada-US trade relationship

The Canada-US relationship has been remarkably integrated for decades. That integration is now being tested.

As of August 22, 2026, the United States imposed a 50% tariff on $27.6 billion of Canadian goods. Canada subsequently announced counter-tariffs of 15%, 25% and 50% on selected US products, covering approximately $27.6 billion of US products effective September 8, with targeted measures including electronics, appliances, steel and aluminum, among other categories.

The good news for software companies is that this does not mean every Canadian software service suddenly carries a 50% tariff.

The bad news is that the impact of trade friction does not stop at the customs border.

Reuters reported on September 3 that Canada’s trade surplus fell sharply in July, while the share of Canadian exports going to the United States declined to 66.35%, compared with 69.39% in June. Exports to non-US markets increased 7.4% during the month.

That means your technology customers may be changing their behaviour even if your software itself is not directly subject to a tariff.

They may delay projects.

They may reduce discretionary spending.

They may rethink expansion.

They may demand greater efficiency from existing systems.

And, interestingly, that last point can create an opportunity for technology companies.

4. Uncertainty changes technology budgets

When economic conditions become unpredictable, organizations tend to look much harder at technology spending.

That does not necessarily mean technology budgets disappear. It often means the standard for approving spending changes.

“Wouldn’t it be nice?” becomes“What problem does this solve?”

“Let’s replace it” becomes“Can we modernize it incrementally?”

“Let’s buy another platform” becomes “Can we get more value from what we already own?”

Statistics Canada found that businesses responding to tariff pressures were considering strategies including alternative suppliers, domestic sourcing, delaying major expenditures and investing in technology improvements. These are important distinctions.

Uncertainty can suppress technology spending, but it can also increase demand for technology that improves efficiency, resilience and control. For business and technology leaders, this is where modernization becomes strategic rather than cosmetic.

If a legacy application is expensive to maintain but essential to the business, replacing it may not be financially realistic during an uncertain economic period. Modernizing the user interface, improving integrations, exposing APIs, cleaning up data, improving documentation or stabilizing the underlying architecture may provide a much better return.

Sometimes the smartest technology investment is not the newest technology; sometimes it’s making the technology you already have more resilient.

5. Canadian technology businesses need to think beyond the US market

There is another side to this conversation.

Canada’s economy has historically benefited enormously from access to the United States. But geopolitical and trade uncertainty is encouraging Canadian organizations to diversify.

Global Affairs Canada’s State of Trade 2026 reports that Canadian goods trade with the United States declined in 2025 amid tariffs and trade policy uncertainty, while Canada’s non-US export share reached its highest level in more than four decades.

For technology businesses, diversification may be considerably easier than it is for manufacturers.

Canada’s digitally enabled services represented approximately 13% of Canada’s exports in 2025 and have grown substantially faster than goods exports since 2010. Export Development Canada also identifies computer services, information services and research and development as areas where Canada has competitive advantages.

That is an opportunity.

Canadian technology companies can sell expertise internationally without necessarily moving factories, inventory or physical infrastructure across borders.

But diversification requires technology businesses to ask whether their own operations are ready for it.

• Can your systems support multiple currencies?
• Can your contracts accommodate different jurisdictions?
• Can your data architecture support different privacy requirements?
• Can your team support customers in different time zones?
• Can your infrastructure be moved if regulatory requirements change?
• Can your business operate if one major market suddenly becomes less predictable?

These are technology architecture questions, but they are also business strategy questions.

6. What does this mean for technology employees?

This is perhaps the most overlooked part of the conversation.

Geopolitical uncertainty eventually reaches people.

When customers delay spending, businesses may slow hiring. When costs rise, companies may scrutinize compensation and operating expenses. When projects are delayed, technology teams can find themselves managing larger backlogs with fewer resources.

Statistics Canada reported that recruiting skilled employees remained one of the leading obstacles identified by Canadian businesses in the third quarter of 2026, with 25.2% identifying it as an expected obstacle.

This creates a strange contradiction. Organizations may become more cautious about technology spending while simultaneously needing highly skilled technology professionals more than ever.

The answer may increasingly be flexibility.

Instead of attempting to hire every specialized skill permanently, organizations can use a combination of internal teams, specialized consultants, staff augmentation and strategic software development partners.

These approaches can help businesses maintain critical systems and continue modernization projects without committing to a permanent expansion of every capability.

It can also help technology employees avoid the familiar cycle of being asked to maintain yesterday’s systems while simultaneously being expected to build tomorrows.

7. Resilience is becoming a technology strategy

For years, resilience was often treated as a disaster recovery conversation.

Backups, redundancy, recovery time objectives, business continuity; these things still matter. But resilience now needs to include geopolitical resilience.

Business leaders should understand where their critical technology dependencies live, who controls them, how replaceable they are and what happens if access changes unexpectedly.

That means conducting regular reviews or audits of:

• Critical software and infrastructure dependencies
• Vendor concentration
• Cloud providers and regions
• Data residency
• Cybersecurity exposure
• Software supply chains
• Legacy system dependencies
• Disaster recovery capabilities
• Documentation and institutional knowledge
• Internal technical skills
• External technical support options

The objective is not to eliminate every risk, that’s impossible.

The objective is to understand which risks could stop the business and make sure there is a plan for them.

The Opportunity Hidden Inside the Uncertainty

There is a tendency to talk about geopolitics as if businesses are simply passengers on a train heading somewhere unpleasant.

That is not entirely true.

Businesses still have choices, they can:

• Diversify suppliers
• Modernize strategically
• Strengthen cybersecurity
• Reduce unnecessary technical debt
• Document critical systems
• Build flexible technology architectures
• Invest in their people
• Diversify markets

And they can stop treating technology as a collection of projects and start treating it as part of the organization’s resilience strategy.

Canada’s current trade situation is a useful reminder that stability should never be confused with permanence. For decades, Canadian businesses could reasonably assume that the Canada-US economic relationship would remain predictable. Today, that assumption requires more qualification.

The same lesson applies to technology.

The system that has always worked may continue to work, the vendor you’ve always used may remain available, the supply chain you’ve always relied on may remain intact.

Strong technology leadership is not about predicting exactly what happens next; it’s about making sure the business can adapt when something changes. That is the real value of resilient software architecture, and in an increasingly unpredictable world, adaptability may be the most valuable asset a business can own.

At STEP Software, we help businesses assess, stabilize and modernize the software they already depend on, while building technology strategies that support what comes next. Drop us a line if you are feeling the pressure and need guidance on how to keep your tech stack flexible and resilient.

The post Tariffs as a Weapon: Geopolitics Has Entered IT first appeared on STEP Software.

Parton became one of the most recognizable figures in music and entertainment while building a business empire and an extraordinary philanthropic legacy. Curry became an international cultural icon through The Rocky Horror Picture Show, and then spent decades championing for the LGBTQ+ community while navigating a career in theatre, film, television, music and voice acting.

Both were iconic champions of diversity and pushing the boundaries of societal norms. They are proof that some of our most powerful leaders are gentle and compassionate humanitarians who also made walking on six-inch platform stilettos look easy.

Their deaths are sad, but their careers offer something constructive for the technology industry to think about.

How do we stay relevant when the world around us keeps changing?

This question applies to software systems, to technology organizations and perhaps most importantly, it applies to the humans building and maintaining them.

Technology Has Legacy Systems. People Have Institutional Knowledge.

The technology industry spends a lot of time worrying about legacy software.

And for good reason.

Legacy applications can become difficult to maintain, expensive to modify and increasingly dependent on technologies that fewer people know well.

But there is another form of legacy that organizations often overlook: institutional knowledge.

A senior developer may know why a particular database table was designed in a seemingly bizarre way. An architect may remember the reason an application was split into three services. A systems administrator may know which seemingly unrelated server is responsible for keeping an ancient integration alive. A business analyst may be the only person who understands why a particular workflow exists in the first place.

This knowledge is incredibly valuable but, it is also incredibly vulnerable.

When an experienced technology professional retires, changes careers or leaves an organization, the company may discover that years of operational knowledge were never documented.

The software remains while the knowledge disappears.

Why Succession Planning Belongs in IT

Succession planning is sometimes treated as an HR exercise, but in technology it should also be treated as risk management.

Consider a critical legacy application that only one senior developer understands.

What happens when that developer retires?

The organization may hire someone to replace them. But, hiring someone who understands the technology is not necessarily the same as hiring someone who understands the history of the application, the business rules embedded within it and the reasons behind its architecture.

This is one reason legacy software modernization should include more than a technology assessment.

It should include a knowledge assessment:

• Who understands the system?
• Where is the documentation?
• Which processes depend on individual knowledge?
• Which integrations are effectively dependent on one person’s memory?
• What would happen if that person were unavailable tomorrow?

These are all uncomfortable questions. They are also considerably cheaper to answer before there is an emergency.

Dolly Didn’t Become Relevant by Staying the Same

Parton’s career is a nearly perfect example of reinvention.

She became successful as a songwriter and performer, then expanded into film and television, business, tourism and philanthropy.

Reuters reports that she wrote approximately 3,000 songs, sold more than 100 million albums and built a business empire that included a major ownership stake in Dollywood. It also highlights her decision to retain rights to her music catalogue, allowing work created earlier in her career to continue generating value.

There is a useful technology lesson hiding in her career.

Don’t abandon the things that made you successful. Build on them.

A technology professional’s existing knowledge is an asset.

The goal isn’t to become a completely different professional every time technology changes. The goal is to add new capabilities to an existing foundation.

That’s how careers remain resilient.

Adaptation Isn’t Always Optional: Lessons from Tim

Curry’s later career offers a different but equally important lesson.

After suffering a stroke in 2013, Curry’s mobility was significantly affected. Yet he remained connected to his craft through voice work, cameo appearances and other projects. Reuters reports that he returned to the big screen in 2024 in the horror film Stream.

His career didn’t continue exactly as it had before, it evolved. The distinction matters.

We sometimes talk about career reinvention as if it is a grand strategic choice.

Sometimes it is, but sometimes circumstances force it.

Technology professionals know this feeling well:

• A programming language loses popularity.
• A platform gets retired.
• A company changes direction.
• A product disappears.
• A skill that was highly valued five years ago becomes less important.

The response cannot always be ‘wait for the industry to come back.’

It’s often an indicator that it is time to learn something adjacent.

The good news is that technology experience is incredibly transferable.

Your Legacy Should Be More Than Code

There is another important lesson here for senior and mid career technology professionals.

Your legacy should not simply be the software you built.

It should also be the people you helped build:

• Did you document the system?
• Did you mentor someone?
• Did you explain why something worked the way it did?
• Did you make it easier for the next developer to maintain your code?
• Did you challenge the organization when a better solution was available?
• Did you help someone younger become confident enough to take over?

These activities may not appear on a project status report, but, ultimately, they may be some of the most valuable things you accomplish.

Parton’s philanthropic legacy provides an excellent illustration of this principle. Her Imagination Library, launched in 1995, has distributed more than 304 million free books to children around the world. You read that right, 304 million free books. Curry, also a voracious reader created the Tim Curry Endowment for Youth Writing Programs Fund, which helps foster the growth and development of young writers,

Regardless of the industry you are in there is something powerful about building something that continues to create value after the original creator has stepped away.

Technology professionals can do this, too.

Third-Party Software Development Can Help Bridge the Gap

Organizations facing a technology succession problem do not necessarily have to choose between hiring a replacement immediately or hedging bets on nothing breaking.

Experienced software development partners can provide additional capacity while knowledge is being transferred.

Services often include:

• Legacy application assessment
• Software modernization planning
• Software audits
• Technical documentation
• Architecture reviews
• Knowledge transfer
• Application maintenance
• Staff augmentation
• QA and testing
• Middleware and integration development
• Custom software development
• On-call technical support

The goal isn’t to replace internal expertise, it’s to protect and extend it.

A third-party team can work alongside senior employees while they transfer institutional knowledge to the next generation. The right partner can also provide additional technical capacity if internal teams are stretched too thin to modernize systems while keeping the business running.

This approach can be particularly useful when an organization has a retiring senior technology resource who holds years of undocumented institutional knowledge.

A structured transition can capture that knowledge while there is still time.

This might include documenting architecture, identifying critical dependencies, reviewing source code, mapping integrations, creating runbooks and pairing experienced specialists with the people who will eventually take over.

I think we can all agree, it is much easier to transfer knowledge when the expert is sitting beside you than when their name has already disappeared from the company directory.

The Technology Industry Doesn’t Need More People Who Know Everything

It needs more people who are willing to keep learning.

Nobody can know everything anymore; technology is changing too quickly for this to even be reasonable.

The most successful technology professional of the future isn’t necessarily the person who can memorize the most frameworks.

It is the person who knows how to:

• Learn.
• Investigate.
• Ask better questions.
• Understand the business problem.
• Collaborate with specialists.
• Adapt when the first solution doesn’t work.
• And how to take decades of experience and apply it to a completely different technological environment.

Experience only remains valuable when it continues to evolve.

Be a Good Human and Leave Something Behind

The deaths of Dolly Parton and Tim Curry are reminders that careers eventually become legacies.

For the tech industry, their passing should prompt some uncomfortable but useful questions:

• What happens to systems someone understands when they leave?
• Who knows what that someone knows?
• Is existing documentation good enough for someone else to take over?
• Has the knowledge that exists in only their head been shared with anyone?
• Are the mid career team members still learning?
• Is mentoring part of the fabric of your team?

And perhaps the most important question for your team and your company:

What do you want to be remembered for?

Maybe it’s a brilliant application.

Maybe it’s an architecture that lasted 20 years.

Maybe it’s a modernization project that saved a company millions.

Maybe it’s the technical standard you established.

Or maybe it’s the five developers you mentored who went on to build things you never imagined.

The beauty of a career in technology is that you don’t have to remain the same person you were when you started. You can keep adapting, keep learning, keep contributing, keep reinventing, and eventually, leave the technology, knowledge and people around you a little better than you found them.

The goal of a long career isn’t to remain unchanged while the world changes around you , the goal is to keep changing in ways that make your experience more valuable, not less.

And perhaps it’s the real wake-up call for the tech industry.

The post Tech Needs More Tims and Dollys first appeared on STEP Software.

And then… the people who were supposed to use it don’t.

The feature sits there quietly, gathering digital dust, much like that New Year’s resolution purchase of a treadmill.

This problem is becoming increasingly visible with rapid adoption of AI.

Businesses are spending heavily on artificial intelligence and embedding AI capabilities into existing applications, but access and adoption are not the same thing. On a recent episode of AI Decoded, BBC examined this issue describing it as an ‘adoption gap’ between employees having access to AI tools and using them meaningfully. The program also highlighted a gap between AI training and access to AI tools.

CIO.com is seeing a similar shift at the enterprise level. Its 2026 State of the CIO research found that only 19% of respondents said their AI initiatives had met or exceeded business goals, while 18% said fewer than one-third of their AI use cases were meeting defined expectations. CIO identified unclear ROI metrics, unclear corporate strategy, and lack of in-house expertise among the barriers to scaling AI successfully.

The message for business leaders is straightforward:

The problem may not be that your users don’t want AI. The problem may be that you built an AI feature they don’t need.

The Technology is Not the Product

This is one of the most important distinctions in modern software development.

AI is a technology, and not automatically a product strategy.

Consider a hypothetical customer service application:

A stakeholder might decide that the application needs an AI-powered conversation summarizer because competitors have one.

The development team builds it. The model produces beautifully formatted summaries.

Everyone is impressed … except the customer service representatives.

Why?

Because their actual problem isn’t summarizing conversations. Their problem is finding the customer’s previous commitments, identifying unresolved issues, and understanding what needs to happen next.

The AI summary may be technically excellent and operationally useless.

That is a product-design failure, not a model failure.

Stakeholders Know the Business. Users Know the Work.

This distinction is crucial.

Executives understand strategic priorities, product leaders understand market requirements, IT leaders understand architecture, security and operational constraints, developers understand how to build the solution. But end users understand the thing none of those groups can replicate, what it is actually like to do the job.

Only end users know:

• Which screen(s) they leave open all day.
• Which spreadsheet exists because the official application doesn’t quite do what they need.
• Which reports they export and manipulate manually.
• Which field they enter incorrectly (repeatedly) because the interface makes it confusing.
• Where the five-minute task becomes a 45-minute task, every single time.

This information is gold during software discovery and is often missing from the requirements document.

The AI Adoption Gap Is Really a Workflow Gap

Reuters reported in August that established technology companies are emerging as unexpected beneficiaries of the AI boom because businesses are moving from experimentation toward deployment. But the article also highlights the difficulty of integrating AI with existing software, data and operational processes.

This is an important distinction.

Adding AI to an existing application does not automatically redesign the process surrounding that application.

If an employee previously had to complete five screens, obtain two approvals, and send an email before completing a task, adding a chatbot to the first screen doesn’t necessarily fix anything.

That new chatbot may have simply been added to a bad workflow.

A better question to ask is:

“If we could redesign this process from scratch, what would we actually want the user to do?”

Once you have these answers, only then should you ask where AI can help.

More AI Does Not Automatically Mean More Productivity

There is also growing evidence that AI adoption should not be measured simply by usage.

CIO.com reported in June that organizations are increasingly moving away from measuring success through adoption alone and toward measurable business value. Some organizations have burned through AI budgets while encouraging employees to experiment broadly, prompting IT leaders to focus more heavily on high-impact use cases and cost controls.

Ars Technica recently reported on analysis of 15 million real AI interactions that found most tasks at most jobs were unaffected by AI.

That doesn’t mean AI isn’t useful; it means something more nuanced: AI is useful where it fits the work.

A feature that saves a user 30 seconds once a month is technically automation and likely not a good strategic investment. A feature that eliminates 30 minutes of repetitive work every day for 500 employees is a vastly different conversation.

This is why use-case selection matters.

Build What Is Needed, Not What Sounds Impressive

The correct solution begins with better discovery.

Before approving another AI feature, organizations should ask: “What problem are we trying to solve?”

If the answer is ‘we need an AI feature,’ stop, immediately.

That’s a technology requirement, not a business problem.

Instead ask:

• What task is taking too long?
• What information is difficult to find?
• Where are employees repeatedly entering the same information?
• Where are errors occurring?
• What decisions are being delayed?
• What work is repetitive but still requires human review?
• What part of the workflow creates the most frustration?

Then quantify the problem:

• How many users experience it?
• How frequently?
• How much time does it consume?
• What does that time cost?
• What happens when something goes wrong?

Once you have these answers you will have something worth designing around.

Prototype Before You Build the Ferrari

An often overlooked and useful change is moving more of the investment upstream. Instead of spending months building the complete AI capability, create a prototype.

Put the prototype in front of real users, watch them use it and equally important, watch what they don’t use. That last part can be uncomfortable; users may ignore the feature you spent the most time building.

Good.

You just learned something before spending even more money.

Software development should not be a contest to see who can turn a requirements document into production code the fastest. Instead, it should be a process of reducing uncertainty.

Where a Third-Party Software Developer Can Help

This is where an experienced external software development partner can provide considerable value.

A third-party team can sit between business stakeholders, IT and end users and ask some uncomfortable but useful questions.

• Is this actually the problem?
• Does AI solve it?
• Could an existing application be modernized instead?
• Would an API or middleware layer solve the integration problem?
• Could workflow automation deliver the same result at a fraction of the cost?
• Does solving this problem add or subtract from existing technical debt?
• What happens if we don’t build this?

Those questions can save money; they can also save development capacity. But more importantly, they can prevent a common enterprise technology problem: continuing to spend money on a solution simply because the organization has already spent money on it.

That is the sunk-cost trap.

If users aren’t adopting a feature, the answer isn’t necessarily another round of training.

Sometimes it is better discovery, sometimes it is redesign, sometimes it is fixing the workflow underneath the feature. And sometimes, it’s admitting that the original idea was wrong; that’s not failure, that’s good software engineering.

The Best AI Feature Might Be the One You Don’t Build

There is tremendous pressure on organizations to demonstrate that they are doing something with AI. This pressure can produce some impressive demos; it can also produce software nobody uses and balloon AI technical debt.

The organizations that get the most value from AI will likely be the ones that become disciplined about distinguishing technology possibility from business value.

CIO.com’s 2026 research makes that shift particularly clear: organizations are moving toward structured governance, measurable KPIs and use-case prioritization rather than simply launching more pilots.

The same principle applies whether the feature uses AI, automation, APIs, cloud computing or something that has been sitting in the technology toolbox for twenty years.

• Start with the user.
• Understand the problem.
• Redesign the workflow.
• Choose the technology.
• Build the smallest useful solution.
• Measure the result.
• Scale what works.

Because ultimately, your software doesn’t get a return on investment because it is clever, it gets a return because someone uses it to accomplish something that matters. If your latest AI feature isn’t getting used, don’t immediately blame your users; they may be telling you something much more valuable:

You built the wrong thing.

And that’s a problem worth solving and where a trusted software development partner can help you get there.

We’ve been helping businesses solve their most annoying software challenges for over 20 years, reach out to our advisors for a complimentary 30-minute call before that next feature joins a growing collection of very impressive software nobody opens.

The post AI: We Have a Problem! first appeared on STEP Software.