Cybersecurity & Final Stretch Change Requests

As a company we provide custom software, advisory, and legacy system services. But the challenges we see with our client’s often cross pollinate between divisions, cybersecurity is a regular topic.

In October we are launching a blog series called, “Questions from the C-Suite”.  We will cover topics that come up from all three divisions, questions asked by nontechnical members of our client’s teams, and scenarios where we suspect our readers could use some clarity. Cybersecurity and change requests (CR) are two topics on repeat, so let’s start there.

Question:
“Our CFO would like a change to a custom software project which is currently in UAT and has a hard deadline for PRODUCTION  in the next 30 days. Our software team is pushing back; they say it can open the door to vulnerabilities. Why is this such a big deal?”

Answer:

First off, congratulations! You’ve made it to the final stretch of a custom software project; that is success. This final stretch, however, is also where things get tricky. Changing requirements this late can be compared to walking into an airport with a ticket to Houston but deciding to go to Cairo instead: technically possible, but with different security implications, a difference in cost and potentially impossible if your timeline is immovable. These hard dates remove the ability to do proper regression and vulnerability testing, leaving your organization at risk.

Q: Why are cybersecurity implications highest in the final 10%?

A: The answer is not straight forward and is better served with a reciprocal question. Ask your software vendor or team:  “Is this change safe and how far into the final 90% are we?”

If their answer is:

“We are approaching UAT and there is minimal risk because the change is simple and does not impact the timeline”, you are likely ok to proceed. 

If their answer is:

“This change will put us back to the first 90%, requires significant code changes, increases our attack vector and will impact our timeline” a pause and regroup should be considered.

In our blog the 90-90 Aphorism we talked about how in the final 90% systems are tightly coupled, and for the most part, running as the initial Statement of Work (SOW) laid out. Simple changes often occur as a project approaches UAT or are a result of UAT. But caution must be taken if introducing new requirements means altering existing code, integrating new APIs, or reworking authentication flows.

Here’s what can happen if you do not rework your timeline to accommodate for being pulled back to the first 90% with a significant CR:

Testing Time Shrinks – Developers may not have the time to run full penetration and regression tests, fuzz testing or vulnerability scans on new features.  The likelihood of this challenge is increased if timelines for delivery are not expanded relevant to the CR.

Unreviewed Code Slips In – Under deadline pressure, code reviews and secure coding practices may be skipped. It’s like when you are a late for an appointment, you run out of the house, keys in hand, jump in the car and start driving only to realize 10 minutes into the drive that you forgot to shut the garage door and lock the house. You might as well of hung your keys on the front door for those with ill intent.

New Attack Surfaces Emerge – Even something that seems as small as adding a new login option or payment workflow can introduce new endpoints for hackers to exploit. Cybercriminals love an unchecked end point.

Verizon’s 2022 Data Breach Investigations Report notes, 82% of breaches involve human error, misconfigurations, or rushed changes; exactly the type of risk created by late requirement shifts. While their 2025 report links 60% of breaches to human error — a perceived improvement, the exploitation of vulnerabilities grew by 34% from 2024 to 2025.  With AI now powering more cybercriminal’s attempts, the sophistication of their attacks can only be thwarted with consistent and intentional proactive security diligence.

Q: Are there safe changes in the 11^th hour?

A: Yes. Some changes are relatively safe, while others should come with warning sirens and a rapidly deploying security door.

Lower-Risk – Low Cybersecurity Impact:

• Updating static content (e.g., text copy, logos, colours).
• Adjusting user interface layouts like moving a login button.
• Non-functional requirements like documentation improvements.

Higher-Risk – High Cybersecurity Impact:

• Adding new authentication or login methods.
• Modifying how payments, transactions, or data transfers work.
• Integrating third-party APIs or services.
• Changing database structures or encryption models.

Think of it this way: if a change alters how data flows, how users log in, or how systems talk to each other, it deserves heavy scrutiny and should be considered for a future phase.  Future phases are also a great business opportunity, just ask Marketing or Sales.

Q: What’s at stake financially if I push for changes?

A: The financial consequences of a cybersecurity incident can dwarf the cost of delaying a launch:

• Direct Costs of Breach: The IBM Cost of a Data Breach Report 2025 found the average breach costs $4.4 million, a 9% increase over 2024
• Operational Downtime: Ransomware or compromised systems can halt operations for weeks. The cost of this to a company is factored into the average cost of a breach in the IBM report above. Do you need a better example than UnitedHealth?
• Reputational Damage: Reputational damage can last weeks, months or even years. Public breaches erode customer trust, oftentimes irreparably and can spill over to employee and stakeholder moral. In the age of social media, managing reputational risk is paramount.    
• Regulatory Fines: If sensitive customer or financial data is exposed, fines under laws like GDPR or CPPA can run into the millions. Under GDPR, organizations can face fines of up to 4% of global revenue for mishandling personal data. British Airways is an excellent example of regulatory fine tied to poor security practices. They were fined £20 million (USD $26 million) in 2020 for a data breach tied.

When you look at the potential reputational and financial cost of a rushed change, is it worth it?

Q: What about the legal side?

A: Legal implications can be as severe as financial:

• Data Protection Laws: Data protection and privacy laws differ worldwide, but the importance has become increasingly critical with the global shift to online activities. Violation of these laws comes with severe financial consequences. We could write an entire post on these laws, instead, we will leave you with the UNCTAD’s (United Nations Trade & Development) page that breaks it all down. 
• Supply Chain Contracts: If your software is part of a supply chain, introducing vulnerabilities can put you in breach of contractual obligations. Often supply change agreements carry clear cybersecurity responsibilities for each partner, ensuring your IT team understands these clauses is critical.
• Litigation: Customers or partners harmed by a breach may pursue lawsuits. Class actions following the Equifax breach of 2017 cost the company $425 million in settlements in the US alone — a cautionary tale for any executive thinking “it won’t happen to us.”

In short: If you are adamant about the change and not prepared to change your timeline at least have your legal team on speed dial.

Final Word for the C-Suite

Changing requirements as UAT approaches is tempting. After all, this is when you finally see the product come together, and new ideas naturally surface. But keep this in mind:

If you must make a change:

Prioritize Security Testing: Allocate extra time for penetration testing, vulnerability scanning, fuzzing and code review of the new feature.

Extend the Timeline if Needed: A delay is cheaper than a breach.

Weigh the Legal and Financial Implications: Is the change worth the potential cost if it leads to an incident?

Phased Approach: Consider moving this change to another phase, a new release with new features is another opportunity to engage your end users and create customer delight.

Consult Experts: Bring in third-party security auditors who specialize in “last mile” secure software deployment or seek advice from experts to help you determine the potential impacts.

Document Everything: This helps both from a compliance perspective and for maintaining accountability.

Remember, if the change is cosmetic, go ahead. If it impacts how data, users, or how systems behave with one another — proceed with extreme caution. To put it bluntly: Better late than never. No company wants to be the headline in next year’s Data Breach Report.