Any input is appreciated!
The DR plan doesn't have to be crazy complicated or long, but companies know there are deficiencies in your solution (they have them in their own), what they are wanting to be able to check is that you recognize the deficiencies and that you have thought about how to protect their data and their access to the system.
https://www.smartsheet.com/disaster-recovery-templates . -- Has lots of different templates to start from or get ideas from.
DR plans could be as simple as a couple of pages or as complex as a few hundred (though I find those useless personally). Answer the key questions, if you are using the cloud to host you are in luck because it simplifies things drastically. If you are self-hosting on your own co-located servers, then you are in for a bit more work. AWS and other clouds have products to assist you and also have templates to help you answer key questions usually. again you have to use what you need from it and customize it for your company though.
I am not trying to be a dick or anything and I hope it doesn't come across this way, but the DR plan for a small SaaS company with one or two employees will be drastically different then one with 100, 1000 or more employees. So having no clue what you do, what your product does, or what size deal this is it is hard to help point you to a specific template that might be more helpful.
Just a note on the RFP process (if you don't already know).
RFP's can be awesome, or they can suck the life out of your company. If you are answering an RFP for a < 5 figure/month deal it is almost always a losing proposition. Most true enterprises will spend 100-250k without needing an RFP. Government, or government agencies are different of course. But RFP's can take you a few weeks to put together properly so you have to weigh the opportunity against the cost to respond. Not saying don't do it just recognize and evaluate the costs. I responded to some RFPs where they required you to be on-site for the question/answer session or you would be disqualified, so now add in air travel and hotel rooms, plus the RFP costs. Some of our RFP's were really awesome and we spent a week putting an answer together and got a decent deal out of it, others we took a month and spent $15-20k only to be told we didn't qualify (when in reality the company already had their chosen vendor and just had to check the RFP bid box), so just guard your time and money when doing RFPs, and try to get a feel for the situation. And remember, probably a good 50% of the RFP process for enterprises is box checking, and once you get past that stage they'll be more open to working with you.
> If you are answering an RFP for a < 5 figure/month deal it is almost always a losing proposition.
I was against going through the first RFP at all but it worked out in the end. I don't necessarily disagree with this statement on face value but my experience illustrates that sometimes playing the long game can work out for you.
One thing I almost always would try if I lost the RFP was to get put on the approved vendors list. If you just try to get on the approved vendors list many times it is very hard with a ton of hoops to jump through with no real near term payoff. But if you answer an RFP and lose, ask to be put on the approved vendors list, many times you can get it with little issue (I did that a lot). What this does is minimizes friction for others in that company to hire your company or purchase your products later on, which can be super valuable.
The RFP process is definitely sucking the life out of us, but we're so close and likely have a good shot getting at least an interview.
Since it is a municipal event center, no matter what happens make sure you use this process to get on their approved/cleared vendors list. Even if you lose this bid the fact you are on the list will help you for the next one (with them or others). Plus you can say when you bid for other projects that you are on the approved vendors list for XYZ municipality. It adds validation to you and helps again check some boxes.
As for some more specifics for you, I'd have to spend some time digging around a little. But having won bids at many levels of the US government/agencies they do a lot more box checking than general businesses do, e.g. the businesses do more diligence usually the govt does more lip service to diligence (general rule not always true). So here, your DR plan will need to cover the key elements but probably not be super exhaustive, for example, contact/escalation lists are super important to government types. You are in luck in one way, most of the time, Govt types are a little more forgiving that things fail, as long as they have the list of who to blame, I mean call. :) . Seriously they will put more weight on process than on actual recovery most of the time, not that you should ignore recovery, but make sure you have answered the roles and responsibilities clearly as that will be focused on with government RFPs more. In enterprises they'll more likely challenge your backup, security etc before they attack your process or escalation sheet. These are just patterns I have seen of course, it could vary depending on the level of technicality and who is on the RFP review board. That brings up a point, always make sure you understand your audience, find out what the makeup of the review board is so you can cater to them a little. Good RFP review boards are a cross section of departments, including IT. But many times you'll find (especially in government projects) they'll be heavily focused from one area, so if you write an RFP that is super technical but the reviewers are all suits, you'll lose before you even submit. I know that is pretty obvious, but I have seen people screw this up a lot.
I wish you the best, everyone needs some luck paired with skill during an RFP.