| Recurring |
multiple_organization |
(a) The software failure incident having happened again at one_organization:
The article does not mention any specific incident of a similar nature happening again within the same organization (NHS Surrey) or with its products and services. Therefore, there is no evidence to suggest a recurring software failure incident within NHS Surrey.
(b) The software failure incident having happened again at multiple_organization:
The article mentions a study conducted by Kroll Ontrack on the methods companies use to erase data, revealing that less than half of the respondents made the effort to delete sensitive data from their old computers or hard drives. This indicates a common issue across multiple organizations where data erasure practices are not being followed adequately, leading to potential data breaches [20726]. |
| Phase (Design/Operation) |
design, operation |
(a) The software failure incident related to the design phase in this case was the failure to properly check that the data destruction company had effectively destroyed the records on the NHS computers before recycling them. The data destruction company believed that crushing hard drives was sufficient to erase the data, but in reality, this method left the information relatively easily accessible. This failure in the design phase of ensuring secure data erasure led to a significant data breach and subsequent fine for NHS Surrey [20726].
(b) The software failure incident related to the operation phase was the failure to securely delete sensitive data from old computers or hard drives before they were discarded. The study conducted by Kroll Ontrack revealed that less than half of the respondents made the effort to delete sensitive data, leading to a high potential for data breaches when these intact computers are placed on the secondhand market. This failure in the operation phase of securely erasing data before disposal highlights the importance of proper data deletion processes to prevent breaches [20726]. |
| Boundary (Internal/External) |
within_system, outside_system |
The software failure incident reported in Article 20726 can be categorized as both within_system and outside_system:
(a) within_system: The failure within the system was primarily due to the lack of proper data destruction procedures within the NHS Surrey organization. The incident occurred because the data destruction company tasked with preparing the computers for recycling did not use accredited erasure software or proper methods to permanently erase the data. This internal oversight led to the sensitive information of 3,000 patients being easily accessible on the recycled computers [20726].
(b) outside_system: On the other hand, the failure was also influenced by factors outside the system, such as the lack of awareness and compliance with legal requirements for secure data deletion. Despite legal obligations in the UK for secure data erasure, the incident occurred due to a failure in educating and enforcing these requirements. Additionally, the breach was discovered by an ordinary member of the public who purchased one of the computers, indicating a lack of proper oversight and control over the disposal process [20726]. |
| Nature (Human/Non-human) |
human_actions |
(a) The software failure incident in the NHS Surrey case was not due to non-human actions but rather due to human actions. The failure occurred because the hospital failed to ensure that the data destruction company properly destroyed the records before recycling the computers. The data destruction company mistakenly believed that crushing hard drives was sufficient to permanently erase the data, which led to the sensitive information being easily accessible on the computers sold to the public [20726]. |
| Dimension (Hardware/Software) |
software |
(a) The software failure incident in the NHS Surrey case was not directly related to hardware failure. Instead, it was a result of a failure in the data destruction process when preparing computers for recycling. The data destruction company failed to properly destroy the records on the computers, leading to a breach of sensitive information [20726].
(b) The software failure incident in the NHS Surrey case was primarily due to contributing factors originating in software. The failure occurred because the data destruction company believed that simply crushing hard drives was enough to permanently erase the data on the NHS computers. However, this method was not sufficient, and deleted data could still be retrieved from damaged equipment or formatted volumes. Proper erasure software or a degausser should have been used to ensure data was permanently erased [20726]. |
| Objective (Malicious/Non-malicious) |
non-malicious |
(a) The software failure incident reported in Article 20726 was non-malicious. The incident involved the NHS Surrey being fined for losing sensitive information about 3,000 patients due to a failure in the data destruction process. The hospital failed to ensure that the data destruction company properly destroyed the records, leading to the data being accessible on recycled computers. This failure was not due to malicious intent but rather a lack of proper procedures and oversight in data erasure [20726]. |
| Intent (Poor/Accidental Decisions) |
poor_decisions |
The software failure incident reported in Article 20726 was primarily due to poor decisions rather than accidental decisions. The incident occurred because NHS Surrey failed to check that the data destruction company properly destroyed the records before recycling the computers. The data destruction company mistakenly believed that crushing hard drives was enough to permanently erase the data, which led to the sensitive information being easily accessible on the recycled computers. This failure was a result of poor decision-making in selecting the appropriate method for data erasure and disposal, highlighting the importance of proper data deletion processes to avoid breaches and legal consequences [20726]. |
| Capability (Incompetence/Accidental) |
accidental |
(a) The software failure incident in Article 20726 was not directly related to development incompetence. It was primarily a case of data mishandling during the disposal process, where sensitive information about 3,000 patients was not properly erased from NHS computers before recycling. The failure stemmed from a lack of proper data erasure procedures and oversight rather than development incompetence.
(b) The software failure incident in Article 20726 can be categorized as an accidental failure. The incident occurred because the data destruction company tasked with preparing the computers for recycling failed to properly destroy the records, leading to the exposure of sensitive patient information. This failure was accidental in nature, as it was not a deliberate act but rather a result of inadequate data erasure practices and oversight during the disposal process. |
| Duration |
permanent |
The software failure incident described in the article is more related to a permanent failure. The failure occurred due to a combination of factors such as the failure to properly check the data destruction process, the use of inadequate methods for data erasure, and the lack of proper education and compliance with data protection regulations. These factors contributed to a situation where sensitive data was easily accessible even after the computers were supposed to be recycled securely [20726]. |
| Behaviour |
omission, other |
(a) crash: The incident reported in the article does not involve a crash of the software system. It is more related to a failure in data destruction processes leading to a data breach [20726].
(b) omission: The software failure incident can be attributed to an omission in the data destruction process. The hospital failed to check whether the data destruction company properly destroyed the records, leading to the sensitive information being passed on unintentionally [20726].
(c) timing: The timing of the incident is not a factor in this software failure. The issue lies in the improper data destruction process rather than the timing of any software functions [20726].
(d) value: The software failure incident does not involve a failure in the system performing its intended functions incorrectly. Instead, it is a failure in ensuring proper data destruction procedures were followed [20726].
(e) byzantine: The software failure incident does not exhibit characteristics of a byzantine failure where the system behaves erroneously with inconsistent responses and interactions. The failure is more related to a breach in data security protocols [20726].
(f) other: The behavior of the software failure incident can be categorized as a failure in data security protocols and data destruction processes, leading to a breach rather than a typical software malfunction [20726]. |