Last week, Tony Kyriakidis from Nevron, the current maintainer of IM in the Cloud, called me with a question about a design decision from the system's early years.
"Leo, why did you choose this particular approach to deleting incidents back then?"
I had to smile. Not because of the question itself, but because it immediately took me back to the drawing board. We had already discussed the reasoning behind that design choice at length at the time.
The first from-scratch design of IM in the Cloud dates from 2016. From the outset, we deliberately integrated the main security principles into the system architecture. This was a conscious design choice, consistent with the principles later incorporated into the BIO (Baseline Information Security for Government).
Tony's question arose from a current discussion about the BIO. This brought the 2016 design choice back into focus. Since that decision had been made long before Tony became involved with the system, I found it all the more interesting that this particular question had resurfaced.
Although a specific design choice in IM in the Cloud prompted it, this article is really about a question every software architect encounters sooner or later.
Behind that one question lay a much more fundamental one:
When do you record something because it is truly necessary, and when do you record it simply because it is technically possible?
The question was:
"Why is the time recorded when an incident is deleted, but not the user who deleted it?"
The issue was whether the user should also be recorded to comply with the BIO.
Whether that interpretation of the BIO is correct is not, however, the central point of this article. I find the underlying design question much more interesting.
At first glance, the answer seems simple: just record the user as well.
But that, to my mind, is precisely where the real design question begins.
Security is not a collection of measures added to a system afterwards. In a well-designed system, Security by Design principles are naturally part of every architectural choice from the very beginning. That is exactly what Security by Design means.
When designing IM in the Cloud, we deliberately distinguished between a data modification and a status change. This was not a choice unique to this system, but a consideration every architect faces sooner or later.
The distinction itself was not new. It came from UDLS, an earlier incident management system I designed for Rijkswaterstaat. There too, we deliberately distinguished between data modifications and status changes, because they have fundamentally different meanings within the incident management process. Only then comes the question of which information actually needs to be recorded. That choice also affects information security, auditing and privacy. It is interesting that a design decision from those days still prompts relevant discussions today.
A data modification changes the content of information. A status change primarily marks the phase an object is in. That may seem a small difference, but for logging, auditing and privacy, it is a fundamental distinction.
Because deleting an incident in IM in the Cloud is a status change, we deliberately chose to record the time of that change. At the time, we explicitly decided not to attach the user to it by default. This was not a technical limitation, but a conscious architectural choice. Recording a status change does not automatically mean that all associated user information must also become part of a security log.
There was a second consideration as well. We wanted to prevent functional application data from quietly becoming a tool for assessing individual users. Incident Management depends on collaboration under sometimes extreme time pressure. Recording only the information genuinely necessary for the operational process keeps the system focused on supporting incident management, rather than on individual performance assessment. Ultimately, that also contributes to trust in and acceptance of the system.
Perhaps this is the greatest source of confusion. There is an essential difference between an application's functional data and a security log.
Functional data is intended to support the primary process. Which modifications have been made? What is the status of an incident? What information is needed to carry out the work properly?
A security log serves a very different purpose. It supports information security, audits and technical investigation of security events. These are fundamentally different objectives and therefore require different design considerations. Treating them as interchangeable soon leads to unnecessary records and discussions about proportionality and privacy.
This distinction mattered beyond the original design. At the start of the DTP project in 2020, when IM in the Cloud first entered operational use, we again discussed these design principles at length. It became clear that the difference between functional data and security logging was not always self-evident. We therefore devoted considerable time to explaining the underlying design choices and the different purposes served by these two forms of recording.
Those discussions explicitly covered the decision to record only the time when an incident is deleted, rather than the user by default. That design choice was consciously reaffirmed at the time.
Tony's question last week showed that these design principles remain relevant years later. Sometimes a practical example explains an architect's original choice better than any design document can.
For me, this again confirms that discussions about information security sometimes move too quickly towards "What can we record?" rather than "Why do we want to record this?" Every entry in a security log should serve a demonstrable security, audit or operational management purpose. Otherwise, you risk recording privacy-sensitive information or performing checks that contribute little to security.
This is precisely where good system architecture proves its value. Incident Management is a highly specialised domain, with a close interweaving of legislation, operational processes, responsibilities and organisation in the Netherlands. IM in the Cloud's original from-scratch design was deliberately built around that domain-specific reality. Architectural choices could therefore be considered together from the beginning, rather than added later.
Many older COTS solutions were designed when security, auditing and domain-specific requirements were less fully integrated into system architecture. Even relatively small changes to such systems can have unexpected consequences for security, auditing and maintainability, precisely because these aspects were not considered together from the outset.
Good architecture does more than solve today's problems: above all, it keeps tomorrow's changes manageable and affordable. Perhaps that is the most important characteristic of good system architecture — not how much functionality it contains today, but how easily it can adapt tomorrow to new insights, new security requirements and changing laws and regulations.
For me, this question once again confirmed that good system design does not begin by asking:
"What can we record?"
It begins with a much more fundamental question:
"Why is this information needed at all?"
Only when you can answer that question can you decide whether to record something, what to record, how long to retain it and who may access it. To me, that is the essence of Security by Design.
If the client eventually decides that the user should also be recorded when an incident is deleted, a well-designed architecture should support that extension without major changes. This applies not only to IM in the Cloud, but to any system developed according to Security by Design principles.
Even then, my first question would still be the same:
Why is this record necessary?
Because deliberately choosing not to record information can also be a well-considered architectural choice. Not because it is technically impossible, but because every record should serve a demonstrable security, audit or operational management purpose.