The information security industry is as fast paced now as the PC industry was in the early 1980s. A lot of innovation, consolidation, shooting star success and abject failure are taking place. With a well written request for proposal (RFP), you can take advantage of the latest industry developments and avoid the burden of unsupported technologies.
An RFP provides a framework in which the uncertainty of a vendor's future and the value of their product can be measured. The goals of an RFP are to provide the lowest initial cost, the greatest cost improvements over the desired technology lifetime and a framework for substantial business process improvement.
Apply Six Sigma principles to your RFP
The world of Six Sigma Quality Improvement provides some ...
To continue reading for free, register below or login
To read more you must become a member of SearchSecurity.com
guidance for ideal RFP operation. The first three steps in Six Sigma are define, measure and analyze, and that is precisely what the RFP should do. The first step in RFP creation is to prioritize the objectives of the business and, by extension, the project. You then take the prioritized project criteria and determine how they may be best measured. Lastly, the RFP document provides a mechanism for analyzing the measured criteria.
The RFP has several important sections in order to meet the Six Sigma based framework I just described:
Project definition
First, provide a clear definition of the project. It is crucial for the vendor and project team members to understand the underlying business case for the project; that is, why the project is being attempted. Also describe how the enterprise came to the project and the deliverables expected from the project and by extension the vendor.
Project requirements
The next section of the RFP contains the specific requirements, including the prioritized measurement criteria.
The requirements are broken down as follows:
- Functional requirements -- Those requirements that directly support the business objectives for the project.
- Non-functional requirements -- The technical requirements that define or describe how the system should behave or what is required to keep the system running securely and reliably. This includes such items as failover, clustering, roll up reporting, etc.
- Technical architecture requirements -- Backbone technical architecture requirements are requested from the vendor. This includes server operating systems, switching and routing needs, backup solutions, etc.
Measurement criteria might be, for example, "must be able to handle 2,000 e-mails per hour, integrate with GroupWise and provide detailed user action logs for every e-mail that is sent to the Help Desk." The criteria are then prioritized to reflect that the solution MUST integrate with GroupWise and handle 2,000 e-mails per hour minimum. Less importance is given to the logs. The easiest way to prioritize these items is to assign a weighting number in the measurement criteria checklist. For example, a three might be given to GroupWise integration, a two to 2,000 e-mails per hour and one to the logs.
Vendor questions
The "Vendor questions" section of the RFP tends to receive the most marketing fluff from vendors. You must be specific in your requests for information. Use this section to ask vendors to describe how their products will meet the project's needs. Ask what support structure and technical architecture is required to make their solution effective in your enterprise. You must be specific in your requests for information here. When you are NOT specific you are much more likely to receive fluff. Being specific in your requests gets you closer to the actual information you really need for evaluation. Ask for cost quotes in specific deployment increments and state what the final deployment is likely to look like.
There is one more crucial request to make of vendors. It is often overlooked, much to the peril of enterprises. That is the question of the vendor's financial stability and ability. Ask them for their sales numbers, financing and venture capital funding. The vendor's answers here in the RFP process will tell you several things including their stability, their honesty and forthrightness, and their long term viability. Independently of the RFP, have your purchasing department obtain the vendor's Dun and Bradstreet ratings.
There are lots of new vendors with compelling technologies. This section of the RFP will help you determine whether they will be here in three years, the possibilities of the vendor being bought out by a competitor or simply going out of business. In the fast paced world of enterprise security this last section is the closest you are likely to come to working with a crystal ball. It has become one of the most crucial to ensure that the enterprise I work for has not become burdened with unsupported technology.
Finally, give the vendor a deadline to return the completed RFP. Be reasonable based on project complexity, internal time commitments (to your management) and how busy the vendor is.
A good RFP returned from the vendor should allow you to make intelligent decisions of which vendors to bring in for a "road test." You should NOT have to go back to the vendors repeatedly for the same information or clarifications of the same information. If you can't get clear responses from an RFP, can you trust that they will respond clearly to a major support request?
About the author
Tom Bowers, CISSP, PMP, CEH, is a technical editor for Information Security and a manager of security operations at a pharmaceutical company.
