How do you get your product or service through a company that has an extensive RFP process because of a risk aversion business model? This risk aversion may be due to regulatory demands and corporate appetite for security models. Either way, you will need a preemptive strike, anticipating and addressing the risk needs. Whether the organization is a hospital, the DOD, a software company, or a financial institution, each has specific requirements and needs in the risk space. Review the regulatory requirements for that organization's business model, whether HIPAA, SOX, PCI or any numerous security regulatory demands.
Gone are the days of security sitting in web operations as network admins; security operations have moved into the risk space and the IT business. Many organizations are bringing security into many of the needed regulatory spaces that an organization has to work within. In most cases, they have separated risk assessments from security to encompass a larger risk space in business. And because of this expansion, product sales teams are missing the mark. Sales and Marketing have believed in the past that creating a white paper about security failures is a good idea, but it is not what security and risk professionals want. They want the meat and potatoes of your product offering, not fast food. I can tell you a white paper written by marketing is not a technical white paper. When security and risk teams have often asked for the technical specs, they get a white paper written by a marketing team with no understanding of what information is needed from that document. Have a technical white paper written on your product or service centered around Risk and Security controls (I.e., we encrypt our data in transit and at rest by using this method.) Suppose I were to identify the weakest substance in white papers. In that case, the authors are not speaking to those needing that information: “Not all people evaluating your product are going to be security and risk illiterate.”
I have seen many vendors sell the services to an interior product group and only get the product stuck in risk reviews and acceptance. Then, it could be abandoned because another product could demonstrate its risk and security measures, and they meet, at minimum, that industry's basic baseline security requirements. So, my advice to vendors is to prepare your product for review. Have a third-party risk assessment done on your application vulnerabilities. Address the security measures you do not have in place. Be transparent about your product vulnerabilities without giving away the secrets. Take a page out of the government's playbook. Redact and design the security review for non-confidential information.
Risk and Security and the IT business are all about identifying the risk.
What inherent risk will this product and service bring to my organization?
What resources will I have to supplement? And can I move that risk elsewhere?
Should the product's inherent risk come to light by the failure of security controls, will that bring brand damage to my organization? Will a breach trigger an audit? As you know, in business, the concerns can be brand damage and financial exposure through a failure of IT security controls. Organizations are reducing those concerns by using risk management principles beyond financial investment risk models, including risk management in the business IT space. So what does all this mean for sales?
Understanding the pain points of deploying your product or service in an organization, and by far the most important is getting the technical information to the right group initially. The key takeaway from this piece of information is this: What security controls does my product have? Remember, fewer security controls will increase the residual risk that an organization has to remediate in scoring risk. In terms of the organization you selling to, that could mean an increase in resources:
Man hours
Additional devices
And larger budgets.
Which, in the end, will torpedo your sale.
Comentarios