This contract document is also included in the discounted Proposal Kit Professional bundle. Order and download for $199.
Use the Disaster Recovery Plan template to create your company's policies and procedures for managing large disasters to ensure the continuity of the business and to minimize interruption of business operations.
Document Length: 20 Pages
Business proposal example I liken spending

money on your product to spending money designing a professional-looking resume. You get the money back so quickly that it’s actually a much more expensive decision to decide NOT to buy."

Nancy Saltz
Accounting & Computer Enterprises, Inc.
The actual document is delivered in the retail products as an editable template.
Produced by:
Proposal Kit
Category:
Software > Computer Software > Business & Productivity Software
Price:
$199 USD
 
 
Proposal Kit reviews4.9 stars, based on over 700 reviews
Related documents may be used in conjunction with this document depending on your situation. Many related documents are intended for use as part of a contract management system.

Related Documents:
Disaster Recovery Plan
Disclaimers: Proposal Kit, Inc. makes no warranty and accepts no responsibility for suitability of any materials to licensees business. Proposal Kit, Inc. assumes no responsibility or liability for errors or inaccuracies. Licensee accepts all responsibility for results obtained. Information included is not legal advice. Use of any supplied materials constitutes acceptance and understanding of these disclaimers.

Writing the Disaster Recovery Plan document

Disaster Recovery Plan DRP THE DRP PROJECT DOCUMENT TITLE Author Title company name current date Document Version Control Information V 1. 0 1. Introduction

1 Purpose of this document Objectives Insert the purpose of this document its objectives and its intended audience. Example. The purpose of this document is to formally recognize and codify the policies and procedures company name wishes to enact in order to both safeguard the Companys Business and ensure its continuity in the event of disaster or other event. The goals and objectives listed in this plan are meant to allow the Company to minimize any interruption to its businesses and individual recovery plans may be enacted to safeguard and restore specific Company resources assets or business process. In order to continue its business operations The Company provides its Employees Staff and Vendors this Disaster Recovery Plan DRP as an overview of the required steps and policies to be enacted following an emergency. 1 Scope of Document Insert description of the scope of this Disaster Recovery Plan and whether this covers the entire company; specific business unit or department; or shall be governed or supersedes other policy documents that may already be in place. 1. 21 Scope Constraints

Insert constraints such as schedules costs interactions overview or any other information relevant to the testing of the development requirements. 1 Goals of this Plan Insert an overview or brief description of the product software or other desired end result that is being tested under this Disaster Recovery Plan. 1 Business Context Insert an overview of the business or organizations impacted by this Disaster Recovery Plan. Include the business or organizations critical components and reliance on specific vendors services or other assets. Note. This section will be primarily used to set priorities and identify and classify risk to the Company as it pertains to recovery from Disaster Event. While it is generally understood that every possible manner in which Company or its continuity could be impacted by an event would not be outlined here this section is intended to quickly communicate in plain language how what and who is important to the business in the event of disaster. Following disaster and the enactment of this plan it is important that personnel involved in the coordination and recovery from disaster event understand the impact to the Companys operations and the dependent business processes so they may better identify further business interruption that may occur from enactment of the plan. e. g. additional or cascading business failures due to missing resources or recovery efforts.

1 Goals Defined The Overall Goals of the DRP are to provide easy and accessible methods for company name to recover from any of the following events or occurrences. * Loss of hardware and critical equipment * Loss of critical infrastructure or personnel * Loss or critical vendors dependent services or other up stream service providers. * Loss of installed software and applications see Company Software Disaster Recovery Plan

* Containment of secondary damage resultant from or the proximate cause of disaster or other event. * Identification and containment of security risks and potential secondary damage resultant from the loss of critical resource following disaster or other event. * Loss of software installation disks packages or other media including software proof of license or ownership * Loss of any other asset resource vendor direct service provider data information or any other asset deemed resource critical to the continuity of the Companys business. 1 References and Reference Material Insert list of all reference documents and other materials related to the Software Disaster Recovery Plan. References will often include but are not limited to. * Company Business Continuation Plan BCP * Company Software Disaster Recovery Plan SDRP * Company Recovery Point Objectives RPO

* Company Recovery Time Objectives RTO 1 Documentation Items Insert references to documentation or contact lists which may include but are not limited to. * Company Critical Services List * Company Critical Vendors List * Company Critical Location List

