Security, performance, recoverability: why “later” is always too late

We'll deal with non-functionals later

I encounter it almost every week. Sentences that sound like this: “We use Microsoft's Cloud Adoption Framework.” It sends shivers down my spine. Without exception, the speaker is trying to explain to me that security is taken care of. Not so. Your security is not taken care of, and it's even worse than that.

If you ever say or think this, read on to find out why it's not taken care of and what you should do instead.

You see, functional requirements get all the attention: “the button must do this, the screen must show that.” Non-functional requirements (NFRs) are pushed to the end of the sprint planning. Or even worse: “we'll test that after going live.” Because there's always pressure: MVP, deadline, demo.

And then comes the go-live.

Not with champagne, but with fires:

A data breach because authorizations were to be set up “a little later.”
Data loss because backup and recovery were never practiced.
A slow application because performance was not an acceptance criterion.
Angry users because the system fails unpredictably.
An audit you fail because logging and traceability are missing.

That's not a technical detail. That's a risk to revenue, reputation, continuity, and compliance. In short: boardroom territory. When you postpone NFRs, you're not just pushing off “IT work”; you're pushing forward director liability, fines, and business disruption.

And the most painful thing is that “later” rarely comes. By the time the problems become apparent, the budget has been exhausted and the organization is already dependent.

What exactly are non-functionals/NFRs?

They are requirements for how the system behaves under pressure, failure, and abuse. Not what it does, but whether you can rely on it.

Important categories (that you want to have checked at a minimum):

Security & privacy (auth, authorization, encryption, data retention)
Performance & scalability (latency, throughput, peak load)
Availability & reliability (uptime, failover, degradation)
Recoverability (backup, restore, RPO/RTO, disaster recovery)
Observability (logging, metrics, tracing, alerting)
Manageability (patching, configuration, deployment, rollback)
Compliance & auditability (rights, evidence, reporting)
Usability & accessibility (friction, errors, WCAG)

In this blog, I will go over areas where non-functionals often go wrong, why that happens, what damage you only see when it's too late, and how you can make them mandatory from day one: measurable, testable, and controllable.

Security “ingrained”? Then you haven't read the “recipe” properly.

“We use Microsoft's Cloud Adoption Framework, so our security is taken care of, right?”

As I mentioned, I hear this a lot. In fact, you're saying, “We have a cookbook, so dinner is ready.” “Come on, Hugo, don't be silly,” you might think. It's not silly; it's just another Microsoft trick to make you think you have everything under control. Unfortunately...

CAF (or any similar framework) is not security. It is a set of guidelines. A checklist. A way to structure your work. Useful, certainly. But it does nothing, builds nothing, protects nothing. At most, it says: this is what you need to think about.

Security only comes into being when you make those guidelines concrete. With choices. With boundaries. With firm agreements that you can test.

Because security is not built into your cloud subscription. Nor is it built into your standard products. And it is certainly not built into your organization.

What you do need to ‘build in’, i.e. decide on and implement, is:

Identities and access: who is who? What roles exist? What rights do they entail? And why? Without an authorization matrix, “least privilege” is just a poster on the wall.
Connection to applications: SSO, conditional access, service accounts, API rights. Every connection point is a new door.
Network and platform security: segmentation, firewall rules, hardening, patching, secrets management.
Detection and response: logging, monitoring, alerting, triage. Not “we have a SIEM,” but: who is watching, when, and what is the first action?
Continuity: incident response, emergency procedures, backup and restore, DR testing. A backup that you never restore is a false sense of security.

And then there's the most underestimated part: ownership. Who is ultimately responsible? Who decides what can go live? Who pulls the emergency brake when risks escalate?

The boardroom likes to ask: “Is security taken care of?”

The better question is: “What risks are we willing to accept, and how do we know it works?”

Because if you call security “ingrained” when you haven't even chosen the ingredients... then it's not a strategy. Then it's hope. Or, as I call it, false security with the certainty of problems that will cost you a lot of money.

Your upgrade was successful... until Monday morning at 9:00 a.m.

At the end of last year, it happened again: SQL Server 2022.

On paper, a neat, necessary upgrade. In practice: every week—sometimes several times a week - CPU at 100% for a full hour. And users doing exactly what you don't want them to do: refreshing, retrying, escalating. Not because they are difficult, but because their work grinds to a halt.

This is not an SQL-only problem. Oracle 12.1 also showed that it's not “the application” but the release itself that can be the performance problem. New versions bring structural changes: different query planners, different memory and IO behavior, new defaults, extra background tasks. Sometimes that's a gain. Sometimes it's exactly the wrong direction—for your workload.

And that's the pitfall: support pressure turns upgrades into panic projects.

‘Out of support’ sounds like a compliance issue. So the organization goes into sprint mode: plan, click, migrate, done. And the non-functionals? They'll come later. Until later suddenly becomes production.

The problem gets bigger if you don't build the software yourself. You don't know what assumptions are built into it. The supplier says, “Compatible with version X.” But that rarely means, “Tested with your data, your customization, your peak load, your chain.” They test generically. You run specifically.

And if you only discover this after half a day of production on the new release, then ‘going back’ is often not an option. Or rather, it is, but at a serious cost: downtime, recovery, data fixes, extra consultancy, reputational damage. The rollback is always more expensive than the test you skipped.

I saw the same thing with a recent Windows 10 → Windows 11 upgrade. Everything was done by the book: minimum system requirements checked, outdated workstations replaced. Great. Except that no one had tested what would happen when you started working. The result: machines that “run Windows 11 fine,” but where Word and Excel take minutes to load. Teams? Five minutes to start up and then another minute to open a call. A bare-bones OS check means nothing if your productivity lies in the applications.

Haste makes waste.

Especially when it comes to upgrades.

Because as soon as support pressure dictates the schedule, the non-functionals are the first to go. And they are precisely what determines whether your company can run as usual on Monday morning.

Don't turn “later” into an incident report

You can ignore non-functionals... until they ignore you.

Most problems are not caused by “a bug.”

They are caused by what has not been agreed upon and not tested: performance under peak load, authorizations, logging, recoverability, failover, manageability.

And then it's always the same ritual:

War room, escalations, suppliers pointing fingers, users cursing, the boardroom asking how this could have happened.

You want to stay ahead of that.

So schedule a no-obligation 30-minute appointment with me. We'll walk through your upcoming rollout or upgrade together and determine:

Which non-functionals really need to be robust,
Which need to be made measurable/testable,
And which risks you are currently unconsciously accepting.

For more than 15 years, Sciante has been helping organizations get their non-functionals in order—before going live. So that rollout is a choice again, not a gamble.

Make that appointment. Organizations that do this in advance avoid escalations, repair costs, and administrative surprises afterwards.