Risk Balance Case – Balancing the risk of policy non-compliance.

Your business could have a mature Information Assurance infrastructure with a well-practised Information Security policy, or it may be in its infancy where your information security policy is still being defined. In either case you will need to have a process in place for situations where you may have dictated an area of policy, but where one-off occurrences/events make it too difficult to justify its enforcement. There will be instances where you or teams within your organisation believe that certain areas of policy are just too stringent to uphold, too expensive to implement or even impossible to enforce with the current technologies available. It is instances like this that need a defined documented process which enables analysis of the risks involved and balances these risks against the mitigations available. This process should be the last option considered for non-compliance with policies and not seen by the organisation as a way out of implementing Information Assurance requirements. However, if this process is not in place there is a risk that non-compliance with policies is occurring but that the board and SIRO are unaware of the true depth of the risks within the organisation.

An example of where the process could be used is: you have mandated that ALL company-owned portable computing devices (laptops, tablets, etc), and all removable media (magnetic and optical) containing business sensitive or Personal information must be encrypted. This is a good policy to have, it is echoed by the internationally recognised Center for Strategic & International Studies’ “Twenty Critical Security Controls for Effective Cyber Defense: Consensus Audit Guidelines”, into which the UK’s National Technical Authority for Information Assurance (CESG) and the Centre for the Protection of National Infrastructure (CPNI) have been contributing members. It is a basic security benchmark that all organisations that process sensitive business and certainly Personal Information should be adopting. Furthermore, the encryption of Personal Data is an Information Commissioner’s Office (ICO) stern recommendation, for which security incidents occurring as a result of its shortfall are pursuable by regulatory action.

It may be, however, that you have a small ground-breaking time-sensitive project rolling out on a number of new laptops in your Research & Development area (which doesn’t involve the processing of Personal Data). The impact of the delay from ordering and installing cryptographic products and the associated training of personnel may mean losing the edge on your competition.

This is where the Risk Balance Case (RBC) becomes a perfect vehicle for such a decision-making process. The RBC is designed to alert the Board, via the Senior Information Risk Owner (SIRO), of instances of intended policy non-compliance and to document how the risk associated with the non-compliance is being managed and risk balanced through other mitigation routes. An example of a possible mitigation is the implementation of procedures – it may be that use of the laptop is only permitted by a very small team within a defined area and that permission to remove the asset is not permitted until the encryption has been installed.

Policies are rules and inflexible rules are known to hinder progress. The RBC process invites innovative thinking throughout an organisation, allowing for a risk management approach to new and existing security architectures. Where for example an additional or strengthened procedural security control can be implemented amongst a few security-conscious and well-vetted individuals in place of a standard technical control for use amongst a larger user community, then perhaps costs (and risks) could be reduced leading to an ultimate increase in business benefit.

The RBC should be a robust, detailed document which provides the SIRO with all of the information they need to be able to understand the issues and risks involved and make a fully informed risk management decision on the issues presented. The SIRO ultimately signs the RBC and accepts the risks associated with the non-compliance.

A good idea is to submit the RBC together with the proposed Security Operating Procedures (SyOPs), which display the depths to which the procedural security controls are being implemented.

The RBC needs to be written by someone with an understanding of Information Assurance and the business area involved to enable the effective analysis of all of the risks involved. After initial completion by the business area, the RBC should be sent to the SIRO on behalf of the Board. The SIRO would consider the RBC in the context of the wider business, considering the overall risks and any potential reputational or political repercussions. The SIRO’s decision should be time-bound and relay any additional security stipulations in view of the proposed discrepancy. The project team should incorporate the additional security requirements in to the SyOPs and ensure their enforcement.

The holistic consideration by the SIRO has an additional positive impact to the business by highlighting policies that may be impossible to implement throughout the organisation, meaning more consideration could to be given to these specific requirements. Without the implementation of the RBC process collation of these issues throughout the organisation may not have been possible. This collation would enable an overview and strategic understanding of the costs, risks and implications of implementing the policy and the associated impact on the organisation.

Security incidents arising from the deployment of the equipment in its vulnerable state should be reported to the SIRO via normal incident reporting channels. The RBC decision, at this point, should of course be re-evaluated; it may be that the risk has been incorrectly balanced and the proposed mitigations are too weak.

If you require any advice on the adoption of a Risk Balance Case process within your organisation, Regency IT Consulting can help; we have extensive experience in their production and in providing approval in various Information Risk Owner roles.