The request for proposal (RFP) is a common tool used by customer organizations to get pricing comparisons from various solution providers. Responding solution provider submissions serve as a starting point for decision makers at the organization, as the proposals they receive help to determine which vendors or solution providers are worth considering, and which can be ruled out right off the bat. Positioning security in an RFP can be a challenge for an organization, so solution providers may need to provide assistance to ensure their customer companies get the best possible submissions back.The role of security in request for proposals (RFPs)
When helping clients write RFPs, a good place to start is by acknowledging any industry-specific requirements. These requirements can highlight the security or compliance needs in a particular vertical market. For example, if a healthcare company is interested in secure hosted email, there will be a HIPAA compliance angle to take into account. If a customer company is publicly held, there may be specific retention and archiving guidelines that apply.
As a result of these industry-specific standards and compliance regulations, security now encompasses multiple facets of a customer's infrastructure. This means a more in-depth understanding of various regulations is required to write an effective security RFP. Security should not be a simple line-item; it requires internal buy-in within an organization for successful
A common approach to justifying security services is stressing cost avoidance. For example, "If we don't spend X now, it will cost us Y later." Amid the current economic circumstances, capital expenses are under increased scrutiny, even if they fulfill a significant need. When helping customers with security RFPs, it pays to call attention to purchasing methods or limitations in order to educate responding solution providers. For example, will the customer consider leasing hardware versus buying? Is there a preference for a hosted offering if it is cost-competitive?
A solution provider guiding a customer through RFP development can ensure costs and payment options are complete in RFP submissions by fleshing out some of these parameters and including them where appropriate. If there are additional policy limitations based on product or service types, those should be included as well. For example, if a hosted security solution is out of the question due to a customer's internal security policy, then that should be noted in the RFP.
If the customer is specifically writing an RFP geared toward a service offering, then there are different metrics at play. By targeting services, the customer is most likely trying to reduce capital expenditures (i.e. purchasing new hardware) and to spread the cost of the service over a given amount of time (i.e. operating expense). Consequently, it is important to instruct the customer to highlight service feature requirements in the RFP that address primary needs, such as SLAs and response times.Using collaboration as a tool
In a down economy, collaboration is becoming a key factor in the RFP creation process. Whether it's leveraging business/technology partners to ensure requirements are accurately documented, or working with customers' internal business teams to make sure the document reflects a varied set of priorities, solution providers should ensure that customers' RFPs are concise and fully address their needs.
It is extremely helpful to know what is driving the need for the RFP, and collaborating with outside sources can help do just that. Speak to business contacts in the customers' specific verticals. Is there any pending legislation that might be driving the RFP? Even better, are there any security incidents that may be serving as the impetus for the RFP? For example, perhaps a data breach at a competitor's company has spurred an organization to action and resulted in an RFP for a security-scanning service. An inside perspective is always helpful to provide crucial clues for product or service positioning. However, when working with third parties to help develop an RFP, ensure the organization does not have any conflicting provisions for disclosing access to potentially sensitive data.
Solution providers should also get information from their customers' internal teams. When working with an organization to distill requirements into an RFP, it is helpful to get perspective. Collaborative efforts with RFPs can be mutually beneficial for those involved and result in more balanced submissions. If a security RFP is written solely by the operations team, for example, but also directly impacts the customer service team, the lack of input will most likely jeopardize the efficacy of any security implementation, let alone the resulting submissions.
By balancing the business, technology and security needs of a customer company, an RFP can be broken down to its distinct motivational pieces. For example, if an RFP is specifying a "security gateway" but supplies minimal implementation or use-case details, how can a solution provider help the customer narrow down what security aspects should be addressed? By working with the internal teams and other knowledge resources, solution providers can target the essential need for the hardware as it would fit into customers' environments and help to further clarify the RFP.
Finally, when incorporating security initiatives at any company, there should be an additional value to the business above and beyond increased security. In developing an RFP, it is worth sharing some metrics that will measure the success of the implementation that is eventually put in place. Too often an RFP submission can focus on price and not demonstrate the value of the product/service being presented. By encouraging the customer to share some of the metrics being sought after, the responding solution providers can more easily identify an appropriate solution that meets the customer need, and also create a positive interaction over the long-term.About the author:
Pete Sclafani has over 10 years of experience in Silicon Valley high tech and is CIO and co-founder of 6connect (www.6connect.net), a datacenter infrastructure provider in San Jose. Founded in 2009, 6connect partners directly with datacenter operators to automate and integrate facility information into a white-labeled cloud infrastructure for their customers. Prior to 6connect, Pete spearheaded IS strategy and product development at UnitedLayer, a San Francisco-based managed colocation provider. Previously, Pete actively contributed to organizations in social networking, nonprofit, embedded hardware and technology services.
This was first published in September 2009