Recently I had a conversation with a CSO who discussed the disconnect between a technology vendor’s (manufacturer) product roadmap and his organization’s needs. “I go to these conferences and it seems they are creating solutions without any understanding of how we are organized, our organizational measures of performance, or our challenges with risk and resilience,” he said. “They create solutions that are looking for a problem to solve!”

This is not unusual. What is often misunderstood is the ecosystem in and around technology vendors and what is supposed to occur in those transactions of value.

Most technology vendors hope to penetrate the risk, resilience and security markets through the “channel:” consultants, value-added resellers (VARs) and system integrators. Their business model depends on three things:

  1. Convincing the channel that their product’s features and functions are compelling.

  2. Convincing the channel that the investment in training and certification is worth the return.

  3. Getting the channel to promote the product in their selling efforts.

Note there are gaping holes in these three areas:

  1. There are usually no verifiable studies on the organizational or security risks that are mitigated by the solution.

  2. There are no consultative approaches (not sales approaches) that are provided.

  3. There is no feedback loop built into the client process including assessment results and post implementation direction to the technology vendor.

As we move into a new era of security leadership, business and security risks must be documented and studied. People, process and technology can be measured. Qualitative and quantitative data is collected and can form the foundation of a value argument to the organization.

This can be a big adjustment to the ecosystem of consultants, VARs, integrators and technology vendors and how they transact their business.

One of the first adjustments is understanding how leadership and culture impacts people and process in an organization. Very few consultants are positioned to assist in this. But, if ignored, it jeopardizes the future of the risk management program and the success of the technology that is implemented.

The second is an as-is analysis of how the program functions. Core processes must be documented, including current measures of performance up and down the organizational hierarchy.

The third is a risk, threat and vulnerability (RTV) assessment that is infused with a technology foundation. Why? Your risks, threats and vulnerabilities include how that technology is used and how it performs. We had one hospital client that had all the important pieces: access control, video and IP intercom, but their time-to-action for a security officer to get notified of a duress signal was three minutes. This not only was a risk and liability, but it was also a process and technology problem.

Fourth: a technology roadmap. This is really about the knowing product roadmaps and closing the feedback loop back to the technology vendors for the long term benefit of the clients.

Finally: performance management. Measures of performance in the assessment often must be initiated, if lacking, and expanded if they do exist to include measures of people, process and technology. This requires a long-term relationship.

Emerging Security Risk Management Services providers should be evaluated against these pillars of value rather than their ability to just sell and service a product. Technology vendors will benefit from SRMS providers sharing this information to inform future products. And enterprise security executives and their programs will benefit from a fully aligned program with their organization that mitigates risk and drives value.