In my first column I invited you into the office of the CSO and the CEO of a company that had re-positioned itself as a security risk management services (SRMS) provider; a new category that I feel is emerging to address the need for a 360-degree view and understanding of an organization’s risk strategy, plan, processes and metrics.

Now let me give you an example of how an SRMS provider could be deployed by an organization and/or their CSO. In this scenario, a medical transportation company’s business model is to partner with hospitals to transport critical care patients from the point of incident to the appropriate care facility. They will be in communication with hospitals transferring patients to other hospitals as well as with first responders at the scene.

An SRMS company was hired to study the business case and the supporting processes behind it. The SRMS firm recognized the hospital depended on expedient response and appropriate level of care at the time of need.

For the transport company, their ability to react and be valuable depended on a series of steps within a workflow. When an emergency transfer has to occur, the nurse would have to move from the patient to the phone to create a transfer. The phone number of the transport company would have to be remembered or found. The phone call would have to be made, acknowledged and acted upon.

Initially, without a baseline understanding of the model, the need and the process, technology was applied, in the form of a “button” that would be pressed by the nurse. The button would avoid the steps of looking up the number, finding the phone and calling the transport company with a single push. But, as so often happens, risk was not properly considered or understood. As well, the understanding of capabilities within the current technology architecture that had already been purchased and deployed was lacking. The lesson: risk is embedded in the behavior of people performing roles in a process using technology as a tool.

In this case the button did not provide positive acknowledgement, so the phone call would still have to be made. The consequences: wasted seconds when lives depend on seconds, wasted costs of the phone service, and, in the button’s utilization, wasted investment in a modem purchase.

 After reviewing the business baseline and the core processes, the risks and the technology, the cross functional team arrived at an effective solution using commercial-off-the-shelf (COTS) video surveillance cameras and video management software. The VMS provider had an open architecture with an embedded rules engine for an input of a button and an output for a confirmation LED light. So when the button was pushed, positive acknowledgement could be confirmed by a light turning on. It used the same sensor methodology for the button as it did for a video camera’s performance management.

With the solution in place for instant validation of the transport request, the SRMS service provider would need to review what other risks might now be present that would impair the people and the technology from responding to the need. The LED light might not come on for a variety of reasons; multiple authentication was needed.

It is imperative that security executives understand this critical juncture. This is where risk, strategy, planning and technical design must be driven by a level of competency in all disciplines. In this case, the team had knowledge of the rules engine of the VMS that they successfully leveraged. They then used their risk and technical expertise to deliver on a multi-authentication strategy using another aspect of the VMS: an alert email to a pre-defined distribution group. This email goes out when a light does not validate a response. But another redundancy layer was needed. Lives were at stake. If the servers were down or email was not delivered, then it was acknowledged that the camera could also deliver a message. Using the scripting language of the camera provider that was included in the I/O module, the team was able to go into the camera unit itself and create a rule that recognized the button signal was received, therefore x and y tasks could be executed. In this case both systems now can send email authentication.

Using SRMS protocols, this now was at the stage where a proof of concept could be designed that would effectively map to the use case, a subject for a future discussion.  However, by performing that last step, the client had the confidence to deploy the solution in 15 other locations because the SRMS provider and ER Team had made a business case; an ROI that fit the mission of the hospital and the metrics of performance.