This Playbook describes the benefits of configuring and running the Application Risk Management Process, what it does and how it works. We explain how you can configure and run the process “out of the box”, and provide a range of ways you can adjust the process to match specific requirements.

All of the assets required to configure and run the process are included in the Application Risk Management Use Case solution. This process also connects to, and makes use of, the Application Ownership Process that is described in Process Playbook: How to automate Application Ownership, and forms part of the Application Lifecycle Management Use Case solution.

If your model does not make use of the 'Application Ownership State' field that forms part of that Application Lifecycle Management solution, you need to adapt or avoid three of the Broadcasts which rely upon that field to determine the ownership state of an Application. Further guidance is provided in Appendix I.

This playbook is for Enterprise Architects who want to automate application risk management processes, improve their organization’s approach to application risk management and save considerable time and money for their organization.

Even though this document refers specifically to the application risk management process,, similar techniques can be applied in Ardoq to automate other governance processes.

Effective IT Risk Management involves managing and maintaining a register of all risks that impact your application portfolio, and a library of the controls that mitigate exposure of your applications to those risks. This is often a manual process that involves tedious and time-consuming activities, however, by following this process Enterprise Architects can automate processes and clear time for higher value-adding activities.
​
The benefits include:
​

Avoiding a reality gap

Without continuous management, a Risk Register can quickly become a dusty relic. This automated process ensures that the Risk Register and Control Library stay alive and connected, both to each other, and to affected applications.

Improved responsiveness

The process ensures that your Risk Register is not a static list, but is proactively managed, with the impact of risks on applications regularly monitored, and controls deployed to reduce the exposure of your application portfolio to the constantly changing risk landscape.

Saving time and money

Managing a Risk Register the old-fashioned way consumes resources, often reducing those responsible to the role of spreadsheet data entry clerks. By enabling Ardoq to engage directly with risk and application owners, there is no longer a need for key resources to single-handedly run a slow and expensive process.

Reducing risk

The purpose of a Risk Register is not simply to document what might happen. This automated process ensures that risks are actively managed and progress is made to reduce the exposure of applications to them.

Increasing engagement

This automated process puts the words “Risk Management is everyone’s responsibility” into action. It automatically engages risk owners, those responsible for controls, and the owners of the applications that are exposed to risks. All have to contribute and collaborate.

This automated process, when configured and deployed, begins when a new Risk component is added to the Risk Register, and runs continuously in the background through the lifetime of the Risk.

Figure 1 below shows the process that is provided with the Application Risk Management Use Case. Details of how this can be configured and put into operation are provided later in this Playbook.

Figure 1: The Application Risk Management Process

Responsibility for application risks and risk management varies considerably by organization. In some cases it is centrally controlled by a Risk Register owner who might, or might not, also be the owner of the Control Library. In others, it is devolved to application teams and application owners, and sometimes it is a joint effort among the Risk Register owner, a group of individual risk owners and the application owners.

This Application Risk Management Process caters for all of these perspectives. In particular, it allows links to impacted Applications and mitigating Controls to be identified and created by those who are recording a new Risk when they are creating it. But it also allows Application owners to review the Risk Register from the perspective of their Applications and create impact links from relevant Risks when they are reviewing their Applications. And Control owners can also manage the list of Applications which their Controls mitigate when creating or updating their Controls. Ten Broadcasts provide the choreography that automates the processes from these related perspectives. Not every organization will require the same balance of responsibilities and activities. Many may choose to deploy only some of the ten Broadcasts to focus the automated messaging on the people and cases where it matters most. You are strongly advised to read through this document, including the final chapter “Adapting the process to fit your organization”, before deciding how to set up and run the process to suit your organization.

Just two types of asset combine to produce this quite complex process: Surveys and Broadcasts.

Figure 2 below shows how the Application Risk Management Process of Figure 1 has been implemented with four Surveys and ten Broadcasts. An advantage of Ardoq’s distributed workflow capability is that individual Broadcasts can be enabled or disabled so that as much or little of this process can be put into action, depending on the specific needs of your organization.

Figure 2: The process in terms of Ardoq assets

Four surveys are used to support the Application Risk Management Process:

Ten Broadcasts are used to send the surveys for completion:

This section describes the few steps needed to configure the Surveys and Broadcasts and make the whole process live.

That’s it! Your Application Risk Management Process process is now running.

Responsibility for identifying and recording new risks varies from organization to organization. Sometimes the application risk register has an owner who will organize a regular review of the content, adding some new risks, adjusting existing ones and removing any that are no longer applicable. They might lead a collaborative workshop to do this. In other organizations the responsibility for identifying risks that impact applications is devolved to the application owners. Access to the RM - Risk Details Survey, which bestows the power to create, update or delete Risks, needs to be controlled in line with the organization’s policy. Can anyone in the organization add a new risk to the risk register or update or delete an existing one? Or is this the sole duty of whoever owns the risk register?

Note that, by default, the RM - Risk Details Survey allows a respondent to create a new Risk, and update or delete an existing one. A more controlled approach could limit the survey to editing existing ones, leaving control of creation and deletion to the risk register owner. Two versions of the survey might be used: one for widespread use that limits users to editing existing Risks, with the other allowing a few users the wider power to create, update or delete Risks. Alternatively, the current survey could be kept, but restricted to just the owner of the risk register.

The power to create and delete components, in addition to editing existing ones, is set in the Define the data section of the Survey Builder:

You can change the default permissions to access the survey by selecting permissions for that survey from the survey overviews page in Ardoq:

