Business Continuity & Availability Policy
Document ID: DPWAT-ISMS-POL-009
Version: 1.0
Owner: Administrator (ADM) + CISO — Anna Boros; Timo Andreas Bejan
Approved by: Administrator (ADM) — Anna Boros
Effective date: 2025-10-15
Next review: 2027-02-01 (or on major change)
1. Policy
DP WAT maintains continuity measures proportionate to our size and operating model (cloud-first, remote-first).
2. Service dependencies
DP WAT relies on key SaaS/cloud providers. DP WAT maintains:
- supplier reviews for critical providers,
- incident processes,
- an outage operating mode (telework, alternate tools where feasible),
- backup decisions for critical information (see backup procedure).
3. Informal redundancy and fallback channels
DP WAT maintains informal resilience through:
- Code/repositories: Local clones on developer machines provide redundancy beyond GitHub.
- Communication: If Google Workspace is unavailable, personnel can use Slack, personal email, or phone.
- Documents: Critical ISMS documents are version-controlled in Git; local copies exist on developer machines.
Formal BCP with detailed RTOs is not warranted for a small (~7 person) remote consultancy; the above measures are proportionate to company size and risk profile.
4. Risk acceptance note (availability)
If DP WAT chooses not to maintain independent backups beyond provider controls, this must be formally accepted and recorded with rationale and impact analysis.
5. Continuity testing
DP WAT performs an annual continuity review (tabletop discussion or practical test) to validate that informal redundancy measures remain effective. The review considers scenarios such as:
- Key person unavailability: CISO or Administrator is unreachable for an extended period (illness, travel, emergency). Verify that the other can assume critical responsibilities and has necessary access.
- Primary communication outage: Google Workspace is unavailable. Confirm personnel know to use Slack, personal email, or phone as fallback.
- Code repository outage: GitHub is inaccessible. Verify that developers have recent local clones and know where to push if an alternate remote is needed.
- Device loss/theft: A developer's laptop is lost with local work. Confirm that code is regularly pushed and that remote wipe can be initiated via MDM.
Results are recorded in management review minutes or a brief continuity test record in 07-records/.