With the growing popularity of BS 25999, many business continuity professionals are wondering how their planning software will support a certification effort. This is a reasonable question, because many organizations have developed their programs using the default processes built within their software. Thus, those default processes, if built correctly by the vender, should lead to easy certification. However, due to the nature of the standard, no software can deliver full, out of the box compliance in a way that ensures the business continuity program can be certified; no matter what the software vendor may advertise.
Let’s take a step back and consider the key issue when asking this question. Business continuity programs involve much more than data gathering and document management, which are the primary activities a software application provides. This is why many business continuity professionals say you must have the structure of a business continuity program before you implement software. The structural components of a business continuity program are just as important as the data gathering and document management, and this is why the BS 25999 standard requires key program structure activities. Understanding that the structure cannot be gained from software, it is easy to see how software cannot be fully compliant with BS 25999 or ensure that a business continuity program is compliant. Key structure components that are not always implemented by a software application include policy development, issue tracking, testing documentation, and executive management review processes.
Understanding that software cannot meet all of the standard’s requirements, there are many requirements that it may be able to meet – such as document change control and approval tracking; however, many applications were not built with these controls as a key objective. As a result, the application may or may not be able to meet the requirement, and if it can, it will likely be a less than efficient process. In addition, BS 25999 is very specific in the controls that it requires – meaning an application may have similar controls but still not meet the standard’s requirements. For example, one of the leading business continuity software applications has an approval process that does not meet the BS 25999 requirement that only approved documents can be available for use. This issue is currently under consideration with the provider, but due to the core structure of the application, it is unlikely that an efficient solution will be provided, if one is provided at all.
In the end, no software will ensure a smooth certification process. An organization considering BS 25999 certification should carefully review the BS 2599 Specification document to understand how the current program and supporting software meets or fails to meet the standard. In addition, for areas that need to be changed, it is important to understand that processes may need to be redesigned to a less efficient or manual method in order to comply with the standard. This is not to say that BS 25999 requires an inefficient business continuity program, but like any audited certification, it requires complete compliance that can be proven repeatedly.