How Should You Onboard New IT Systems and Software?

Key Role of Asset Owners

In this context, we need to understand that while the IT department is the custodian of an information system, it is the responsibility of the asset owners(s) to ensure that their asset, i.e., the new software or system being introduced, includes the necessary safeguards to protect the information that it might store, communicate or process.

Generally, we find the views of system owners and information asset owners differ in terms of what protection should be provided.  Their primary concern is often biased by their respective roles in the organisation.

However, the common denominator for both roles is the confidentiality, integrity and availability of the assets under their control, although they may differ about how important each aspect is.  The truth is, the importance of all of these areas should be driven by the information itself.

Therefore, for most software and systems, it is the information asset owner that should determine how much protection should be provided, not the technical person responsible for the system/software.

Determining Risks to Software/Systems

As such, the system or software owner should consider this in the design phase and seek early input and engagement from the information asset owner.  It is vitally important that the organisation determines what the risks are to any information that may be stored, processed or communicated by the new system or software i.e., provided by the information asset owner.

Risks should be documented and communicated to all those concerned.  The result should be that the requirement for suitable controls is identified early in the development lifecycle of any new software or system, allowing the controls to be built in from the ground up, rather than ‘bolted on’ afterwards.

Planning Phase

It is imperative that the documentation regarding business and technical requirements are compared to ensure that they complement each other and are available to all relevant parties.  Therefore, during the planning phase, any development project should include business and technical requirements through bilateral communication between the business and technical departments.

The outcome of this phase should be a project brief or a business case outlining the technical requirements, deliverables, security controls required, type of data processed, roles and responsibilities and timelines.  Where required, the organisation may choose to revisit the cost-benefit ratio to ensure that the cost of implementation is lower than the risk of not implementing an information system.

‍

Design Phase

The design stage of the project should focus on technical architecture and business workflows.  It is advised to commence with business workflows to allow the technical team to review their initial plan and ensure that the technical solution is fit for purpose, particularly with regard to the security requirements of the system.  During the design of business workflows, the business may work on defining deliverables or at least its expectations of what outcomes are expected, the format, the criticality of information and requirements for any additional security controls.

Any deviation from the agreed scope of the new software or system could significantly increase the risk that the solution may not be fit for purpose.  To ensure risk is controlled, a project risk register should be considered.  Such a register allows for a transparent overview of any issues that could have an adverse impact on project deployment, including where the requirements for security have not been adequately met.

Security Assurances

In some instances, internal verification and validation may not provide adequate assurance that the security requirements of the new system are sufficient.  Where the system is hosting, processing or transmitting sensitive information, independent verification should be considered in the form of a compliance audit or thorough penetration testing.

Essentially, the trick is to identify the security requirements of any new software or system as early as possible and to ensure that these requirements are delivered, whether the software or system is a commercial off-the-shelf product or as a result of bespoke development.

‍