* Company Department Head and Manager List * Company Disaster Response Team List 2. Plan Components 2 Software Inventory Catalog and Control A centralized Software Database and Control System SDCS for inventory is maintained for all software licensed by the Company. A complete copy of all SDCS data is maintained off company property and updated on regular basis. The SDCS shall be the first resource the Company utilizes in the event of critical Software failure or interruption. 2 Hardware Inventory Catalog and Control A centralized Critical Infrastructure and Control System CICS for all assets deemed necessary and critical to the continuity of the Company and its business is maintained for all assets owned by the Company. A complete copy of all CICS data is maintained off company property and updated on regular basis. The CICS shall be the first resource the Company utilizes in the event of critical hardware or infrastructure failure or interruption. Information contained in the CICS shall contain but is not limited to. * Descriptions of Company infrastructure and dependent equipment vendors and services.

* Inventory and locations of all company assets deemed critical and the locations of all spare back up or reserve equipment. * Lists of all Company personnel who have access or the ability to interact request or otherwise direct vendors to act on Companys behalf. e. g. Account Owners or Administrators * Directing Staff to any additional manuals and documentation. Insert additional descriptions of the tasks to be performed. 2 Inventory Audits

Company shall conduct periodic audits of all resources to ensure compliance and integrity of our inventory data. Regular checks of employee hardware software and license counts may be conducted on random basis. The Company will also conduct complete audit annually and compare it to the CICS. Insert additional descriptions of the tasks to be performed. 2 Off site Storage Off site storage of all information contained in the CICS shall be facilitated by the Company. This includes whenever possible copies of all purchase information service agreements warranties installation media documentation licenses serials and other relevant information. Regardless of whether multiple copies of the same asset or resource are being utilized it shall be necessary to store copies of each relevant warranty service agreement End user License Agreement EULA or any other information that may be specific to an individual or serialized asset. Data will be updated on regular basis and more than one member of the Incident Response Team shall have access to this storage at all times. Insert additional descriptions of the tasks to be performed. 2 Proof of Ownership All original supporting Proof of Ownership documents shall be retained off site while the Company shall retain copies of Proof of Ownership onsite for auditing purposes. Insert additional descriptions of the tasks to be performed. 2 Documentation

Whenever possible photocopies or reproductions of all documentation should be made for employee use while the originals are stored off site. Insert additional descriptions of the tasks to be performed. 2 Plan Objectives This Disaster Recovery Plan may be superseded by actions taken by individual Company Disaster Recovery Plans such as those governing Software Employees and Personnel utilizing alternate locations or other specific plans that are part of the Companys Business Continuity Plan BCP. The following shall be considered to be objectives of the Disaster Recovery Plan. * Safeguard the lives and personal safety of all Company employees and other staff members. * Gain assistance direction and support from civil services such as fire police and emergency management. * Secure information and establish channels of communications concerning natural disaster event from fire police and emergency management in order to tie into Company Command and Communication Centers. * Company Recovery Point Objectives RPO The Company Recovery Point Objective RPO shall be considered point in time in which operations must be restored in order to be acceptable to Company within the context of the following.

1. The difference in time between back up resource or asset and the disruptive event that could occur. 2. The Companys tolerance for loss of data and continued operations. 3. The Companys tolerance for risk and exposure to risk during disaster event 4. The Companys exposure to cost and financial loss due to restoration of data and or time spent recovering or re entering data. * Company Recovery Time Objective RTO The Company Recovery Time Objective RTO shall be the acceptable boundary of time in which recovery efforts must be accomplished in order to meet the expectations the Company has determined critical to meet when disaster event or business interruption occurs. * An individual RTO may be established for each process covered under this recovery plan as established during the Company Business Impact Analysis BIA for each department. An RTO may also encompass series of processes as well. All RTOs are to be determined by Senior Management and or the Executive Team.

3 Implementation of the Plan Insert the overall objectives for implementation of the plan. Your Disaster Recovery Plan may contain several different approaches for certain events large or small. 3 Definition of Disaster Event A disaster event shall be defined as an event or occurrence which results in the sudden or unexpected loss of key resources functions software licenses components dependencies or any other failure of an asset deemed critical to the Companys continued business. An event may include but is not limited to.

* Fire or Smoke Damage * Floods or Water Damage * Power and Utility Failures * Natural Disasters * Terrorist Attacks * Theft or Criminal Activity * Computer Viruses or Security Breaches

