Establish and Maintain the Application's Risks - Application Management Best Practices

Establish and Maintain the Application's Risks

(Chapter 114 of Application Management Best Practices)

Executive Summary: Chapter Overview

IF4IT

The Bottom Line

Application Risks that are not recorded cannot be owned, assessed, or mitigated, and tend to surface only once they materialize. This chapter defines the Risk record, including likelihood, impact, Risk Owner, and mitigation or accepted decision, and requires significant Risks and unclosed documentation gaps to enter the Enterprise Risk Register. Conscious acceptance by an accountable owner must replace silent tolerance.

Core Concepts

Concept	Definition & Strategic Role
Application Risk	A potential future event or condition that could harm the Application, its users, or the enterprise, such as security vulnerabilities, unsupported technologies, vendor instability, single-person dependencies, documentation gaps, capacity limits, or compliance exposure.
Risk Owner	The accountable person recorded against each Application Risk. Naming an owner means the Risk can be assessed and mitigated, and any decision to accept the Risk is made consciously by someone accountable rather than tolerated silently.
Enterprise Risk Register	The enterprise-level register into which every Application Risk meeting the enterprise’s thresholds, and every known documentation gap not immediately closed, must be recorded. It raises significant Application exposure to enterprise risk governance.
Risk-to-Issue Linking	Linking each Risk to the Issues that cause it, such as Technical Debt Items, Defects, and Knowledge Debt Items. It shows where fixing one Technical Debt Item or Defect would remove a significant exposure.

Quick Q&A

Question: Which attributes must be recorded for each Application Risk?

Answer: Each Risk records a description and its cause, its likelihood and potential impact using the enterprise’s risk assessment scales, its Risk Owner, the mitigation plan or the decision to accept it and who made that decision, its status and review date, and links to related Issues such as Technical Debt Items, Defects, and Knowledge Debt Items.

Question: When are an Application's Risks reviewed?

Answer: Risks are kept in the enterprise’s risk management tool or Risk Register, linked from the Application Documentation, and reviewed with every Release and on each Risk’s own review date. Regular review lets owned Risks be mitigated before they materialize, and it ensures that any decision to accept a Risk is revisited by an accountable owner rather than silently tolerated.

This chapter explains how to establish and maintain the record of an Application’s Risks.

Why Application Risks Must Be Recorded

Applications face many kinds of Risk: security vulnerabilities, unsupported technologies, vendor instability, single-person dependencies, documentation gaps, capacity limits, and compliance exposure, among others. Risks that are not recorded cannot be owned, assessed, or mitigated, and they tend to be noticed only once they materialize.

Establish the Record of Risks

For each Risk, record:

A description of the Risk and its cause.
Its likelihood and potential impact, using the enterprise’s risk assessment scales.
Its Risk Owner.
The mitigation plan, or the decision to accept the Risk and who made that decision.
Its status and review date.
Links to related Issues, such as Technical Debt Items, Defects, and Knowledge Debt Items.

Record in the Enterprise Risk Register every Risk that meets the enterprise’s thresholds, and every documentation gap that is known and not immediately closed, as described in the chapter “Record Application Documentation Gaps in the Enterprise Risk Register.”

Keep the Application’s Risks in the enterprise’s risk management tool or Risk Register, linked from the Application Documentation, and review them with every Release and on each Risk’s review date.

Best Practice: Establish and Maintain the Application’s Risks

It is a best practice to both establish and maintain the solution for an Application’s Risks: record each with its likelihood, impact, owner, mitigation or acceptance, and status, register significant Risks in the Enterprise Risk Register, and review them regularly.

Benefits: Recorded, owned Risks can be mitigated before they materialize, and conscious acceptance by an accountable owner replaces silent tolerance. Linking Risks to the Issues that cause them shows where fixing one Technical Debt Item or Defect would remove a significant exposure.

The Application Portfolio Management (APM) Best Practices addresses assessing application risk, including security, compliance, vendor, and operational risk.

How to cite this page

When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.

Example (informal web citation):

The International Foundation for Information Technology (IF4IT), LLC. Establish and Maintain the Application's Risks | Application Management Best Practices. https://if4it.org/best-practices/application-management-best-practices/establish-and-maintain-the-application-s-risks/ (accessed 2026-10-31).

See About Us for content governance and site-wide citation guidance.

Legal Disclaimers

Why Application Risks Must Be Recorded

Establish the Record of Risks

Maintain and Share the Record

Best Practice: Establish and Maintain the Application’s Risks

Connections to Related IF4IT Practices and Inventories

How to cite this page