FR
Cyberbasics — Episode 3: selected real-world lessons from risk analysis
This article is the third episode of the cyberbasics series, dedicated to the fundamentals of software security. It follows on from the Risk analysis article and aims to complement it with field experience.
Concrete examples of strategic decisions born from risk analysis
I care deeply about being concrete and pragmatic when raising cybersecurity awareness, so in this episode I would like to share a few real-world lessons that helped me understand the value of risk analysis. I will deliberately keep the context vague so as not to cause harm to the companies involved.
If you are not familiar with risk analysis in a software context, I recommend reading the Risk analysis article first.
The product that needlessly wanted to be highly available
In the context of a startup developing what we might call an "activity monitoring" product for large industrial groups, risk analysis led us to identify the following feared event:
the monitoring data collected by the solution leaks and allows a competitor to extrapolate the exact activity of a factory.
Anyone familiar with the industrial sector knows that this kind of espionage is taken very seriously, particularly in France.
We then tried to assess the leak risk associated with the software that collects activity data from a factory, and when we dug in, we quickly stumbled upon a range of concerning issues:
- unencrypted database
- unencrypted logs
- TLS communications not always strictly enforced
A classic, I am sure many will recognise themselves in this example.
The consequence of this assessment: an unacceptable level of risk for the monitoring solution's clients. The conclusion was simple: we absolutely needed to implement data encryption, both in transit (HTTPS) and at rest (database, log files, configuration files). Worth noting that we skipped in-memory encryption, as the benefit-to-risk ratio was not favourable — which is often the case, and a topic that would deserve its own article or talk.
This then raised the difficult question of combining data protection — with extensive encryption and complex key management — with a high availability constraint. This constraint was not clearly justified and, as we later understood, came from an "architecture template" (or popular best practices, if you prefer).
An architectural problem then emerged: how do you manage encryption keys alongside a secure high availability mechanism? Those who have tried will tell you the solution is always expensive, in engineering and infrastructure alike. But! It turned out that in this specific case, monitoring data was only collected, on average, once a week. This frequency comes from industrial standards and can be taken as a strong assumption. The direct consequence for our architecture was simple: any high availability mechanism is superfluous, it would create accidental complexity (and what complexity!) and make data protection harder.
In conclusion, we opted for a simple, monolithic architecture with a single encryption key pair — easier to manage — along with clear development guidelines:
"at the slightest error or suspicion of a security issue: shut down the software in fail-safe mode, encrypt everything, and raise an alert."
On top of being simple to implement, this solution is easier to explain and audit — and that is a real asset when convincing sceptical clients.
In this case, risk analysis allowed us to lift a design bias (the false need for high availability) and implement a simple solution, achievable with resources appropriate for a modest team.
Securing gift card codes and their financial value
I had the chance to work on a project for a mid-sized company that manages bearer vouchers — codes that allow their holder to spend money on merchant websites. The idea of a bearer voucher is that whoever holds the code can spend the money. Where things get interesting is that to generate commercial margins, these codes are negotiated in large volumes and purchased by the thousands, for amounts that can reach six or seven figures.
We therefore had transactions through which thousands of gift card codes had to be injected into our system, for a substantial total value. Without going into detail, I will let you imagine how to secure the transaction — and you will quickly understand why we ended up with something very complex, given the financial risk associated with a full leak of the codes.
The core problem was that during the transaction between the merchant and our system, if an attacker managed to access the batch of codes, they had won. A simple read or copy of the information was enough to pocket the money it represented. This gave us a lot of headaches, as this kind of scenario is very difficult to mitigate effectively.
But then, during a risk analysis session with one of the company's founders, we learned that this transaction was secured upstream by the merchant. In practice, if an incident or a doubt about the confidentiality of a batch of codes arose, it was enough to call the merchant and have them cancel the entire batch — with the bonus of being able to regenerate it very easily.
What this meant for us was that our problem reduced to anomaly detection (detecting that an attacker had been able to read the information) rather than long-term protection of sensitive data.
This "phone call" option, which we had not known about at the start of the project (we all know that product specifications are by nature incomplete), ended up greatly simplifying the architecture of the software we had to build.
The medtech founder who gave up on software sovereignty
It is common for many organisations, of all sizes, to impose strict sovereignty constraints in their specifications, then abandon them once they understand the associated cost.
In this last example, I am thinking of a founder of a medtech (medical technology) company, who wanted to develop a personalised health tracking application. Health data being highly sensitive, there was no question of using non-sovereign software solutions for her project.
We then explored solutions to provide her with a sovereign cloud infrastructure. The problem: the budget estimates from our study exceeded her startup's budget by a wide margin.
We then carried out a quick and honest risk analysis with the objective of measuring what an infrastructure capable of protecting against US espionage would actually cost.
We quickly drew up a list of services that would need to be dropped: Google Workspace, Microsoft Windows PCs, hyperscaler infrastructure, the founder's Mac... The cost of such an IT infrastructure was clearly prohibitive for this startup and would have jeopardised its survival. The economic risk of meeting the sovereignty constraint was too great; the constraint was too costly to uphold. We ultimately went with a hyperscaler — it was the only way to stay within the client's budget.
A note for purists: no, we did not violate any European regulation on this project :) The data involved was not strictly medical, and we operated within an environment compliant with HDS (Healthcare Data Hosting) certification — a French standard for hosting health-related data.
Key takeaways
These three examples share a common structure: the obvious solution at the start of the project was not the right one, and it was risk analysis that allowed us to realise it.
In the first case, it revealed a false need — high availability — and led to a simpler, more securable architecture.
In the second, it brought to light missing information in the specifications — the merchant's ability to cancel the codes — which transformed an unsolvable problem into a manageable one.
In the third, it made the true cost of an abstract constraint concrete, enabling an informed and deliberate decision: accept a risk.
Risk analysis is, above all, an exercise in clarity. It does not always produce complex action plans — sometimes it produces simplifications, reframings, or deliberate acceptances. In all cases, it produces clarity where there was ambiguity.
And that is precisely why it is worth practising, even imperfectly, even quickly.
This article is part of the cyberbasics series, aimed at developers and small organisations who want to build a solid, pragmatic security posture.