* Hardware and Equipment Failures * Human Error or Omissions * Legal Issues * Riots Strikes and Civil Disturbances * Planned Maintenance and Testing * Unplanned Maintenance and Testing

3 Notification of an Event In the event of an occurrence of any event or disaster regardless if it is known to impact single user department or the entire company the following people must be immediately notified. Insert notification information here including back up secondary notification information. specific person will be noted as Disaster Recovery Coordinator which you will want specify who in your organization must take on that role. Be sure to specify all back up and secondary notifications that must take place as well as who the role of Disaster Recovery Coordinator falls to in the event that the primary point of contact cannot be reached. 3 Event Recovery Strategy Business interruption events or disaster have different levels of severity or degrees of impact to the Company. The strategies procedures and objectives of this Business Continuity Plan outline plan of action that deals with the worst case scenario that the Company could face should such an event occur. Insert summary for the specific strategy the Company wishes to employ for managing disaster events. The Company recovery strategy is high level overview of the recovery process that the Company will enact if disaster event or interruption occurs. This strategy shall include but is not limited to. * Current Company Command and Communication Centers

* Alternate Company Command and Communication Centers * Use of alternate business operations methods or other alternative business processes. * Use of alternate data processing or processing centers. * Use of alternate data and voice communications. * Descriptions for when to move critical data to off site storage facilities and vendors and what control document or plan is to be enacted following such decision.

Writing the Essential Functions Priority List document (alternate or related contract document)

company name Department Program Prioritized Essential Functions Essential functions are those organizational functions and activities that must be continued under any and all circumstances. Priority Essential Functions Key Personnel Required; List Alternates Systems Needed to Perform Function Current Location of System Alternate Location. If office is closed how can function be performed. How performed with limited staff. Leadership Leadership describes the order of succession to key positions within the organization. Orders should be of sufficient depth to ensure the organizations ability to manage and direct its essential functions and operations. Please list job titles in the table not employee names. Department Leadership Vital Files Records and Databases

This section addresses the departments vital files records and databases to include classified or sensitive data which are necessary to perform essential functions and activities and to reconstitute normal operations after the emergency ceases.

How do you write a Continuity Plan Worksheet document? (alternate or related contract document)

company name ACTION PLAN CONTINUITY OF OPERATIONS EVENT. DEPARTMENT. IMMEDIATELY ACTION WHO COMMENTS

WITHIN HOURS ACTION WHO COMMENTS ONGOING ACTION WHO COMMENTS

Writing the Software Disaster Recovery Plan document (alternate or related contract document)

Software Disaster Recovery Plan SDRP THE SDRP PROJECT DOCUMENT TITLE Author Title company name

current date Document Version Control Information V 1. 0 1. Introduction 1 Purpose of this document Objectives

Insert the purpose of this document its objectives and its intended audience. Example. The purpose of this document is to formally recognize and codify the policies and procedures company name wishes to enact in order to both safeguard the Companys investment in their Software and to ensure that in the event of disaster the Company can minimize any interruption to its businesses. The Company recognizes that its Software is an important part of its continued business operations and this plan provides company name Employees Staff and Vendors this Software Disaster Recovery Plan SDRP as an overview of the required steps and policies to be enacted following an emergency. 1 Scope of Document Insert description of the scope of this Software Disaster Recovery Plan. Describe whether this covers the entire company or specific business unit or department and whether this plan shall be governed by or supersedes other policy documents that may already be in place. 1. Scope Constraints Insert constraints such as schedules costs interactions overview or any other information relevant to the Software Disaster Recovery Plan. 1 Goals of this Plan

Insert an overview or brief description of the product software or other desired end result that is included in this Software Disaster Recovery Plan. 1 Business Context Insert an overview of the business or organizations impacted by this Software Disaster Recovery Plan. Include the business or organizations critical components and reliance on Software. Note. This section will be primarily used to set priorities and identify and classify risk to the Company as it pertains to recovery from Disaster Event. 1 Goals Defined The Overall Goals of the SDRP are to provide easy and accessible methods for company name to recover from any of the following events or occurrences. * Loss of installed software and applications * Loss of updates patches fixes or other required upgrades * Loss of installation disks packages or other media * Loss of software proof of license or ownership