A similar question arises concerning the management of the Control Library (the collection of Controls that has been defined in Ardoq). Again, by default, the RM - Control Details Survey gives the respondent the power to create, update or delete Controls. You should consider carefully how access to this Survey should be managed.

By default, the RM - Risk Details Survey allows respondents to create new Controls during the process of adding a new Risk, or editing an existing one, when answering the question “What controls do we have, or can we implement, that can mitigate this risk?”. Some organizations may prefer to limit this power to the owner of the Control Library, and restrict the Survey question to selecting from among existing controls only.

This can be done easily by unchecking the Create components checkbox in the Survey builder for RM - Risk Details Survey under question 6 Mitigating controls.

We suggest that the three core elements of the Use Case: Risks, Controls and Applications should each be regularly reviewed. These are in addition to actions that are triggered by specific circumstances (e.g. asking an Application Owner to respond to the impact of a newly identified Risk). We propose that the three reviews can be synchronized, so that each is able to take into account recent influencing revisions. The logical sequence of this synchronization is:

We propose a six-monthly set of reviews, with a gap of one month between each element (Risk Register, Control Library, Applications). This should give sufficient time for content to be updated before the successor review. This is how the three review Broadcasts have been set up by default: each to run at 6-monthly intervals, with a month’s gap between each.

Some organizations may prefer a faster or slower pace, or may wish to change the overall frequency of review, perhaps to quarterly, or to annual. If there are very many applications, the frequency of application owner reviews could be varied by business criticality, to allocate the overall effort involved in risk management appropriately.

To change the frequency of a Broadcast, edit it and navigate to Section 5 Select schedule and reminder. Here you can select a start date, interval, and decide whether a reminder should automatically be sent to recipients who have not updated their surveys within a given number of days. The Start date fields of each of the three connected broadcasts can be set to your desired sequence and gap between them.

Of course, you do not need to make all three of these reviews live. You could choose, for example, to disable the RM - App Owners Risk Review. The rest of the Application Risk Management Process will continue to run provided the remaining Broadcasts are live. New Applications will be picked up and Owners will be asked to review the relevant Risks and Controls for them with the RM - New App Owner Risk Review Broadcast, and any affected Application Owners will have to respond to new Risks thanks to the RM - App Risk Details Broadcast.

And in some organizations, the six-monthly review of the Risk Register might also incorporate a review of the Control Library. New Controls can be created automatically when adding or updating Risks, and so these combined activities may render a separate review of the Control Library unnecessary. In such a case, the RM - Control Libary Review Broadcast may be disabled. Much depends on how ownership of the Risk Register and Control Library is allocated in an organization.

As with Applications, this Use Case provides for the allocation of owners (of type Person) for RIsks and Controls. We have made it mandatory for Risks, so that there is an escalation path in the situation where Risks are impacting unowned Applications. Without it, the Risk Register is reduced to the role of being a record of impending disaster, rather than a proactive tool for managing risk. So the RM - Unowned Risks Broadcasts will find unowned Risks and request the Risk Register owner to allocate an owner to them. It will do so daily, so unless the Risk Register owner responds within 24 hours, they will get another reminder the next day. The frequency of this Broadcast can be changed, as with all Broadcasts, in Section 5 or the Broadcast Builder, Select schedule & reminder, under Interval.

The Use Case, as implemented, does not make the requirement to have an owner of each Control mandatory. The question is asked in the RM - Control Details Survey, but there it is optional and a failure to name an owner for a Control does not have any consequences as far as the Use Case is concerned. If you wish to require new Controls to always be given an owner, you can change the minimum Number of references that can be created to “1” under the question Who is the owner of this Control? In the Questions section of the Survey builder for the Survey RM - Control Details Survey.

You could also choose to implement a check, similar to that implemented for Risks, to ensure that all Controls have an owner. To do this, you would need to:

In this way, any Controls that become unowned, perhaps because their owner has left the organization, will be picked up automatically, just as happens with Risks ( and Applications in the Application Ownership Process).

You might wonder why the 6-monthly review of the Risk Register, and that of the Control Library, are sent to their respective owners rather than the owners of the individual Risks and Controls (given that each of them has a personal owner). After all, the 6-monthly review of risks by application owners is sent to each application owner, not a central authority responsible for all applications. The reason is that the reviews of Risks and Controls should not only review all the existing Risks in the Risk Register, and Controls in the Control Library, but look at the whole set in the light of the current environment, and consider whether some new Risks or Controls should be added to Ardoq. If each owner just receives a request to review their set of Risks (or Controls), there is a danger that they will not look beyond a review of what is in front of them. This explains the design choice we have made.

But it would be a simple change to send the review Broadcasts to the individual owners of each Risk and Control. To do so, in the relevant Broadcast builder, under Section 2, Select audience, choose Add audience, and select By predefined people query.

In the resulting popup window, select the Owns checkbox at the top. A preview appears, and if you are happy that it is correct, hit the Add to audience list button:

The following Broadcasts in this Use Case solution depend upon the Application Ownership State field in the Application component type to be populated appropriately. This field, in turn, depends on the Ownership Accepted field being populated appropriately. If you have deployed, and are running, the Application Ownership Process in the Application Lifecycle Management Use Case solution, these fields will be present and populated automatically, through the operation of the process. Details of how to implement and run the process can be found in Process Playbook: How to Automate Application Ownership. If you have chosen not to deploy and run the Application Ownership Process, but wish still to deploy and run this Application Risk Management Process, you will need to amend the following Broadcasts before making them live: