Hello, I will give my take on this.
What things should be included in DRP? only backup restoration?
Can anyone share examples of the contents of the DRP and BCP ?
If i want to build to my company a DRP and a BCP what should i exactly do, a step by step guide.
As mentioned, the DRP aligns to what is determined in the BCP. It all starts with determining what the business needs are in the BCP. The DRP is written to meet the objectives in the BCP process.
Honestly, you can find templates online all over, but it really depends on the business and what the needs are, and sometimes a template may help you get started but ideally you need to
A. Making sure the documents is readable and concise (not fluffy)
B. Accessible when needed,
C. Useful as an aid a disaster
You don't want to be wasting everyones time just to check a box for an audit. This should be useful, otherwise it was a waste of everyones time and just false assurance. The details in my below response may help get started.
The individual(s) tasked with BCP/DRP development must:
1. Schedule Meetings! Meet with business leaders to review, (and sometimes discover) critical processes and systems used to support the business. I would suggest having folks from IT in meetings with business leaders from each department. Document these meetings. These initial meetings will kickoff the BCP and will determine the scope of the company BCP. This is the Business Impact Analysis (BIA), it is a component of building the BCP. Ideally, this should be done for every major change and at least annually.
During the BIA meetings ask:
"What are the key systems that you use to work?" (eg Email, Phones, internet connection, System A.. etc)
"How long can the business go without X process/system?"
"Are there any other systems or alternative processes that could run?"
Essentially, determine a number that can be defended logically (what the business need is vs. the risk appetite). This is important because high availability disaster recovery is expensive and after cost vs. benefit the implementation may not be worth it, and the business may have to accept a risk on having less availability for key systems due to cost considerations. This is known as the Recovery Time Objective (RTO), or frankly, how long can we go before business obligations demand it.
Next, ask about data loss considerations. Each system and process can be different. Examples could be if it's customer facing server farm hosting databases. Having a data loss in a SaaS system may not be tolerable if customer SLAs demand high availability. "What about print servers?" Maybe printer servers can be backed up much less often and those jobs can run once a week/month/not at all. Making sure you meet with all departments, is key as you may find caveats like "the accounting check printer needs higher availability!" Once you determine data loss considerations for systems, you have your Recovery Point Objective (RPO).2. OrganizeTake these details and organize them into tables based on what they are (infrastructure, systems, processes). I would start with an excel document that has the fields: department name, key item (system/process/etc), Business Purpose, RTO, RPO, Alternatives, and another for comments. Organize these details into a document(s), have the business leaders review the agreed upon details, and "ta-da" you have a BIA for that area!3. Build out a BCP DocumentThe overall BCP must document how the business will operate under an disaster. It may contain details on backup work facilities or procedures for calling in staff to work remote, how business decisions are made internally under a crisis, contact information of key executives and critical vendors, protocols on communications to clients and other procedures. Thus, it is important that users are trained and aware of the BCP and that it is reviewed and tested to evolve with the business and be useful in event of a disaster.4. Build out the DRP DocumentThe DRP is the document that will be used mainly by IT to support the business and meet the metrics determined during the BIA (RTOs, RPOs, etc).Ideally this document will have emergency procedures like the process to run off hot-site, and restoration/recovery procedures. It is important to test this with IT to confirm objectives can be met and find any gaps.5. Make Sure it Works! Test!!Document testing and gaps throughout the processes on a frequency determined by the business. Results of testing and summaries of these policies should be known to the individuals at the org tasked with risk management. As mentioned, acceptance of risks (eg. not backing up specific servers) should be documented as the business is signing off on IT not needing to support. These items should feed into the orgs risk management program.The ISACA website has audit program guides that may be helpful in looking at what attributes an auditor is looking for. Reviewing these attributes and "working backwards" to consider what details need to be included or discussed in a test of a DRP or BCP, may be worth looking into.Jordan