* Loss of software inventory software inventory data or other DRM Digital Rights Management information 1 References and Reference Material Insert list of all reference documents and other materials related to the Software Disaster Recovery Plan. References will often include but are not limited to. * Company Business Continuation Plan BCP * Company Disaster Recovery Plan DRP

* Company Recovery Point Objectives RPO * Company Recovery Time Objectives RTO * Company Computer Use Policies * Software Acquisition Plan * Software Management Plan 1 Documentation Items Insert references to documentation including but not limited to.

* Software Requirements Specification SRS * Software Design Specification SDS * Software Development Plan SDP * Software Installation Guides * Software User Guides * Software Features Guides * Software Bug Error Correction or Defect Removal Guides

2. Plan Components 2 Inventory Catalog and Control A centralized Software Database and Control System SDCS for inventory shall be maintained for all software licensed by the Company. Before new software can be put into service it must be entered into the SDCS by the IT department. Regular audits of employee computers will be performed to ensure compliance. complete copy of all SDCS data shall be maintained off Company property and updated on regular basis. 2. Check in Procedures Software shall undergo check in procedure including all downloadable virtual online ASP or hosted application forms. All software regardless of its form or the media on which it is delivered shall be entered in the SDCS. This procedure is subject to change based on the individual software licensing requirements; however all software shall have record of entry in the SDCS regardless of its physical form.

Check in shall include but is not limited to. * Providing proof of purchase. * Providing proof of license. * Providing proof of Company license and not individual license. * Providing all installation disks media manuals and collateral materials. * Directing IT staff to any online manuals and documentation.

* Providing original downloads and installation files for all software and licenses delivered virtually. * Providing copies of all licenses serial numbers activation keys IDs passwords logins or other information required to run the software or application. Submitting complete set of information concerning the software you want to license and install will ensure faster entry into the SDCS and approval for the use of the software. Insert additional descriptions of the tasks to be performed. 2 Inventory Audits Company shall conduct periodic audits of all software licenses to ensure compliance and integrity of our software inventory data. Regular checks of employee software and license counts may be conducted on random basis. The Company will also conduct complete Software and License Audit annually and compare it to the SDCS.

Insert additional descriptions of the tasks to be performed. 2 Off site Storage Off site storage of all information contained in the SDCS shall be facilitated by the IT Department. This includes whenever possible copies of all installation media documentation licenses serial numbers and other relevant information. In the case where multiple copies of the same software are being utilized it is only necessary to store single copy of each version off site. Data will be updated on regular basis and more than one member of the Incident Response Team shall have access to this storage at all times. Insert additional descriptions of the tasks to be performed. 2 Proof of Ownership All original supporting Proof of Ownership documents shall be retained off site while the Company shall retain copies of Proof of Ownership onsite for auditing purposes.

Insert additional descriptions of the tasks to be performed. 2 Documentation Whenever possible photocopies or reproductions of all documentation should be made for employee use while the originals are stored off site. Insert additional descriptions of the tasks to be performed. 2 Plan Objectives This Software Disaster Recovery Plan may be superseded by actions required by the Company Disaster Recovery Plan DRP and is part of the Companys Business Continuity Plan BCP. The following shall be considered to be objectives of the Software Disaster Recovery Plan. * Company Recovery Point Objective RPO The Company Recovery Point Objective RPO shall be considered point in time at which data must be restored in order to be acceptable to Company within the context of the following. 1. The difference in time between back up resource or asset and the disruptive event that could occur.

2. The Companys tolerance for loss of data and continued operations. 3. The Companys tolerance for risk and exposure to risk during disaster event. 4. The Companys exposure to cost and financial loss due to restoration of data and or time spent recovering or re entering data. * Company Recovery Time Objective RTO The Company Recovery Time Objective RTO shall be the acceptable boundary of time in which recovery efforts must be accomplished in order to meet the expectations the Company has determined critical when disaster event or business interruption occurs. * An individual RTO may be established for each process covered under this recovery plan as established during the Company Business Impact Analysis BIA for each department. An RTO may encompass series of processes as well. All RTOs are to be determined by Senior Management and or the Executive Team.

3. Implementation of the Plan Insert the overall objectives for implementation of the plan. Your Software Disaster Recovery Plan may contain several different approaches for certain events large or small. 3 Definition of Software Disaster Event A software disaster event shall be defined as an event or occurrence that results in the sudden or unexpected loss of key software licenses components or dependencies; or any other failure. An event may include but is not limited to. * Fire or smoke damage * Floods or water damage * Power and utility failures

