# MEGA™ Municipal Risk Management — Afrihost shared hosting pilot

## IMPORTANT: Version 1.1 candidate, restricted pilot only; not audited production release
This is a **functional pilot** intended for a controlled, simulated workshop with non-sensitive information. It has not undergone real-host end-to-end testing, penetration testing, load testing, independent security review, WCAG accessibility audit, municipal legal sign-off, or production disaster-recovery verification. Do not load real employee, fraud, personal, procurement or confidential municipal records until those steps are completed. Never imply that a successful PHP lint is a live-workshop guarantee.

Read `TEST_REPORT.md` before deploying. Existing installations require `app/migrate_1_1.sql`, as described in that report.

## Hosting prerequisites
- Afrihost **Linux** shared hosting account with PHP 8.2+ (recommended current patched version), PDO MySQL and Fileinfo extensions, MySQL/MariaDB, Apache `.htaccess`, and working HTTPS/TLS.
- Create one database and database user in your Afrihost control panel. Grant the user adequate schema privileges for installation; restrict privileges afterwards.
- Confirm the exact Afrihost plan supports your PHP/MySQL version and sufficient capacity for your anticipated participant count. Shared plans have resource limits; voting uses HTTP requests, not persistent WebSockets.
- **Use a fresh pilot database. Never install over an existing system.**

## Install steps
1. Download and extract `MEGA_Municipal_Risk_Management.zip` locally.
2. In Afrihost's File Manager or FTP, upload the entire `MEGA_Municipal_Risk_Management` folder into `public_html`, so the resulting layout is `public_html/MEGA_Municipal_Risk_Management/install.php`, `app/`, `public/`, and `storage/`.
3. Confirm the `.htaccess` deny rules in `app/` and `storage/` are honoured by your hosting server. If not, move `app/` and `storage/` outside `public_html` and adjust the paths in `public/index.php`, `app/bootstrap.php`, and `install.php` appropriately **before exposing it publicly**.
4. Visit `https://YOUR_DOMAIN/MEGA_Municipal_Risk_Management/install.php`. Enter database credentials, municipality name, and a strong administrative password (at least 14 characters). The installer creates tables and imports 587 taxonomy risk events.
5. **Delete `install.php` immediately** using File Manager. There is no automatic deletion mechanism.
6. Sign in at `https://YOUR_DOMAIN/MEGA_Municipal_Risk_Management/public/index.php?p=login`.
7. Populate departments and approved IDP strategic objectives; then populate SDBIP operational objectives linked to strategic objectives. **Pilot only:** objectives are entered manually based on approved source plans. Automatic extraction from PDFs is not implemented.
8. Schedule a workshop, open it, capture a draft risk and link the risk to that workshop.
9. Open a voting round in the risk view. Share the generated participant link with workshop attendees. They can vote without a user login. Participants enter a name and give one 1–5 impact score and one 1–5 likelihood score. Each browser can submit only one vote per round. Participants must not share browser profiles or vote twice from different devices.
10. Close voting. The system calculates `average_impact × average_likelihood`, rounded to two decimals, as inherent risk. Score band defaults in this pilot: High >=15, Medium >=6, Low otherwise. **Validate against the municipality's adopted criteria before use.**
11. Record current controls, factor (0–1), risk owner, improvement actions, action owners, due dates and budget status. `residual = inherent × control_factor`. Control-effectiveness changes after the first entry require supporting effectiveness evidence and KPI before/after observations, and must be approved by Risk Officer/Admin.
12. Have a user with a manager or admin role approve risk records. Only approved risks appear in official consolidated reports. Admin can generate a snapshot and download CSV.

## Workshop run-of-show (suggested)
- 15 minutes before: test Wi-Fi/mobile connectivity, projected register, HTTPS, participant vote link on 3+ phones, database backup, video/projector, and a 4G backup connection.
- Start with a preconfigured department and objectives; perform a non-sensitive sample risk test from discovery to closing the vote.
- Show live vote count (refresh risk page), take a final vote close, then apply existing controls and calculate residual exposure.
- Submit, approve using a separately logged-in authorised account and export consolidated data.
- Have printed paper ballots or an offline spreadsheet available if internet fails; import/reconcile later manually (automatic offline sync is **not** implemented).

## Pilot limitations and security upgrades required
- An administrator can create staff accounts at `public/index.php?p=users`, but secure invitations, account recovery, forced first-login password change and MFA are not implemented. Do not email passwords or use real sensitive data.
- Anonymous voting is protected by a workshop access code and one browser cookie per vote round; **it is not a tamper-proof or identity-verified ballot**. A determined attendee can vote from multiple browsers/devices, and identities are self-declared. Do not use this to make high-consequence binding decisions without attendance verification and stronger participant tokens.
- The live vote count updates by page refresh (not continuous push), and vote rounds have no independent quorum/eligibility enforcement.
- Individual vote audit records are stored, but no separate participant register with authenticated one-time tokens is provided.
- Departments and objectives are manually entered. IDP/SDBIP imports, version changes, source-document extraction, cross-catalogue linkage review and statutory traceability require later implementation.
- Approvals are per risk; formal departmental sign-off workflow and historical assessment version snapshots (beyond exported consolidated snapshots) require further development.
- There is no fine-grained data segregation between departments; signed-in users may see multiple departmental risk records according to their broad role. Do not treat this as multi-tenant production-safe.
- The prototype does not support automatic email/SMS notifications, budget-system integration, offline capture, Excel XLSX export, PDF generation, or bulk legacy import. CSV export opens in Excel.
- Risk levels and control factor choices must be reconciled against the municipality's approved methodology; the six control-effectiveness descriptors from the source register are not yet exposed as a validated dropdown.
- A KPI trend is recorded as before/after text with evidence, not automatically verified against an authenticated SDBIP system. Final effectiveness judgement remains human and requires governance.
- Evidence uploads are limited to 5 MB and PDF, PNG, JPG, TXT. File type is checked using Fileinfo; malware scanning is not provided. Apply antivirus scanning at infrastructure level before accepting live content.
- No rate-limiter / bot protection, MFA, backup automation, restore tests, automated per-risk notification, trusted device attestation or security event monitoring is included.
- The default design provides no independent access-control checking on evidence beyond login; production deployments need record-level and sensitivity-based authorisation.
- Follow POPIA requirements, municipal ICT security policies, records retention schedules and procurement of hosting/data processing services before using real data.
- Shared hosting may be unsuitable for high-concurrency production municipal deployments: assess dedicated infrastructure, queues, backups, monitoring and penetration testing first.

## Change control and validation
Do not claim formal compliance with ISO 31000, ISO 27001, OWASP ASVS or WCAG without independent verification. Use them as acceptance/assurance targets. Validate risk methodology, control ratings, rounding and classification with the municipality's risk policy and the Public Sector / Local Government Risk Management Framework.