How Should You Onboard New IT Systems and Software?

27 Jul

Table of Contents

This blog takes a look at onboarding information systems.  When onboarding is mentioned in terms of information security, typically, most will conclude it’s referring to people, and particularly the starters and leavers process. However, it is also important to consider the onboarding of new software and systems into our operational environment.

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.

ISO 27002:2022 Update

If you want to learn more about ISO 27002:2022 and how to implement the new controls and the new attributes, you can attend URM’s ISO 27001:2022 Control Migration Course.
Thumbnail of the Blog Illustration
Information Security
Published on
How do you Categorise Your Assets When Conducting an Information Security Risk Assessment?

‘How do we approach asset identification within our information security risk assessment?’. This blog examines which assets or asset types to include.

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
Difference Between Certified and Compliant ISO 27001 ISMS

There is some confusion about the difference between having an ISMS which is certified to ISO 27001 and one which is compliant or aligned to the Standard.

Read more
Thumbnail of the Blog Illustration
Information Security
Published on
5 Common Fallacies Associated with ISO 27001 Certification

There are many good reasons to implement an information security management system (ISMS) and get it certified to ISO 27001.

Read more
Great presentation - looking forward to your future events.
Webinar 'ISO 27001 Internal Auditing, the 6 Pillars of Success'
contact US

Let us help you

Let us help you in your compliance journey by completing the form and letting us know how we can best support you.