* Natural disasters * Terrorist attacks * Theft or criminal activity * Computer viruses or security breaches * Hardware and equipment failures * Human error or omissions

* Legal issues * Riots strikes and civil disturbances * Planned maintenance and testing * Unplanned maintenance and testing 3 Notification of an Event In the event of an occurrence of any event or disaster regardless if it is known to impact single user department or the entire company the following people must be immediately notified. Insert notification information here including back up secondary notification information. specific person will be noted as Disaster Recovery Coordinator you will want to specify who in your organization must take on that role. Be sure to specify all back up and secondary notifications that must take place as well as who the role of Disaster Recovery Coordinator falls to in the event that the primary point of contact cannot be reached.

3 Event Recovery Timelines Within the first hours hours after notification of an event the Disaster Recovery Coordinator will take the following steps. 1. Assess all damage to Company and its operations including the determination of all affected locations and resources. Special consideration should be made for all dependent systems and software which are not yet impacted by an event but share dependency with an impacted software or resource. 2. Consult all relevant Company Recovery Time Objectives RTO and Company Recovery Point Objectives RPO. 3. Notify Senior Management and or the proper Executives.

4. Notify all support staff responsible for implementing this plan and recovery services including all vendors who have responsibility for implementing the Company Business Continuity Plan BCP. 5. Make decisions regarding containing the damage from the disaster event and decide whether recovery is to be enacted or whether back up resources must be employed. Within the first hours hours after notification of an event the Disaster Recovery Coordinator will take the following steps. 1. If the disaster event impacts Company customers and after successful contact with Senior Management or Executives contact all Customer Support Managers to provide them with information concerning service restrictions limitations or other downtime that may occur. 2. Notify all disaster recovery vendors services or off site storage providers as deemed necessary. 3. Schedule all support staff or employees with disaster recovery duties and task them with recovery efforts. 4. Schedule obtaining all relevant back up data software manuals and other required resources. 5. Contact all Managers Supervisors or Department Heads impacted by the Disaster Event.

Within the first hours hours after notification of an event the Disaster Recovery Coordinator will take the following steps. 1. Provide Senior Management and or the proper Executives with an updated assessment recovery progress report and an estimate timeline for the recovery schedule. 2. In the case of critical software and systems not immediately recoverable the Disaster Recovery Coordinator shall have discretion to enact emergency funding up to Insert Disaster Recovery Funding Amount to cover the procurement of resources. 3. Review all software support contracts and contact all software vendors to alert them for emergency assistance temporary license keys or to enact provisions of support agreements that may exist between the vendor and Company. 4. Proceed with acquisition of back up resources if deemed necessary at this time. 5. Proceed with activation of alternate resources sites locations or other critical resources. 6. Secure all recovery logs. 7. Secure an alternate base of operations if deemed necessary. 8. Carry out Company wide communication subject to Senior Management and or Executive approval.

9. Carry out customer communication subject to Senior Management and or Executive approval. Within the first hours hours after notification of an event the Disaster Recovery Coordinator will take the following steps. 1. Provide Senior Management and or the proper Executives with an updated assessment recovery progress report and an estimate timeline for the recovery schedule. 2. Begin installation and testing of all software and critical applications. 3. Begin restoration or reloading of all critical or dependent data.

4. Enact monitoring of all restored software and operation of software to verify data integrity and operational continuity. 5. Coordinate with Customer Support Managers and Department Heads to confirm successful resumption of schedules and functionality of restored software and systems. Within days days after successful restoration from an event the Disaster Recovery Coordinator will take the following steps. 1. Provide Senior Management and or the proper Executives with an updated assessment and recovery progress report noting any outstanding reduction in functionality loss of data or an extended estimate timeline for the recovery of such items subject to each relevant RPO. The Disaster Recovery Coordinator will also coordinate evaluation and certification that each objective in the Companys RPO for an impacted business process has been met. 2. Store all recovery logs.

