In a more and more digitalized workplace, new applications enter our daily workplace routines almost on a monthly basis. How should we welcome these applications?
There is no doubt that there are different aspects to take into consideration when on-boarding new applications. In this article we'll take some of them into account.
Planning
During planning it's important to take into account all the different aspects of the application, to make sure that both the implementation and support/maintenance of the application is clearly defined and decided upon.
What issues does the application aim to resolve?
Have detailed specifications of what the application aim to resolve. This way it will be clear what is to be delivered, making it much easier for the parties involved to estimate cost as well as deliverables based on the specifications.
Is the ROI for the implementation of the application positive?
Based on both the specifications and the initial need for the application, the leadership needs to make sure its implementation and the timeframe are within the needed parameters.
Don't let the application be another one of the failed implementations, overrunning every budget that was in place. Make sure that the costs associated with the system are less than the earnings that the application will solve over time.
> On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted.
Source: McKinsey & Company (https://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/delivering-large-scale-it-projects-on-time-on-budget-and-on-value)
Not only does a project usually deliver less value than predicted, they also overrun costs in almost 50 percent of all cases (!!), when developing projects above 15$ million. Make sure we know the deliverables and costs long before the project is started.
Pre-projects are golden. A good pre-project saves time when implementing the actual solution, as well as giving a good indication to if the project to be implemented is both worth it and actually do-able.
Will the application comply with the organization's information security policies?
A very important aspect before implementing the application is to make sure that the delivered application can be integrated to comply with existing information security policies.
When an application that is already developed by an external party can't comply with existing security policies (But the business value is high), then there are a few different ways to handle that application:
- On-premise solution: Can the application be containerized within a secure environment. If so, then the application can be insecure itself, but still comply with the existing security policies.
- Cloud solution: Cloud applications are a lot harder to deal with when they can't comply with security policies. As a bigger vendor it's usually possible to drive the development of the cloud application or get a hybrid-cloud solution where the actual app can be hosted on-premise. These solutions might make it possible to comply with the policies in place (Usually at a higher cost).
Who will be responsible for the support & maintenance of the application
Making sure we know who will support the users and maintain the application is key. Keeping it up to date with feature requests as well as security patches is extremely important.
There is usually three way's this can be provided;
- Full support & maintenance by the application vendor.
- Partly provided where the vendor does one of the two above mentioned.
- The organization is responsible for both support & maintenance of the application. (For example internally developed applications)
The first and second case will need to include a detailed, ongoing agreement with the vendor. By doing this, we can make sure that deliverables are delivered on time and that the support uphold the promised guidelines and that it can be measured for a monthly/bi-monthly/half-yearly/yearly meeting.
The same goes for the two latter cases, however it's then also important to decide and dedicate a team inside the organization to take care of the application before it's delivered. This way it's clear from the start who should be contacted in cases of support and maintenance. There should always be a product owner within the organization that makes sure that issues are caught fast and handled, even when the application is fully supported by the vendor.
Which employees will have access to the application
From both a cost & security aspect it's important to take into consideration who will use the specified application. That information will help both with estimating the delivery cost as well as where and how the application should be rolled out.
If the application only needs to be delivered to a small department in the organization, then the security aspect will be a lot easier to handle than if for example it needs to be deployed organization wide.
By figuring out exactly who will be using the application the different teams can easily plan months ahead to make sure that the application is deployed securely and cost-efficiently.
Will other available applications be made obsolete by this application?
With a beautifully new application it's easy to forget about the one(s) that were used before.
> 89% of IT chiefs admit to using outdated applications despite vulnerability to security.
Source: InformationAge (https://www.information-age.com/outdated-applications-security-123473108/)
It's a time consuming process to move data from old applications into new applications or simply archiving it. Instead many leave their old applications running to potentially open up huge security holes in their organization.
Instead of allowing software that has been replaced to keep running without any security supervision, we need to decide what to do with the old applications from the start.
Planning for removal and including that in the delivery of the new software is crucial. By not allowing deliveries to be approved before any old/outdated applications have been correctly migrated/handled, ensures a secure environment. Having this on the agenda and in the C-level focus is important.
End of life
In the section above we specified the case when an application is replaced directly by another application. This is not always the case. Sometimes business needs change and the applications simply become useless. When this happens is extremely important to have a decommissioning plan that are regularly updated and validated.
By having clear decommissioning plans it's easy to determine when, how and why an application should be decommissioned. If the application is replaced, then the decommissioning plan will be a good guide to how the application should most safely be removed/migrated, without removing any invaluable data.
Summary
The points above includes a small subset of the many things that needs to be taken into consideration when planning for a new application.
An important aspect that is very important to not forget, is to always include and engage C-level's in the IT policymaking. Without understanding from C-level and the Board it's hard to dedicate the time and funding to actually implement many of these important factors.
Most of the above mentioned security factors have no direct value to the organization and can therefore often be looked upon as an increased cost. It's extremely important to not forget how multimillion dollar corporations have taken massive hits due to poor IT Security. By not providing good incentives for organizational IT Security, then this won't ever be a priority.
A short section from the chilling article about NotPetaya in The Wired Magazine will explain this better than I ever could:
> And, of course, Maersk was only one victim. Merck, whose ability to manufacture some drugs was temporarily shut down by NotPetya, told shareholders it lost a staggering $870 million due to the malware. FedEx, whose European subsidiary TNT Express was crippled in the attack and required months to recover some data, took a $400 million blow. French construction giant Saint-Gobain lost around the same amount. Reckitt Benckiser, the British manufacturer of Durex condoms, lost $129 million, and Mondelēz, the owner of chocolate-maker Cadbury, took a $188 million hit. Untold numbers of victims without public shareholders counted their losses in secret.
Source: The Wired Magazine (https://www.wired.com/story/notpetya-cyberattack-ukraine-russia-code-crashed-the-world/)
That's a chilling estimate of **2.300$ million**, yes million. Not to mention that this was just a few of the official numbers. Most of these breaches could have been solved by using less than 1% of that amount on their security budgets.
So let's put information security on the agenda, not only for IT, everyone.