COI Report – Part VII Page 382 of 425 threat. Malicious parties are continually innovating, devising new ways of attacking systems, and in response, the IT security industry has to find ways of reducing or eliminating this threat. However, systems can only benefit from the latest security tools and if the software is kept up to date. 47.1 A detailed policy on software upgrading must be formulated and implemented 1111. IHiS’ policy documentation, and the HITSPS in particular, are silent on the issue of software upgrades. The draft version of HITSPS Version 4.0 provided in IHiS’ evidencealso omits any mention of a software upgrade policy. 1112. A detailed policy must be formulated to make clear that security is an important consideration when determining if and when software should be upgraded, and how such upgrades should be prioritised. 1113. We set out the core elements that should form part of the software upgrade policy in the following sections. 47.1.1 Maintenance of an organisational-level software inventory 1114. The policy should require that an accurate inventory be maintained of all commercial off-the-shelf software packages in use by the Clusters, along with version numbers of those software packages. This inventory would help administrators better monitor and identify which endpoints require software upgrades to be rolled out, when the decision is made to do so. 47.1.2 Planning process for upgrades 1115. The policy should provide fora continuous planning process that does not only involve operational IT staff. For example, a cross-functional team can be formed, comprising all stakeholders – users of the software from Clusters IT operational staff IT security staff and IHiS/Cluster management. When anew version of the software is released, the team can map the new functions to the current system and the business processes that are affected to determine whether
