Policy Hub

Policy Statement

Africa Watch implements information security controls proportionate to risk, protects user data and platform availability, and meets its legal and contractual obligations. All personnel and systems handling Africa Watch data must comply with this policy.

Scope

All systems, staff, and contractors handling Africa Watch data, including the Africa Watch SaaS platform (africaiswatching.org), underlying Oracle Cloud Infrastructure, third-party integrations, and developer workstations.

Objectives

• Protect the confidentiality, integrity, and availability of Africa Watch information assets
• Comply with GDPR, applicable data protection laws, and contractual obligations to users
• Maintain user trust and platform reputation through consistent security practice
• Enable rapid detection and response to security incidents

References

• ISO 27001:2013
• GDPR (EU) 2016/679
• Controls Register (/admin/controls)
• Incident Response Playbook (/admin/incident-response)

Rules for Admin Access

• Admin access must be used only for legitimate platform management tasks
• Admin credentials must not be shared with any other person under any circumstances
• All admin actions are logged in the audit log and are subject to review
• Platform infrastructure (OCI, GitHub, API keys) must not be used for personal projects
• Any suspected compromise of admin credentials must be reported immediately to the Security Lead
• Users must lock workstations when unattended
• Sensitive data (API keys, tokens, credentials) must never be committed to source control

Prohibited Activities

• Exfiltrating user data outside of authorised export procedures
• Bypassing security controls or disabling logging
• Installing unauthorised software on production servers
• Accessing other users' accounts or data without authorisation

Consequences

Violations of this policy may result in immediate access revocation and, where applicable, legal action.

Pre-employment

• Reference checks required for any role with admin access to Africa Watch systems
• Signed Non-Disclosure Agreement (NDA) must be in place before any system access is granted

Onboarding

• Security awareness briefing (covering this policy, acceptable use, and incident reporting) before account creation
• Principle of least privilege applied on day one — access granted only to what is needed for the specific role
• TOTP MFA enrolled on admin account before first login

Ongoing Training

• ISO 27001 security awareness refresher conducted annually for all personnel with platform access
• Training completion logged (date, participant, topic)

Offboarding

• Admin account revoked within 1 hour of confirmed departure or role change
• All access reviewed and deprovisioned; API keys revoked
• If the departing individual had access to shared credentials, passwords are rotated immediately
• Exit interview includes reminder of ongoing confidentiality obligations under NDA

Normal Change Workflow

• All changes to production are made through git (master branch) — no direct file edits on server
• Changes are committed with a descriptive message referencing the feature or fix
• Security gate: npm audit --audit-level=high must pass before deployment proceeds
• SAST: Semgrep scan runs automatically on every push to master via GitHub Actions

Deployment Process

• Deployment: git pull origin master && pm2 restart africa-watch on the Oracle Cloud server
• Deployment confirmed by checking PM2 status and observability dashboard
• Deployment actions are logged (timestamp, operator, commit SHA)

Emergency Changes

• Emergency changes (e.g., critical security patch) may be deployed immediately without normal review cycle
• Emergency changes must be documented within 24 hours as a post-deployment note in the commit message or incident log
• A retrospective review is conducted at the next opportunity to identify process improvements

Prohibited

• No force-push to master branch
• No deployment of code that fails npm audit high severity check
• No deployment of code that fails Semgrep SAST scan without documented exception

Design Phase

• Threat model reviewed for any new feature that handles user data or authentication
• Security requirements documented alongside functional requirements

Development Phase

• OWASP Top 10 checklist applied during development
• Input sanitisation enforced via platform helpers: sanitizeLocation(), sanitizeQuery(), sanitizePromptInput()
• Output escaping via escapeHtml() applied to all user-supplied output rendered in HTML
• No credentials, API keys, or secrets committed to source control
• CSP nonce pattern used on all admin HTML pages — no inline event handlers

Testing Phase

• Route authentication tests (29/29) must pass in CI before merge
• Semgrep SAST scan (OWASP Top 10, Node.js, JWT, secrets rulesets) must pass in CI
• TruffleHog secrets scan runs on every push
• npm audit security gate blocks deployment on high severity CVEs

Deployment Phase

• npm audit gate must pass prior to deployment
• No force-push to master — all changes through commit history
• PM2 restart confirmed and observability dashboard checked post-deploy

Post-Release

• Error ring buffer and observability dashboard monitored for anomalies following deployment
• Any security incidents triggered by releases are documented in the incident log

Recovery Objectives

Objective	Value	Notes
RTO — Recovery Time Objective	4 hours	P0 platform-level outage; manual restore from backup
RPO — Recovery Point Objective	24 hours	Daily backup at 02:00 UTC; maximum data loss = 1 day

Backup Configuration

• Automated daily cron backup at 02:00 UTC
• Backup location: OCI Object Storage, 7-day retention window
• Backups are encrypted at rest on OCI Object Storage

Restore Procedure

1. SSH to Oracle Cloud server as opc
2. Stop PM2 process: pm2 stop africa-watch
3. Download latest backup from OCI Object Storage to /opt/africa-watch/
4. Replace africa-watch.db with restored file
5. Restart PM2: pm2 restart africa-watch
6. Verify platform health via observability dashboard
7. Log restoration in the Recovery Drill Log below

Escalation

• Platform Engineering Lead is contacted first on P0 outage
• Security Lead notified within 1 hour of confirmed P0
• User-facing status communication issued if outage exceeds 30 minutes

Failover Note

No secondary region is currently provisioned. The RTO of 4 hours reflects manual restore from OCI backup. A secondary region failover architecture is a future improvement item.

BCP Testing

The BCP is exercised via the Platform Outage tabletop scenario (see Tabletop Exercise page). Backup restoration is drilled quarterly — results logged below.

Recovery Drill Log

Cells are editable — data is saved to browser localStorage for this device.

Data Protection Officer

Security Lead — contact: [email protected]

Personal Data Processed

Data Type	Legal Basis	Retention
Email address, username	Contract (subscription service)	Active + 90 days post-deletion
Subscription status	Contract	Active + 90 days post-deletion
Watchlist locations	Contract	Active + 90 days post-deletion
Usage / security logs	Legitimate Interest (security)	30 days rolling

DPIA — LLM Processing

Africa Watch feeds political event descriptions to the Claude API (Anthropic) for analysis and summarisation.

• Data sent: Event title, location name, event description — no PII by design
• Processor: Anthropic (Claude API) — GDPR-compliant Data Processing Agreement available
• Risk level: Low — no personal data included in LLM prompts by design; prompts reviewed in SDLC
• Mitigation: sanitizePromptInput() strips any user-supplied content before sending to LLM

Subject Access Request (SAR) Procedure

• Users email [email protected] to request their data
• Response provided within 30 days as required by GDPR Article 15
• Data export generated from africa-watch.db covering: account details, watchlists, subscription status
• Right to erasure: account and associated data deleted, anonymised in logs where possible

Data Breach Procedure

• Breaches involving personal data reported to the relevant supervisory authority within 72 hours of discovery (GDPR Article 33)
• Affected individuals notified where breach is likely to result in high risk (GDPR Article 34)
• Breach response follows the Incident Response Playbook (Data Exposure runbook)