Business Continuity Plan (BCP)
1. Introduction
1.1 Purpose
This Business Continuity Plan (BCP) establishes the procedures and systems that Yazi Research (Pty) Ltd has implemented to:
Ensure the continuity of critical business operations during disruptive events.
Protect client data and uphold privacy controls in all circumstances.
Fulfil our regulatory and contractual obligations concerning data protection.
Maintain the service levels of our WhatsApp research platform, ensuring continuous engagement with our clients.
1.2 Scope
This plan covers:
All production systems hosted on Amazon Web Services (AWS).
Data processing and storage operations.
Client communications and support services.
Internal operations and personnel activities.
1.3 Objectives
The primary objectives of this BCP are to:
Maintain data privacy and security throughout disruptive events.
Ensure continuous availability of all critical services.
Minimise downtime and data loss during incidents.
Protect client interests and sensitive information.
Remain compliant with all applicable regulatory standards.
2. Data Privacy and Protection Controls
2.1 Data Protection During Disruptions
Encryption: All data remains encrypted during failover procedures.
Access Controls: Strict access protocols are maintained to ensure data integrity during recovery.
Data Residency: Compliance with data residency requirements is enforced during all failover activities.
Privacy Impact Assessments: These assessments are conducted regularly and particularly during recovery operations.
Audit Logging: All recovery actions are fully audited and logged for accountability.
2.2 Privacy Controls in Recovery Operations
Authorised Access: Only authorised personnel are granted access to client data during recovery.
Data Segregation: Client data remains segregated from other datasets at all times.
Backup System Compliance: Privacy requirements are rigorously enforced across all backup systems.
Restoration Protocols: Strict controls are in place to manage data restoration.
Regular Testing: Privacy controls are regularly tested in simulated recovery scenarios.
3. Recovery Time and Point Objectives
3.1 Recovery Time Objectives (RTO)
Critical Systems: 4 hours
Support Systems: 8 hours
Non-Critical Systems: 24 hours
3.2 Recovery Point Objectives (RPO)
Critical Data: 15 minutes
Support Systems: 1 hour
Non-Critical Systems: 4 hours
4. AWS Infrastructure Recovery Procedures
4.1 Primary Infrastructure
Yazi Research (Pty) Ltd supports two distinct data residency options. The primary infrastructure is configured based on the client’s selected region:
For Clients with South African Data Residency:
Region: AWS Africa (Cape Town)
Production Environment: Deployed across three availability zones.
Database: Amazon RDS Multi-AZ deployment, with servers physically located in South Africa.
Storage: Amazon S3 storage with cross-region replication configured to ensure that backups remain within South African territory.
For Clients with United Kingdom Data Residency:
Region: AWS Europe (London)
Production Environment: Configured across multiple availability zones in the London region.
Database: Amazon RDS Multi-AZ deployment, with servers located within the United Kingdom.
Storage: Amazon S3 storage with cross-region replication designed to ensure that all data storage and backup processes comply with GDPR requirements.
Detailed documentation is maintained for both configurations to ensure strict adherence to each client’s data residency selection.
4.2 Failover Procedures
Automated Failover: Automated failover between availability zones is implemented within each region.
Manual Failover: In the event of a regional AWS failure, manual failover procedures are available. These procedures are tailored based on the client’s selected data residency region.
Database Failover: Automatic redirection to standby replicas is enabled. For UK data residency, this includes adherence to GDPR-based recovery protocols.
Load Balancer Health Checks: Regular health checks are conducted, and load balancers automatically reroute traffic as required.
DNS Management: Rapid DNS updates are managed via AWS Route 53, ensuring that traffic is directed to the correct regional endpoints.
4.3 Data Recovery Procedures
Automated Backups: Databases are recovered using automated backups that are region-specific.
Point-in-Time Recovery: Enabled to recover data up to the client-specific recovery point objective (RPO).
Version Control: Amazon S3 versioning is utilised to restore previous versions of data, ensuring that restoration aligns with the client’s selected data residency.
Consistency Verification: Detailed checks are performed to confirm data integrity and consistency post-recovery.
Privacy and Regulatory Verification: Recovery procedures include steps to verify that privacy controls and regulatory requirements (POPIA for South Africa and GDPR for the UK) are fully maintained.
5. Incident Response and Escalation
5.1 Incident Classification
Level 1 – Minor Disruption: Affects a single component.
Level 2 – Significant Disruption: Impacts multiple components.
Level 3 – Major Disruption: System-wide impact.
Level 4 – Catastrophic Failure: Complete service outage.
5.2 Response Team and Responsibilities
Incident Commander: Timothy Treagus (CEO) Oversees overall incident management and client communications.
Technical Lead / Security Officer: Mzwandile Sotsaka (CTO) Directs technical recovery and ensures that security protocols are adhered to.
Client Communications: Timothy Treagus Manages all client and stakeholder communications during incidents.
5.3 Escalation Matrix
Level 1:
First Response: Technical Team
Escalation Time: Within 30 minutes
Notification: Internal teams only
Level 2:
First Response: Technical Lead
Escalation Time: Within 1 hour
Notification: Affected clients are informed
Level 3:
First Response: Technical Lead and CEO
Escalation Time: Immediate
Notification: All clients receive notification
Level 4:
First Response: Full response team activation
Escalation Time: Immediate
Notification: All stakeholders, including regulatory bodies if necessary
6. Testing and Maintenance
6.1 Testing Schedule
Monthly: Component-specific tests.
Quarterly: Full failover testing across key systems.
Bi-annual: Disaster recovery simulation exercises.
Annual: Comprehensive review and testing of the entire BCP.
6.2 Testing Procedures
Pre-Test Planning: Notification of stakeholders and detailed planning.
Execution: Real-time monitoring during test events.
Documentation: Detailed recording of test results and performance metrics.
Privacy Verification: Specific tests to verify the effectiveness of privacy controls.
Gap Analysis: Identification and resolution of any detected deficiencies.
Reporting: Distribution of comprehensive test reports to the response team.
6.3 Documentation Requirements
Test Plans: Detailed scenarios and methodologies.
Results and Metrics: Documentation of performance and outcomes.
Privacy Control Assessments: Verification of controls during tests.
Remediation Records: Documentation of any identified gaps and corrective actions.
Approval: Sign-off by the Security Officer following each test.
7. Client Communication Procedures
7.1 Notification Templates
Service Disruption Notices: Clear, timely updates regarding any disruption.
Status Updates: Regular progress updates during incident resolution.
Resolution Confirmations: Formal confirmation once services are restored.
Post-Incident Reports: Detailed summaries and follow-up actions after an incident.
7.2 Communication Channels
Email: Direct notifications to clients.
Status Page: Real-time updates on our dedicated status page.
Direct Contact: Personal outreach by account managers for critical clients.
Regulatory Notifications: Timely communication with regulatory bodies where required.
8. Data Backup and Recovery
8.1 Backup Procedures
Daily Automated Backups: Full backups are executed daily.
Transaction Log Backups: Performed at 15-minute intervals to minimise data loss.
Cross-Region Backup Replication: Backups are replicated across regions according to the client’s data residency selection. This ensures that for South African clients, all backups remain within South Africa, and for UK clients, backups remain within the United Kingdom.
Encryption: All backups are encrypted to maintain data confidentiality.
Regular Backup Testing: Frequent testing is conducted to verify the integrity and correct regional placement of backups.
Location Verification: Procedures include explicit steps to verify that the backup data remains in the client-selected region.
8.2 Recovery Procedures
Team Authentication: The recovery team is authenticated before initiating any recovery process.
Backup Integrity Verification: Backups are rigorously verified for integrity prior to restoration.
Secure Restoration: Data is restored in a secure environment that complies with the client’s data residency requirements.
Data Consistency Checks: Post-restoration, thorough checks are performed to ensure data consistency.
Privacy Control Validation: All privacy controls are validated during the recovery process.
Regulatory Compliance Verification: Recovery procedures incorporate additional compliance checks to ensure adherence to local data protection regulations—POPIA for South African data and GDPR for UK data.
Operational Resumption: Services are gradually resumed following successful verification and restoration.
9. Compliance and Audit
9.1 Regulatory Requirements
POPIA: Strict adherence to the Protection of Personal Information Act is maintained during all recovery procedures.
GDPR: For data processed within the United Kingdom, full compliance with the General Data Protection Regulation is ensured.
Industry Standards: Our practices are aligned with recognised standards such as ISO 27001.
Independent Assessments: Periodic independent security assessments validate our data protection measures and regulatory adherence.
9.2 Audit Procedures
Regular Audits: Scheduled audits of the BCP and its effectiveness.
Privacy Impact Assessments: Regular reviews of the privacy implications of our recovery procedures.
Control Testing: Periodic tests of security and privacy controls.
Documentation Reviews: Comprehensive review of all recovery documentation.
Compliance Verification: Regular verification against applicable regulatory standards.
10. Plan Maintenance and Updates
10.1 Review Schedule
Monthly: Update of emergency contact lists.
Quarterly: Review and refinement of recovery procedures.
Annual: Full review and update of the entire BCP.
Post-Incident: Immediate updates following any significant incident.
10.2 Version Control
Document Tracking: All changes are tracked with version numbers.
Change Log: A detailed log of changes is maintained.
Approval Documentation: All updates are formally approved.
Distribution: Controlled distribution to ensure all stakeholders have the latest version.
11. Emergency Contacts
11.1 Internal Contacts
CEO: Timothy Treagus Tel: +27 60 946 6174 Email: [CEO Email]
CTO / Security Officer: Mzwandile Sotsaka Tel: [CTO Phone Number] Email: [CTO Email]
Technical Support: Email: [Technical Support Email]
11.2 External Contacts
AWS Support: Enterprise Support (24/7)
Internet Service Provider: [Provider Contact Details]
Data Centre (AWS Cape Town): [Contact Details]
Legal Counsel: [Legal Counsel Contact Information]
12. Appendices
Appendix A: Recovery Checklists
System Recovery Procedures: Detailed step-by-step recovery actions.
Data Verification Steps: Procedures for verifying data integrity.
Privacy Control Checks: Steps to ensure privacy controls are operational.
Communication Templates: Pre-approved templates for client and stakeholder notifications.
Testing Scenarios: A compendium of simulated scenarios for training and testing purposes.
Appendix B: Risk Assessment
Critical System Dependencies: Identification of key systems and interdependencies.
Single Points of Failure: Analysis of any areas where failure could lead to significant impact.
Recovery Priorities: Clear prioritisation of system recovery.
Risk Mitigation Strategies: Strategies to reduce identified risks.
Last updated