Business Continuity of Databases....

Question

I would welcome some Oracle DBA assistance to scope a piece of audit work for tender around business continuity of an oracle database/environment (managed and supported by a 3rd party provider). We have had several “security” audits/assessments of this oracle database, and its environment, i.e. the infrastructure on which the database is installed/operated, and the front end web application. But I just think that’s only half the coverage requiredwhen it comes down to risk, there’s still operational issues namely we call this “business continuity” practices and controls.
Can anyone help provide a scope of the things to include in a business continuity type audit of an Oracle Database/DBA provider? Even if its just top level bullet points that I can research further it will help. If you have ever done one before - do you have a scope of the work, if you have ever had such an assessment/audit done of your own busienss continuity practices for oracle environments you manage and support, what was included in the review?

Answer 1

It doesn't make a lot of sense to talk about business continuity at a database level - it needs to be addressed at a service level. Database failure is only one of many things that could affect the availability of the service.
But in general you need to think about the following
- What constitutes loss of service? I.e what is the trigger point for invoking your business continuity plans? You may have several levels of this, Full outage, loss of functionality, loss of access based on geographic area/user group/access channel, each with different plans
- Who makes the decision to invoke the plan/bits of the plan i.e escalation routes?
- Coming up with a plan for the various scenarios, Not just technical (That is often the easy bit) - things like
- Communication - how do you let the team invoking the plan, and the users know? Bear in mind the problem may be with networks etc. Does everyone have access to the plan, even if computer systems are down?
- Training
- Physical considerations. Do you need a new server room? Somewhere to work?
- Financial. What will the financial impact be? Can you get funds to pay for staff, kit, accomodation etc if necessary?
- Testing. The plans need to be tested. Can be a hard sell to management to really take your systems out, but it's often the only way. And this time you know you can easily turn things back on!
- Afterwards. Do you need to do any processing after the event? For example for one of my systems in the case of losing an area node, the plan is to revert to paper recording, and contact other offices for any urgent lookups etc. This requires backfilling the data onto the system once it is back available. You need to plan the amount of resource necessary for this.
You can come up with hundreds of different scenarios if you get carried away. You will never be able to plan for them all, so pick the most likely. It should be a continuously evolving process anyway. For example we had to add policies around bird flu (Both for a genuine pandemic, and more likely scenario that offices are shut down) a year or 2 ago.
Carl