Introduction to Application Risk Assessment

Application risk assessment is a custom of evaluating the potential scope or considered action which might lead to an undesired outcome. Application risk factors can be termed a probability of an event which may occur or may not. These risk factors negatively impact organization’s infrastructure, system, data or business operations.  In this article, we shall focus our discussion on identification and assessment of application risks.

Why is Application risk important to organizations?

No enterprise is completely immune to attacks. Applications with risk factors tend to create many complications in an organization including:

  • Infrastructure Failure
  • Decreased system failure
  • Compliance failure
  • Security Breaches
  • Reduced Performance

In entire IT portfolio, people spend more time in identifying and fixing problems which are direct result of missed vulnerabilities. The undetected flaws straight away swallows the entire security system, creating security loopholes. This further leads to failure of infrastructure and affects the performance.

Risk factors faced by IT landscape 

  • Technology obsolescence: If an application is no longer being treated as a necessary application then, there arises a risk of ‘Technology obsolescence’. This usually happens in case when a particular application is replaced by newer version.
  • Documentation: The threat of ‘No Documentation’ exists in almost every company, i.e. lack of availability of up-to date documents related to an application. Documentation issue is mainly found in case of applications which have undergone multiple updates.
  • Skill Paucity: Skill paucity means the scarcity of knowledge about the working of application. Insufficient knowledge on application functions, in documentation form as well as in the form of knowledgeable staff, straight away turns to be a critical risk factor.
  • Vendor support: Some organizations place their critical and confidential information with external vendors for both development and maintenance. In such situations, it is essential to monitor and ensure that application is kept in good health, which also implies a very good relationship with vendors.
  • Source code availability: With the data mentioned in Figure 1, it is clear that one fourth of custom applications do not have the source code. This has been observed in such situations where application was pushed to multiple rounds of updates from multiple sources. When considering operation or maintenance of application, unavailability of sources code might be a serious issue which may also call for replacement of entire application.

         The below data highlights the percentage of applications facing certain challenges.

Pic Credit:


  • Instability: During the course of normal functioning of application, interruption caused by bugs is known as instability. This demands for additional resources being expended on applications.
  • Volatility: It is the measure of ‘How often the function of application is being challenged’? Hence the next step should be resolving these challenges.

    Application Risk Prioritization

    There may be hundreds of applications accessing in an organization. Here, the very first set of simple questions to be answered, to prioritize the application risks are;

    • What are the applications and where are they placed?
    • What is the level of risk pertaining to every application?
    • Which application is exposed to maximum risk level?
    • Which application has the risk of overlooked vulnerabilities?
    • Which applications must have security assessments right away?

    Overall Risk Categorization of Applications:

    The figure 2 arrives at an overall risk ratings. Applications which are treated as important for business must be kept on the top of queue. They should be secured first and then move to next. 

    Building Inventory

    An inventory can be as simple as an excel sheet or a portal, which basically contains the records for tracking all applications such as, existing, upcoming and developing. The idea here is to maintain a list of applications for ready reference either in excel form or in a portal or website form, which must be a well maintained document and updated regularly.

    Business Criticality is a very important aspect to be discussed upon, while prioritizing the applications. Application prioritization is a simple step of identifying ‘which application to be secured first’?

    It becomes very crucial for organizations to analyze which application is important for their business.

Example: Consider an aviation firm. This firm sells tickets online and makes millions every month. They also have an internal application which tracks the employee payroll data. Here, it is obvious for them to secure the ticketing application first. It does not mean that payroll application is not important, it holds the second position when compared to ticketing application. If the main ticketing application doesn’t function well, it makes a huge impact on business.

 The following is a sample categorization of applications. 

Critical applications, if the functioning of these apps are troubled, it directly and immediately affects the business revenue.

Important applications, if the functioning of these apps are troubled, it affects the business revenue in few days.

Strategic applications do not have any direct correlation with the business finances, but if they are troubled, they indirectly hit organization’s bottom line.

Internal support applications come under intranet facing applications which are used for smooth functioning of rest all applications. If these applications are distressed, there may not be any major loss to the company but definitely it impacts the functionality. 

Analyze Security Risk Posture: In order to categorize applications based on its security risk, it is necessary to create a questionnaire and evaluate them. The sample and basic questionnaire is mentioned below, this might be extended over a period of time. It is built to record the risk posture applications.

1  Which application is facing the internet?
2  Which application is dealing with confidential credit card data? 
3  Is this application dealing with PII data? 
4  Does application host any classified or patented data? 
5  In case if application goes down, is it harmful? 
6  Will this application be subjected to any compliance audits (e.g. PCI, HIPAA etc.)? 
7  Does this application demands assistance from Top Management or Board Members in decision making? (E.g. CEO, CIO, CTO, CISO, CFO, Board of Directors etc.) 
8  Does application implementation involves any kind of authentication or authorization? If yes, please give additional details. 
9  Is this application developed as a plug-in or extension for other application? If yes, please provide additional details on what all applications it will be working with. 


Further to simplify the task, there is another way of categorizing applications based on its level of risks, as shown below.

  • High Risk
  • Medium Risk
  • Low Risk
Risk category Sample application types
 High Risk · Internet Facing Applications
· Critical Applications Storing PII Data     
· Important Applications storing sensitive customer application
Medium Risk · Important Applications
· Strategic Intranet Facing applications    
 Low Risk · Internal Supporting Applications facing internet
· Standalone applications (e.g. Batch Applications)     


There are multiple strategies for security assessment like automated security scanners and manual security assessment. These comprise a complete methodology. Some organizations employee automated security scanners which focus on covering more applications using certain tools, reduce time and efforts. While some other organizations rely on manual security assessment, which covers less applications, but meanwhile has a better approach and quality output. 

Conclusion: Application risk assessment proves to be an advantage to multiple organizations. It is an architecture to determine the potential of any vulnerability. This aids in identifying their potential impact on other systems and business. Perhaps, it makes an easy way for organizations to evaluate application risks. 

Reference Links: