For a data breach, you don't always need a hacker. An error in a software change can also show, misconnect or send data to the wrong person. The recent incident at the CJIB shows why change management, functional testing and safe test data are full parts of information security.
What happened at the CJIB?
Due to a mistake in a new software release, the Central Justice Collection Agency linked approximately 6,000 claims of traffic fines, criminal cases and government collections to wrong persons for about a day. A few dozen people could access information that was not intended for them via MyCJIB. Letters with incorrect information have also been sent.
The error was found on 26 August 2026. MyCJIB was then taken offline and remained until August 30. This reduces exposure, but the incident shows how one error in data processing can hit many files in a short time.
An important nuance is that public information does not show how the CJIB has tested in advance, which test cases have been conducted or which test data has been used. So we cannot draw any conclusions on this. The case is a useful example to see which management measures organisations need around software changes.
A release is only controlled when you know the risks beforehand, have tested realistic exceptions, are separated responsibilities, can return and is actively monitored for abnormalities after commissioning.
Why change management is part of information security
Change management, also called change management, is the controlled application, assessment, testing, approval, input and evaluation of changes. The aim is that a necessary improvement does not cause unexpected disruption, security weakness or incorrect data processing.
Information security is about confidentiality, integrity and availability. A wrong link touches confidentiality because someone can see another's data. An incorrect letter or mutation affects the integrity of information. The temporary closing of a portal affects availability. One release can influence all three aspects at once.
A workable change process does not have to be a bureaucratic conference machine. The heaviness must be in line with the risk. A minor text change requires a different assessment than an adjustment in the link between persons, files, payments or medical data.
- Capture what changes, why it is necessary and which systems and processes are affected.
- Pre-judge possible consequences for data, users and continuity.
- Determine who develops, tests, accepts functionally and gives permission to enter.
- Plan the moment of introduction, the check after and the relapse option when it goes wrong.
- Keep proof the tests performed, acceptance, release and post-checking.
Test out of production but treat the test environment seriously
Changes directly in manufacturing testing increase the chance that customers, clients, employees or chain partners will experience the consequences. Therefore, use separate development, testing and production environments where the nature and size of the system justify it.
A test environment is not a safe house. It is precisely there that developers, suppliers and testers often have wider access. Therefore, also secure the test environment with appropriate access rights, logging, patching, backups, retention periods and data deletion agreements.
In addition, avoid testing functions from sending real emails, letters, payments, notifications or chain messages. External links can be replaced by a controlled test device where possible, so that a test record never accidentally reaches a real receiver.
Use synthetic or truly anonymised test data where possible
A copy of production data quickly makes a test environment realistic. At the same time, you move real personal data to an environment with different purposes, other users and often less strict access restrictions. As soon as personal data are processed during a test, pilot or pilot project, the GDPR will remain applicable.
Synthetic test data is created specifically for testing and does not describe real persons. Well anonymized data is no longer traceable to a person. Pseudonimisation is something else: when data can be re-connected with additional information, it remains personal data.
Please do not choose test data for privacy only. The set must also be functionally usable. Build realistic variation and record border cases, such as double names, multiple files per person, removals, missing fields, abnormal characters, exceptional amounts and simultaneous changes. In these combinations, errors often occur that do not show a standard test.
| Type of test data | Focus |
|---|---|
| Synthetic data | No real persons; design the set so that relationships, exceptions and limit values are tested realistically. |
| Anonymised data | Only outside the GDPR when re-direction is effectively and permanently impossible; Check the results. |
| Masked or pseudo-impressed data | Could still be personalized; protect the key and restrict access and use. |
| Production dates | Only after demonstrable necessity and risk weighting; apply data minimising, access limitation, security and removal. |
Technical testing is something other than accepting functionally
A technical test can show that code is running, an interface is responding and a link does not give an error message. This does not yet establish that the business process is the right outcome. A system can technically do exactly what was built and yet link a file to the wrong person.
Therefore, also let process owners or expert users perform functional acceptance tests. They know the meaning of data, exceptions in the process and the consequences of a mistake. Pre-set acceptance criteria, so approval is not dependent on a general feeling that the release seems to work.
Make sure that function is separated wherever possible. The developer can check his own work, but it is not the only way to determine that the release is allowed to go to production. A second pair of eyes reduces the likelihood that the same assumption remains in both the construction and the test.
- Unit and integration tests for technical operation
- regression tests to check that existing functions continue to work
- functional tests for complete processes and data flows
- negative tests and exceptional situations
- Authorisation tests: Does every role only see what she can see?
- acceptance by a authorised process owner or user
Make privacy and security part of the test cases
Privacy and security checks are sometimes only reviewed after the functional test. Then the most important question is too narrow: does the new function work? Therefore, add pre-test cases that investigate for whom data is visible, to whom messages are sent, which data are logged and what happens in case of incomplete or error record.
This is particularly important in case of changes in identification, file links, authorisations, exports, message traffic and interfaces. Check the processing from start to finish. A correct input can still be linked to a wrong account, document, message or external system on the go.
Prepare a rollback or other safe relapse before
A fallback plan describes how to turn off or reverse the change when the outcome deviates. Think of resetting a previous software version, disabling a feature flag, restoring a database change or temporarily stopping a link.
Before the release decide who decides to turn back, decide which signals give rise to this and how much time is available. Test the fallback route, too. A rollback that exists only on paper may still fail during an incident, for example because data structures have changed.
Sometimes a release can be technically reversed, while incorrectly processed or sent data already needs to be restored. Therefore, include data correction, communication, privacy assessment and any data breach notification in the scenario.
Check for abnormalities immediately after entry into service
A successful acceptance test gives confidence, but production has more users, more links and more variation. Therefore, plan a period of increased control after a risky release. You'd rather find a mistake after five transactions than after 6,000.
Pre-define what signals you follow and what normal behaviour is. Look not only at technical availability and error codes, but also at business outcomes: Number of links, unexpected changes, returned messages, abnormal transmissions, complaints and differences between source and target systems.
- automatic warnings for technical errors and abnormal volumes
- samples of accuracy of files, accounts, letters and transactions
- reconciliation between source data and processed results
- clear accessibility of the release and incident team
- an agreed decision to continue, pause or reverse
- an evaluation identifying errors and points of improvement
Subcontractors do not change the management responsibility
Many software changes are performed by an external developer, SaaS supplier or IT service provider. Ask how releases are tested, who accepts functionally, which environments are used and how test data is protected. A general statement that the supplier works according to best practices gives little insight into actual control.
Record in agreements how risky changes are announced, what evidence is available, how incidents are reported and who can start a rollback. As an organisation, keep sufficient knowledge and access to assess its functioning. The supplier shall build or manage the system; the organisation remains responsible for the process and the data it entrusts to it.
Checklist for a secure software release
Use a risk-oriented checklist for each change. A simple standard change will suffice to ensure compact registration. For critical data processing, you want to be able to answer every question below.
- Is it clear what changes and what data, systems and processes are affected?
- Has the change been technically and functionally tested outside of production?
- Have border cases, fault scenarios and existing functions been included?
- Has synthetic or truly anonymized test data been used where?
- Have privacy, authorisations, links and outgoing messages been explicitly tested?
- Has anyone other than the developer assessed and accepted the change?
- Have introduction, communication, responsibilities and decision-making moments been established?
- Is a workable rollback or other safe relapse prepared and tested?
- Is additional monitoring and functional control set up immediately after the start of operation?
- Are results, deviations, recovery actions and lessons learned documented?
Safe software changes require demonstrable control
Information security is not just about attackers outside the organisation. An unintentional error in a release may touch the same confidentiality, integrity and availability that you are trying to protect from cyber attacks.
The solution is not that every change should last months. The solution is a predictable process in which the depth of assessment and testing fits the risk. With appropriate test data, independent acceptance, workable relapse and targeted monitoring, an organisation can see faster when practice deviates from expectations.
Sources and deepening
Based on official frameworks and practical implementation
The source pages provide the formal background. Kynexis Information Security translates this information into an executable approach for your organisation, sector and risk profile.
