Auditing BCP

Could they really recover?

Auditing business continuity is the same. The question is simple: could the organisation recover its critical processes within acceptable time and data loss if something went badly wrong? The plan document is only the start.

That breaks down into five questions:

1. Are critical processes and recovery objectives identified and approved by the business? If not, the whole plan rests on IT’s assumptions.
2. Can the recovery strategies actually meet those objectives?
3. Are the plans complete, current and available?
4. Have the plans been tested realistically, and were weaknesses fixed?
5. Do people know their roles?

Procedures

Governance and the BIA

• Review the BCP policy, scope and responsibilities.
• Review the BIA: are critical processes, impacts and RTO/RPO identified, current and approved by senior management?

Strategy

• Compare each critical system’s RTO and RPO with what the strategy can really deliver: backup frequency, replication, site readiness.
• Read alternate site contracts: configuration, capacity, oversubscription, testing rights, duration.
• Check dependencies on cloud and other providers, and their own continuity arrangements.

Plans

• Check the BCP and DRP are complete: declaration, teams and backups, contacts, procedures, return to normal.
• Check they’re current, by comparing them with recent system, organisation and supplier changes. A plan not updated after big changes is likely to fail.
• Confirm copies are kept offsite and can be reached.

Testing

• Review the test schedule, scope and realism.
• Compare results with objectives: time to recover, data recovered.
• Confirm issues were tracked to resolution and the plan updated.
• Observe a test where possible.

Verification

• Reconcile the offsite backup inventory with backup records; visit or review the offsite facility.
• Review evidence of restore tests.
• Interview team members about their roles.
• Call a sample of numbers on the contact list.
• Compare insurance cover with the risks identified.

The auditor’s role

The auditor evaluates and reports. They may advise while the plan is being developed, but they don’t write or own it. That would impair their independence when they audit it later.

Example. An auditor finds a detailed DRP with 4-hour RTOs for core systems, approved last year. The last test was a tabletop exercise two years ago, and backup restores have never been timed. The auditor can’t conclude the 4-hour objective is achievable, and reports that the plan’s effectiveness hasn’t been demonstrated.

How the exam asks about it

In short

• The auditor evaluates whether the BCP and DRP are adequate, current, tested and able to meet the business's recovery objectives.
• Start by understanding the BIA: are critical processes and recovery objectives identified and approved?
• Check that strategies (sites, backups, contracts) can actually meet the RTOs and RPOs.
• Review test plans and results: the best evidence that the plan works is a successful, realistic test.
• Verify offsite storage, backup inventories, copies of the plan, and alternate site contracts.
• Interview team members to check they know their roles, and check contact lists are current.

Exam traps

• A well-written plan that has never been tested gives little assurance.
• If the plan's recovery objectives weren't set by the business, the whole plan rests on IT assumptions.
• Reviewing the plan document alone isn't enough; verify backups, sites and people.
• The auditor evaluates and reports; the auditor doesn't write or own the plan.
• A plan not updated after major system changes is likely to fail.

Slides

Click the slide and use the arrow keys. F toggles full screen.