3. Provide to Senior Management and or the proper Executives Disaster Recovery Report DRR. 4. Upon successful restoration of all critical software and systems complete new re assessment of all systems and software associated with or relating to the recovery. 5. Complete an assessment of all vendor performance. 6. Complete an assessment of all support staff performance related to the recovery and enactment of the Software Disaster Recovery Plan. 7. If recovery efforts included use of off site or alternate locations resources or vendors work with Senior Management and or Executives to outline plan for restoration and normalization of usage of such assets and resources including additional back up e. g. allowing for back ups for the back ups in essence resources to be deployed. 3 Software Recovery Plan Testing Insert the objectives and requirements for testing to ensure that the plan operates correctly within the parameters set forth by the Company and the provisions of its BCP.

3 Plan Objectives vs. Mandates The objectives set forth in RPO and RTO objectives should be considered the overall goals of the Company in disaster event. They are not exact mandates. Individual department policies and procedures contingency plans and other disaster recovery plans may outline additional instructions to be followed. 3 Plan Performance Testing Insert the objectives and requirements for testing to ensure that the plan operates correctly in regard to normal operation response and execution times scalability portability and all other performance requirements within the business environment. 3 Plan Regression Testing Insert the objectives and requirements for testing to ensure that any changes applied to the plan do not affect functions previously tested. 3 Plan Acceptance Testing

Insert the objectives and requirements for testing to ensure that the plan meets all criteria and deliverables as set forth in the Companys Business Continuity Plan BCP. The Acceptance Testing is important to ensure that all requirements are met and that all components modules hardware requirements and recovery and restore operations function and that viable plan exists to demonstrate such functionality for customer. 4. Plan Testing Process and Methods Insert the specific testing process and methods to be used in performing each test activity. In this section you will describe and define each type of test that the Software Disaster Recovery Plan contains. You may attach additional exhibits to this section if your testing plan requires them. 5. Test Deliverables Insert the specific deliverables and documents that are to be delivered from the testing process. Test deliverables may include incremental data or data derived from incomplete tests. Typical test deliverables include but are not limited to. * Individual RTO RPO Test Summary Reports * Group Department RTO RPO Summary Reports

* Individual and Combined Test Logs * Test Metrics and Benchmark Reports * Test Incident Reports 6. Testing Task and Requirements List A description of tasks and the skills required for performing testing as part of the deliverables. Examples. 6 Task Name Insert description here. 6 Responsibility for Task

Insert description here. 6 Resources Required for Task Insert description here. 6 Schedule or Timeline for Task Insert description here.

7. Testing Hardware and Environmental Requirements List A description of the hardware and environmental requirements for performing testing as part of the deliverables. Examples. 7 Hardware Requirement Name Insert description here. 7 Software Requirement Name

Insert description here. 7 Security Resources Requirement Name Insert description here. 7 Specific Tools Requirement Name Insert description here. 7 Specific Documentation Requirement Name Insert description here. 7 Specific Risks and Assumptions

Insert description here. Focus on restraints such as resource availability time constraints staff and developer availability and all other external factors that can influence testing. 7. Risk and Assumption Contingency Plan Insert description of the contingency plan for each item listed above. 8. Change Request and Management A description of the Software Disaster Recovery Plan change request and change management procedure. Describe the process that must be followed for submission review and authorization for all requests for change to the Software Disaster Recovery Plan or any change to any part of the deliverables. 9. Approval for Software Disaster Recovery Plan

A description of the personnel authorized to approve the Software Disaster Recovery Plan. Their names titles and signatures must accompany this document. approved approver Title Date when the contact was signed approved approver Title

Date when the contact was signed approved approver Title Date when the contact was signed approved approver Title Date when the contact was signed

10. Appendices A description of all other supporting information required for the understanding and execution of the Software Disaster Recovery Plan and requirements. All Software Disaster Recovery Plan documents require the following two appendices. 10 Definitions Acronyms Abbreviations A description of the definitions of important terms abbreviations and acronyms. This may also include Glossary of terms.

10 References A listing of all citations to all documents and meetings referenced or used in the preparation of this Software Disaster Recovery Plan. Customer Initials Developer Initials

A Document from Contract Pack

The editable Disaster Recovery Plan template - complete with the actual formatting and layout is available in the retail Contract Packs.
Proposal Kit on BBB
Proposal Kit
Proposal Kit on FaceBook
Create winning business proposals & contracts with minimal effort and cost. Downloadable proposal software, proposal templates, legal contracts and sample proposals.
© 1997 - 2018, Proposal Kit, Inc. All rights reserved.
Proposal Kit

Create winning business proposals & contracts with minimal effort and cost. Proposal software, proposal templates, legal contracts and sample proposals.