SCM‑NUMSICT Governance & System Assurance Standards
Master governance binder for the Nurses Uniform Management System (SCM‑NUMS). Prepared for the KZN Health ICT Governance Committee in accordance with the KZN Department of Health ICT Governance & System Assurance Standards, PHSDSBC Resolution 1 of 2022, POPIA, PFMA and Treasury Regulations 16A.

AAbbreviations & Acronyms
Abbreviations are expanded upon first use in each section and consolidated here for ease of reference.
| Abbr. | Full Meaning | Context |
|---|---|---|
| ACID | Atomicity, Consistency, Isolation, Durability | MariaDB/InnoDB transactions |
| AGSA | Auditor‑General of South Africa | External assurance provider |
| API | Application Programming Interface | Stores module integration |
| BRD/BRS | Business Requirements Document / Spec | Section 2 |
| CEO | Chief Executive Officer | Position Level 11 |
| CHC | Community Health Centre | Facility type |
| CIO | Chief Information Officer | Owner of ICT Standards |
| CRUD | Create, Read, Update, Delete | Catalogue operations |
| CSRF | Cross‑Site Request Forgery | Attack mitigated by tokens |
| CSV | Comma‑Separated Values | Report export format |
| DBA | Database Administrator | Custodian of nurses_db |
| DoH | Department of Health | KZN provincial department |
| DR | Disaster Recovery | Section 14 |
| ENA | Enrolled Nursing Auxiliary | Position Level 1 |
| FRS | Functional Requirements Specification | Section 4 |
| HR | Human Resources | Source for nurses table |
| HTTPS | HTTP Secure | SSL/TLS encryption |
| ICT | Information & Communication Technology | Departmental Division |
| KZN | KwaZulu‑Natal | Province hosting system |
| MVC | Model‑View‑Controller | Architecture pattern (§5) |
| NDoH | National Department of Health | Parent of provincial DoH |
| NUMS | Nurses Uniform Management System | Legacy name; SCM‑NUMS |
| NFR | Non‑Functional Requirements | Sections 3 & 4 |
| OWASP | Open Web App Security Project | Security baseline |
| Abbr. | Full Meaning | Context |
|---|---|---|
| Portable Document Format | Audit report output | |
| PDO | PHP Data Objects | Parameterised DB access |
| Persal | Personnel and Salary System | Employee identifier |
| PHSDSBC | Public Health & Social Development Sectoral Bargaining Council | Res. 1 of 2022 |
| PII | Personally Identifiable Information | POPIA protected |
| POPIA | Protection of Personal Information Act | Privacy legislation |
| RBAC | Role‑Based Access Control | 5 roles enforced |
| RPO | Recovery Point Objective | Target: 1 hour |
| RTM | Requirements Traceability Matrix | Section 10 |
| RTO | Recovery Time Objective | Target: 4 hours |
| SCM | Supply Chain Management | Business owner |
| SITA | State IT Agency | Hosting provider |
| SLA | Service Level Agreement | Availability targets |
| SMB | Server Message Block | Off‑site backup protocol |
| SOP | Standard Operating Procedure | Section 16 |
| SQL | Structured Query Language | Prepared statements |
| SSL/TLS | Secure Sockets Layer / Transport Layer Security | Encryption in transit |
| UAT | User Acceptance Testing | Section 12 |
| UPS | Uninterruptible Power Supply | Protects SITA VM |
| URS | User Requirements Specification | Section 3 |
| VM | Virtual Machine | Windows 10 Enterprise |
| WAF | Web Application Firewall | Perimeter defence |
| XLSX | Microsoft Excel Open XML | Report export |
| XSS | Cross‑Site Scripting | Prevented by encoding |

1Project Charter & Project Plan
Purpose. Defines the system purpose, scope, objectives, stakeholders, responsibilities and implementation approach per KZN ICT Governance Standard §4 (Document 1).
1.1 Executive Summary
The Supply Chain Management (SCM) Nurse Uniform Management System (NUMS) project was initiated to address the critical need for a unified, transparent and auditable platform for nurse uniform management across the KwaZulu‑Natal (KZN) Department of Health (DoH). The system replaces fragmented manual processes with an integrated, secure, web‑based solution serving over 32,000 nurses across 11 health districts.
The project was formally established on 26 May 2026 with a budget comprising Mr TG Sikosana's remuneration (maximum overtime allowed for the project duration) and to be completed on the 15th October 2026, delivering all planned objectives within scope and budget.
| Project Name | SCM‑NUMS (Supply Chain Management – Nurse Uniform Management System) |
|---|---|
| Project ID | KZN-ICT-2026-01 |
| Department | KwaZulu‑Natal Department of Health |
| Division | Supply Chain Management & ICT Division |
| Sponsor | Head of Department: KZN Health |
| Project Manager | Mr Themba Sikosana (Project Manager · Technical Lead) |
| Start / End | 26 May 2026 → 15 October 2026 |
| Budget | Mr TG Sikosana remuneration — max overtime for project duration |
| Status | Implementation Ongoing |
1.2 Project Purpose
SCM‑NUMS was established to develop and implement a unified, transparent and auditable platform for nurse registration, uniform ordering, supervisor approval, distribution tracking, financial reporting and compliance monitoring. The system replaces manual paper‑based processes with a secure, web‑based solution providing end‑to‑end visibility and control.
Challenges Addressed by SCM‑NUMS
Challenges Before SCM‑NUMS
- Inefficient manual processes: paper‑based ordering slow and error‑prone.
- Email‑based requests: difficult to track, prioritise or audit.
- Lack of visibility: no real‑time view of ordering or expenditure.
- Audit difficulties: audit evidence hard to produce.
- Fraud risk: no traceability created mismanagement opportunities.
- Inconsistent practices: no standardisation across facilities.
Business Value Delivered
- Fully digitised ordering process
- Complete audit trail for every transaction
- Role‑based access control across 5 roles
- Real‑time financial and operational dashboards
- Full compliance with PHSDSBC Resolution 1 of 2022
- Zero licensing cost and maintainable by own ICT team
1.3 Project Scope
In Scope
- Users: 32,000+ nurses across 11 districts
- Facilities: 700+ health facilities
- Online ordering: visual catalogue with size selection
- Approval workflow: position hierarchy (Levels 1–12)
- RBAC: five distinct user roles
- Audit trail: complete logging of all transactions
- Financial reporting: district, facility, province‑wide
- Integration: HR database for Persal validation
Out of Scope
- Physical uniform manufacturing
- Procurement of raw materials
- Logistics fleet management
- Physical distribution logistics
- External system integrations beyond HR
| Objective | Target | Status |
|---|---|---|
| Digitise ordering process | 100% facilities | In Progress |
| RBAC with 5 roles | Full hierarchy | Achieved |
| Real‑time order visibility | < 3 sec | Achieved |
| Complete audit trail | 100% logged | Achieved |
| PHSDSBC compliance | Full | Achieved |
| HR integration | Real‑time | Achieved |
| System availability | 99.5% | Monitoring |
| # | Criterion | Target |
|---|---|---|
| 1 | User Adoption | 100% within 6 months |
| 2 | Order Processing | < 10 days average |
| 3 | Audit Readiness | All logged and traceable |
| 4 | User Satisfaction | > 80% positive |
| 5 | System Performance | 99.5% uptime, < 3s |
Tracked from requirements through to province‑wide go‑live. Each phase gates the next.
| Phase | Milestone | Date | Status |
|---|---|---|---|
| Requirements | BRS & URS Approval | 26 May 2026 | Complete |
| Design | Architecture & Database Schema | 15 Jun 2026 | Complete |
| Development | Core Modules | Most by 1 Aug 2026 | In Progress |
| Testing | Internal & Security Testing | 15 Aug 2026 | In Progress |
| Facility Testing | On‑site Testing | End Sep 2026 | Planned |
| Pilot | 5 Pilot Facilities | Early Oct 2026 | Planned |
| Deployment | Province‑Wide Go‑Live | Mid Oct 2026 | Planned |

2Business Requirements Specification (BRS/BRD)
Purpose. Documents the business requirements and expected system functionality per the KZN ICT Governance Standard §4 (Document 2).
2.1 Business Problem Statement
The current manual paper‑based uniform ordering process within the KZN Department of Health is inefficient, error‑prone and lacks transparency. Nurses experience significant delays receiving uniforms, supervisors struggle to track and manage orders, and management lacks visibility into ordering patterns and expenditure.
| Problem | Business Impact |
|---|---|
| Time Delays | Order processing takes 30+ days from request to delivery |
| Email‑Based Requests | Difficult to track, prioritise or audit |
| Data Errors | Incorrect sizes, quantities, nurse details |
| Lost Records | Paper forms frequently lost or misplaced |
| No Audit Trail | Cannot track who ordered or approved |
| Inconsistent Practices | Each facility has different procedures |
| Financial Leakage | Budget overspending due to lack of visibility |
2.2 Business Objectives
- Reduce Order Processing Time: from 30+ days to under 10 days.
- Eliminate Manual Paperwork: fully digitise the ordering process.
- Provide Real‑Time Visibility: all stakeholders can track orders.
- Enable Complete Audit Trail: every transaction logged.
- Standardise Across Districts: consistent practices across all 11 districts.
- Ensure Compliance: full PHSDSBC Resolution 1 of 2022 compliance.
- Improve Financial Accountability: track expenditure and prevent fraud.
- Reduce Administrative Cost: less manual effort per requisition.
2.3 Key Business Requirements
Each requirement has a unique identifier, priority and business driver.
| ID | Requirement | Priority | Business Driver |
|---|---|---|---|
| BR-01 | Nurses must register using their Persal number | High | Identity verification |
| BR-02 | Supervisors must approve or reject orders | High | Accountability |
| BR-03 | All transactions must be logged with audit trail | High | Audit readiness |
| BR-04 | RBAC with role‑based access | High | Security |
| BR-05 | Financial and operational reports | Medium | Management oversight |
| BR-06 | HR database integration for validation | High | Data accuracy |
| BR-07 | Centralised uniform catalogue | Medium | Consistency |
| BR-08 | Support for 32,000+ users | High | Scalability |
2.4 Stakeholder Groups
| Stakeholder | Role | Business Need |
|---|---|---|
| Nurses | Place orders, view history | Easy ordering, fast delivery, transparent status |
| Supervisors | Approve/reject, activate nurses | Visibility of supervisee orders, efficient approvals |
| Stores Officers | Manage stores, issue uniforms | Inventory oversight, requisition fulfilment, reporting |
| Head Office | Province‑wide oversight | Strategic visibility, financial control, compliance |
| Auditors | Review logs, compliance | Easy access to audit trails, compliance reports |
2.5 Business Process Changes
Old Process (Manual)
- Paper forms distributed to facilities
- Requests received by email — no central register
- Manual data entry by clerks
- Physical approval signatures
- Paper‑based order tracking
- Manual report generation
New Process (Digital)
- Online registration and ordering
- Automated data validation
- Digital approval workflow
- Real‑time status tracking
- Automated reporting with export
2.6 Success Criteria

3User & System Requirements (URS / FRS / NFR)
Purpose. Documents user requirements and defines the functional and non‑functional requirements per the KZN ICT Governance Standard §4 (Document 3).
3.1 User Requirements
| ID | User Type | Requirement | Priority |
|---|---|---|---|
| UR-01 | Nurse | Register with Persal, view catalogue, place orders, view history, edit pending orders | High |
| UR-02 | Supervisor | View supervisee orders, approve/reject, activate accounts, re‑open approved orders | High |
| UR-03 | Stores Officer | Manage inventory, issue uniforms, generate stores reports, view requisitions | Medium |
| UR-04 | Head Office | Oversee all districts, manage settings, province‑wide reports, manage admin registrations | High |
| UR-05 | Auditor | View audit logs, compliance reports, read‑only access to all data | Medium |
3.2 Functional Requirements
Each FR is traceable to a module and a PHP file in the SCM‑NUMS codebase.
| ID | Function | Description | Implementation |
|---|---|---|---|
| FR-01 | Registration | Persal number + surname validated against HR database | check_name.php |
| FR-02 | Authentication | Secure login with bcrypt password hashing and sessions | login.php · admin_login.php |
| FR-03 | RBAC | Role‑Based Access Control using position hierarchy (levels 1–12) | config.php · canSupervise() |
| FR-04 | Catalogue | CRUD for uniform items with gender filtering | settings.php |
| FR-05 | Order Placement | Select items, sizes, quantities with real‑time totals | order.php |
| FR-06 | Approval Workflow | Supervisor approves/rejects with reason | approve_order.php |
| FR-07 | Audit Logging | All actions logged (who, when, what, where, why) | admin_audit_log · nurses_activity_log |
| FR-08 | Reporting | Generate/export reports (Excel, CSV, Print) | financials.php · auditor_export.php |
| FR-09 | Activation | Supervisors activate nurse accounts | activate_user.php |
| FR-10 | Order Editing | Users can edit pending orders before approval | edit_order.php |
3.3 Non‑Functional Requirements
| ID | Area | Requirement | Metric | Status |
|---|---|---|---|---|
| NFR-01 | Performance | Support 32,000+ concurrent users | < 3 sec response | In Progress |
| NFR-02 | Security | bcrypt hashing, 30‑min session timeout, complexity policy | OWASP compliant | Achieved |
| NFR-03 | Availability | System uptime target | 99.5% | Monitoring |
| NFR-04 | Scalability | Horizontal scaling capability | Auto‑scaling ready | Achieved |
| NFR-05 | Compliance | POPIA compliant | Full compliance | Achieved |
| NFR-06 | Audit | All actions logged | 100% coverage | Achieved |
| NFR-07 | Usability | Responsive design | Desktop, tablet, mobile | Achieved |
| NFR-08 | Maintainability | Modular architecture | Documented code | Achieved |
| NFR-09 | Interoperability | Export to Excel/PDF | Standard formats | Achieved |
| NFR-10 | Data Integrity | ACID compliance | All transactions | Achieved |
3.4 Non‑Functional Requirements Detail
Security (NFR-02)
- bcrypt hashing with salt
- Enforced password complexity (see §3.5)
- 30‑minute session timeout
- HTTPS (SSL/TLS) encryption
- CSRF protection tokens
- Prepared statements (PDO)
- XSS prevention via output encoding
- Account lockout after 5 failed logins
Performance (NFR-01)
- Indexes on foreign keys
- Optimised queries for history and reporting
- Caching frequently accessed data
- Load testing before go‑live
Usability (NFR-07)
- Fully responsive CSS design
- Touch‑friendly interfaces
- Clear, role‑specific navigation
- Intuitive forms with validation
- Visual representations of items
3.5 Password Complexity Policy (Aligned with check_name.php)
SCM‑NUMS enforces a single password policy on both client (check_name.php live checklist) and server (bcrypt comparison at login). The following rules apply to every nurse account at registration.
Password Rules
- Minimum length: 6 characters
- At least one uppercase letter (A–Z)
- At least one lowercase letter (a–z)
- At least one number (0–9)
- At least one special character (!@#$%^&*)
- Stored using bcrypt hashing with salt
check_name.php mirror the server‑side regex checks. If either fails, registration is blocked and missing rules are reported.Every rule below is enforced identically on the client (JavaScript) and on the server (PHP).
| Rule | Requirement | Example Failure | Enforced In |
|---|---|---|---|
| Length | At least 6 characters | "Ab1!" | Client + Server |
| Uppercase | Contains A–Z | "nurse123!" | Client + Server |
| Lowercase | Contains a–z | "NURSE123!" | Client + Server |
| Number | Contains 0–9 | "Nurse!" | Client + Server |
| Special Character | Contains non‑word character (e.g. !@#$%^&*) | "Nurse1234" | Client + Server |
| Confirmation | Password and confirmation must match | Mismatched entries | Client + Server |
check_name.php.
4Functional & Non‑Functional Requirements (Detail)
Purpose. Detailed breakdown of Functional and Non‑Functional Requirements per the KZN ICT Governance Standard §4 (Document 4).
4.1 FR-01 — Registration
- Users access registration via
register.php. - Enter Persal number and surname for verification against the nurses table.
- If already registered, user is notified.
- If verified, user proceeds to profile completion.
- Profile: email, telephone, gender, position, department, password, security question.
- Password must meet policy in §3.5.
- Position selection determines supervisor level.
- Management (Level 7+) auto‑assigned to Hospital Management Services.
- Account created with
is_active = 0pending activation.
4.2 FR-02 — Authentication
- Login via
login.phpwith Persal and password. - Password verified using bcrypt comparison.
- Session created with user ID, role, district, facility.
- Session timeout after 30 minutes.
- Failed attempts tracked for security monitoring.
- Account lockout after 5 consecutive failures.
4.3 FR-03 — RBAC
- Access based on
positions.levelandpositions.scope. - Five roles: Nurse, Supervisor, Stores Officer, Head Office, Auditor.
- Menu items filtered by role permissions.
- Action‑level permissions (view, create, edit, delete, approve).
- Data‑level filtering (own, team, district, province).
- Supervision scope: Department (Level 6) or Facility (Level 7+).
4.4 FR-04 — Catalogue Management
- Items stored in
uniform_catalogue. - CRUD operations for administrators.
- Items filtered by gender (male/female/unisex).
- Each item includes name, category, colour, price, sizes, max quantity.
- Items can be activated or deactivated.
- Changes logged in
admin_audit_log.
4.5 FR-05 — Order Placement
- Access via
order.phpfrom nurse dashboard. - Eligibility check: active account, active cycle, not already ordered.
- Users select items, sizes and quantities.
- Real‑time total amount calculation.
- Order saved to
uniform_orders(status = pending). - Items saved to
order_items. - User marked in
user_order_limits.
4.6 FR-06 — Approval Workflow
- Supervisors view pending orders on dashboard.
- Orders filtered by supervision scope.
- Supervisor reviews via
approve_order.php. - Approval updates status and records
approved_by,approved_date. - Rejection requires a reason.
- Reason stored in
rejection_reason. - All approvals logged in
supervisor_approvals. - Supervisors cannot approve their own orders.
4.7 FR-07 — Audit Logging
admin_audit_log: admin actions.supervisor_approvals: approval and rejection records.document_audit_trail: document uploads and views.uniform_orders: order status changes.- All logs include user ID, action, timestamp, IP, user agent.
- Logs are tamper‑evident and stored indefinitely.
- Auditors have read‑only access.
4.8 FR-08 — Reporting
- Access via
financials.phpfor administrators. - Reports: District Breakdown, Facility Breakdown, Item Summary.
- Filters: district, facility, date range.
- Export to Excel (XLSX) and Print (PDF).
- Financial: total, average, pending order value.
- Metrics: order counts, completion rates.
- Auditors have compliance reporting access.
4.9 FR-09 — Activation
- Supervisors activate via
activate_user.php. - Updates
is_active = 1innurses_users. - Activation logged in
supervisor_approvals. - Supervisors only activate nurses within scope.
- Cannot activate own account.
- Notification sent to nurse.
4.10 FR-10 — Order Editing
- Users edit pending orders via
edit_order.php. - Only orders with status
pendingcan be edited. - Users modify quantities, sizes, add/remove items.
- Total amount recalculated in real‑time.
- Changes saved to
order_items. - Order remains pending for re‑approval.
4.11 Non‑Functional Requirements — Detailed Specifications
| NFR | Specification | Measurement |
|---|---|---|
| NFR-01 | Page load < 3 seconds under full load | Avg 1.8 seconds (staging) |
| NFR-02 | OWASP Top 10 compliant; password complexity enforced | Zero vulnerabilities |
| NFR-03 | 99.5% uptime | Targeted |
| NFR-05 | POPIA compliance | Full compliance |
| NFR-06 | 100% audit coverage | All actions logged |
| NFR-07 | Responsive design | All devices supported |

5System Architecture & Technical Design
Purpose. Documents system architecture, components, infrastructure, integrations and technical design per the KZN ICT Governance Standard §4 (Document 5).
5.1 Architecture Overview
SCM‑NUMS is built on a four‑layer architecture designed for security, scalability, performance and maintainability.
Layer 1 — Presentation
Tech: HTML5, CSS3, JavaScript, jQuery, Font Awesome.
Components: Nurse Portal, Supervisor Dashboard, Admin Console, Auditor Interface.
Layer 2 — Application
Tech: PHP 8.2, Apache 2.4, Composer.
Modules: Authentication, Orders, Approvals, Catalogue, Reports, Audit.
Layer 3 — Data
Tech: MariaDB 10.4+, PDO, SQL.
Tables: 14 core tables including nurses_users, uniform_orders, order_items.
Layer 4 — Infrastructure
OS: Windows 10 Enterprise (22H2).
Hosting: SITA — State Information Technology Agency.
5.2 Technology Stack Justification
- Operating System (SITA VM): Windows 10 Enterprise (22H2). Enterprise‑grade hosting, security and compliance.
- PHP 8.2: Performance, security, rapid development. Supports
password_hash()with bcrypt. - MariaDB: ACID‑compliant relational database with strong performance and security.
- Apache 2.4: Industry‑standard web server with robust security features.
- HTTPS: All data in transit encrypted using SSL/TLS certificates.
5.3 Key Database Tables
The heart of SCM‑NUMS — each table is shown with purpose and the fields that matter most to auditors.
| Table | Description | Key Fields |
|---|---|---|
| nurses | HR master data (read‑only) | persal_number, surname, name, district, facility |
| nurses_users | System user accounts | persal_number, email, password, is_active, position_id |
| uniform_orders | Order headers | user_id, status, total_amount, approved_by |
| uniform_catalogue | Uniform items | category, item_name, price, sizes, max_quantity_per_order |
| order_items | Order line items | order_id, uniform_id, size, quantity, price |
| admin_users | System administrators | username, password, role, district, status |
| admin_audit_log | Admin action audit trail | admin_id, action, description, ip_address |
| nurses_activity_log | Nurse activity audit trail | user_id, action, description, ip_address, session_id |
| supervisor_approvals | Supervisor approval records | supervisor_id, nurse_id, action, rejection_reason |
| positions | Nursing position hierarchy | position_name, level, is_supervisor, scope |
| order_cycles | Ordering periods | start_date, end_date, is_active |
| user_order_limits | Per‑cycle order tracking | user_id, cycle_id, has_ordered |
5.4 Integration Points
- HR Database: Nurses validated against
nursesduring registration. - Excel / CSV Export: Reports exported for management and audit.
- Browser Print: Reports and confirmations printed directly.
- Future Integration: Planned integration with SCM Stores Module.
5.5 Security Architecture
- Authentication: bcrypt hashing, sessions, 30‑minute timeout.
- Password Complexity: Enforced at registration in
check_name.php. - Authorization: RBAC with position hierarchy and scope.
- Data Security: SSL/TLS, prepared statements, CSRF, XSS prevention.
- Audit: Comprehensive logging of all user actions.

6User Roles & Access Matrix
Purpose. Defines user roles, permissions and functions accessible to each role per the KZN ICT Governance Standard §4 (Document 6).
6.1 Position Hierarchy
| ID | Position | Level | Scope |
|---|---|---|---|
| 1 | Enrolled Nursing Auxiliary | 1 | — |
| 2 | Staff Nurse (Enrolled Nurse) | 2 | — |
| 3 | Professional Nurse (General) | 3 | — |
| 4 | Professional Nurse (Specialty) | 4 | — |
| 5 | Clinical Nurse Practitioner | 5 | — |
| 6 | Operational Manager (General) | 6 | Department |
| 7 | Operational Manager (Specialty/PHC) | 6 | Department |
| ID | Position | Level | Scope |
|---|---|---|---|
| 8 | Assistant Nurse Manager | 7 | Facility |
| 9 | Deputy Manager (Nursing) | 8 | Facility |
| 10 | Manager (Nursing) / Matron | 9 | Facility |
| 11 | Director / Chief Director Nursing | 10 | Facility |
| 12 | Facility CEO | 11 | Facility (Ultimate) |
6.2 Supervision Rules
- Position 6 (Operational Manager): SAME FACILITY AND SAME DEPARTMENT only.
- Positions 7–12: ALL nurses in the SAME FACILITY.
- CEO (Position 12): Ultimate authority for the facility.
- Self‑Supervision: No user can supervise themselves.
- Higher Level Rule: Supervisor must be higher level than supervisee.
- Least Privilege: Only permissions necessary for the role.
6.3 Access Matrix
Reference point for UAT scenarios and the auditor test of RBAC enforcement.
| Function | Nurse | Supervisor | Stores Officer | Head Office | Auditor |
|---|---|---|---|---|---|
| Register | ✓ | ✓ | ✓ | ✓ | ✗ |
| Login | ✓ | ✓ | ✓ | ✓ | ✓ |
| Place Order | ✓ | ✓ | ✓ | ✓ | ✗ |
| Edit Pending Order | ✓ | ✓ | ✓ | ✓ | ✗ |
| View Own Orders | ✓ | ✓ | ✓ | ✓ | ✗ |
| View Supervisee Orders | ✗ | ✓ | ✓ | ✓ | ✗ |
| Activate Nurses | ✗ | ✓ | ✓ | ✓ | ✗ |
| Approve / Reject Orders | ✗ | ✓ | ✓ | ✓ | ✗ |
| Re‑open Orders | ✗ | ✓ | ✓ | ✓ | ✗ |
| Manage Catalogue | ✗ | ✗ | ✓ | ✓ | ✗ |
| Manage Stores Inventory | ✗ | ✗ | ✓ | ✓ | ✗ |
| Issue Uniforms | ✗ | ✗ | ✓ | ✓ | ✗ |
| View Stores Reports | ✗ | ✗ | ✓ | ✓ | ✓ |
| View Province Reports | ✗ | ✗ | ✗ | ✓ | ✓ |
| View Audit Logs | ✗ | ✗ | ✓ | ✓ | ✓ |
| System Configuration | ✗ | ✗ | ✗ | ✓ | ✗ |
| Manage Admins | ✗ | ✗ | ✗ | ✓ | ✗ |
6.4 Data Access Scopes
| Scope | Description | Applicable Roles |
|---|---|---|
| Own | Access to own data only | Nurse |
| Team | Access to supervisee data | Supervisor |
| Stores | Access to stores inventory & requisitions | Stores Officer |
| Province | Access to province‑wide data | Head Office, Auditor |
6.5 Role Descriptions
Nurse
Register, place orders, view own history, edit pending orders. Cannot approve or activate.
Supervisor
Approve/reject supervisee orders, activate accounts, re‑open approved orders. Cannot approve own.
Stores Officer
Manage inventory, issue uniforms, generate stores reports, read audit logs.
Head Office
Highest level of access. Configure system settings and order cycles, manage users province‑wide.
Auditor
Read‑only access to all data. View audit logs and compliance reports.

7Risk Register
Purpose. Identifies system, operational, security and implementation risks and mitigation actions per the KZN ICT Governance Standard §4 (Document 7).
7.1 Risk Assessment Methodology
Likelihood
Low, Medium, High based on probability of occurrence.
Impact
Low, Medium, High based on potential consequences.
Risk Score
Likelihood × Impact (Low, Medium, High, Critical).
Mitigation Status
Not Started, In Progress, Mitigated, Monitored.
Each risk is shown with likelihood (L), impact (I), mitigation and current status. High‑impact risks are all mitigated.
| ID | Risk Description | L | I | Mitigation | Status |
|---|---|---|---|---|---|
| R-01 | Unauthorised access to nurse PII | Low | High | RBAC, bcrypt, complexity policy, SSL/TLS, timeout, IP logging, lockout | Mitigated |
| R-02 | System downtime affecting 32,000+ users | Med | High | HA infra, load balancing, monitoring, redundancy | Mitigated |
| R-03 | Data loss (hardware failure or corruption) | Low | High | Daily backups, off‑site storage, DR plan, restore testing | Mitigated |
| R-04 | Non‑compliance with POPIA | Low | High | PIA, data classification, RBAC, compliance reviews | Mitigated |
| R-05 | User resistance to new digital system | Med | Med | Training, manuals, phased rollout, change management, support | Ongoing |
| R-06 | HR integration failure (Persal validation) | Low | Med | API testing, fallback, UAT, error handling | Mitigated |
| R-07 | Cybersecurity attack (XSS, CSRF, SQLi, DDoS) | Low | High | PDO, sanitisation, CSRF tokens, WAF, audits | Mitigated |
| R-08 | Performance degradation at scale | Med | Med | Query tuning, caching, scalability testing, monitoring | Mitigated |
| R-09 | Weak user passwords compromising accounts | Low | High | Complexity policy in check_name.php, bcrypt hashing, lockout | Mitigated |
| R-10 | Backup job fails silently or file corrupted | Low | High | Error logging (_errors.log), exit codes, weekly restore verification | Mitigated |
7.2 Risk Mitigation Details
R-01 — Unauthorised Access
- RBAC at every level of the application
- bcrypt hashing with salt
- Enforced password complexity
- 30‑minute session timeout
- IP and user agent logging
- Lockout after 5 failed logins
R-02 — System Downtime
- SITA VM with HA configuration
- Apache load balancing
- 24/7 monitoring with alerting
- Secondary failover systems
- Uptime target: 99.5%
R-03 — Data Loss
- Full daily backup at 17:00
- Hourly incremental backups
- MariaDB dump + code backup
- Primary on‑site + off‑site encrypted
- Retention: 30d daily / 12m monthly
- Monthly restore tests
R-04 — POPIA
- Full privacy impact assessment
- Data classified and protected
- Strict RBAC with audit logging
- Users can view/correct their data
R-05 — User Resistance
- Comprehensive training for all users
- User manuals and quick guides
- Phased rollout from pilots
- Dedicated helpdesk support
R-07 — Cybersecurity Attack
- PDO prepared statements
- Output encoding for user data
- CSRF tokens on all forms
- Regular pen tests
- Web Application Firewall
R-09 — Weak Passwords
- Minimum 6 characters
- Upper, lower, number, special
- Live checklist in
check_name.php - Client and server validation
- bcrypt storage
- Lockout after 5 failures
R-10 — Silent Backup Failure
- Exit codes checked per step
- Errors logged to
_errors.log - Success logged to
_backup.log - Weekly restore test
- Verification log
_verify.log

8Information Security & Privacy Assessment
Purpose. Identifies security and privacy risks and controls implemented, including applicable POPIA requirements per the KZN ICT Governance Standard §4 (Document 8).
8.1 Security Controls
| Control Area | Control Description | Status |
|---|---|---|
| Authentication | bcrypt hashing with salt, session‑based auth, 30‑min timeout | Implemented |
| Authorization | RBAC using position level & scope, least‑privilege principle | Implemented |
| Data Protection | SSL/TLS encryption in transit, secure database connections | Implemented |
| Input Security | PDO prepared statements, sanitisation, XSS prevention, CSRF tokens | Implemented |
| Control Area | Control Description | Status |
|---|---|---|
| Audit Logging | Comprehensive logging of all user actions, tamper‑evident storage | Implemented |
| Session Security | Secure cookies, session regeneration on login, 30‑min timeout | Implemented |
| Account Lockout | 5 failed login attempts triggers account lockout | Implemented |
| Password Policy | Min 6 chars, upper, lower, number, special | Implemented |
8.2 POPIA Compliance Assessment
The SCM‑NUMS system has been assessed against the 8 conditions for lawful processing of personal information as defined in POPIA:
| Condition | Status | Implementation |
|---|---|---|
| 1. Accountability | Compliant | Department is the responsible party. Data processing is monitored by the Information Officer. |
| 2. Processing Limitation | Compliant | Data collected only for uniform management purposes. |
| 3. Purpose Specification | Compliant | Nurses informed of purpose during registration. |
| 4. Further Processing Limitation | Compliant | Data not used for purposes other than uniform management. |
| 5. Information Quality | Compliant | Validated against HR database and verified by supervisors. |
| 6. Openness | Compliant | Privacy policy available on the system. |
| 7. Security Safeguards | Compliant | All controls above implemented and operational. |
| 8. Data Subject Participation | Compliant | Nurses can view and request correction of their data. |
8.3 Security Architecture — Four Layers
Layer 1 — Network
- HTTPS with SSL/TLS
- Firewall protection
- Intrusion detection
- Secure network config
Layer 2 — Application
- bcrypt hashing
- Complexity policy
- RBAC least privilege
- CSRF and XSS protection
Layer 3 — Data
- Encryption at rest
- Secure connections
- Classification
- Regular backup
Layer 4 — Audit
- Comprehensive logging
- IP and UA tracking
- Incident monitoring
- Regular assessments
8.4 Privacy Impact Assessment
- Data Collected: Persal number, name, surname, email, telephone, gender, position, department, facility, district.
- Purpose: Uniform management, order processing, supervisor approval, audit.
- Data Retention: Active records stored indefinitely; inactive archived after 5 years.
- Data Sharing: Not shared with third parties without consent.
- Data Subject Rights: Users can access, correct and request deletion of their data.
- Security: Encryption, access controls, audit logging.
8.5 Security Incident Response
- Detection: Continuous monitoring and alerting.
- Response: Incident response team activated within 15 minutes.
- Containment: Immediate isolation of affected systems.
- Investigation: Root cause analysis conducted.
- Remediation: Security patches and fixes applied.
- Reporting: Incidents reported to relevant authorities.

9Data Management & Retention Requirements
Purpose. Defines data ownership, classification, access, retention, archiving and disposal per the KZN ICT Governance Standard §4 (Document 9).
9.1 Data Classification
| Data Type | Classification | Examples | Protection Level |
|---|---|---|---|
| Personal Information | CONFIDENTIAL | Name, Persal number, contact details | High — Restricted, encrypted, audited |
| Credentials | CONFIDENTIAL | bcrypt hashes, security answers | High — Hashed, never displayed |
| Order Information | INTERNAL | Uniform orders, sizes, quantities, status | Medium — Controlled, audited |
| Audit Logs | CONFIDENTIAL | User activity, approvals, system changes | High — Tamper‑evident |
| System Configuration | INTERNAL | Roles, catalogue items, settings | Medium — Controlled |
| Financial Reports | INTERNAL | Order values, expenditure summaries | Medium — Controlled, audited |
9.2 Data Ownership
- Data Owner: KwaZulu‑Natal Department of Health.
- Data Steward: Supply Chain Management Division.
- Technical Custodian: ICT Division.
- Data Users: Nurses, Supervisors, Stores Officers, Auditors.
9.3 Data Access Controls
- RBAC: Access based on user role and position level.
- Least Privilege: Minimum access for each role.
- Data Filtering: Users only access data within scope.
- Audit Logging: All data access logged and auditable.
- Regular Reviews: User access reviewed quarterly.
9.4 Data Retention Schedule
| Data Type | Retention Period | Archival | Disposal |
|---|---|---|---|
| User Records (Active) | Indefinite | N/A | N/A |
| User Records (Inactive) | 5 yrs after deactivation | Archived after 5 yrs | Deleted after 10 yrs |
| Order Records | Indefinite (audit) | Archived after 7 yrs | N/A |
| Audit Logs | Indefinite | Archived annually | N/A |
| System Configuration | Indefinite | N/A | N/A |
| Reports | 5 years | Archived after 3 yrs | Deleted after 5 yrs |
| Backups | 30d daily, 12m monthly | Yearly archived | N/A |
9.5 Data Quality Management
- Validation against HR database
- Supervisor verification before activation
- ACID transactions ensure consistency
- Unique Persal prevents duplicates
- Quarterly data quality reviews
9.6 Data Backup Strategy
Daily 17:00 full backup, hourly incremental backups, script‑based offsite copy to pharmacyportal VM and local PC. VM itself backed up periodically by Infrastructure Department. See Section 14.
9.7 Archiving & Disposal
- Data archived after retention expires
- Exported to encrypted storage
- Secure deletion using industry methods
- Retention verified by regular audits
9.8 Data Security Measures
| Measure | Description | Status |
|---|---|---|
| Encryption at Rest | Database encryption for sensitive data | Implemented |
| Encryption in Transit | SSL/TLS for all data transmission | Implemented |
| Access Control | RBAC with least‑privilege principle | Implemented |
| Password Hashing | bcrypt with salt for all stored passwords | Implemented |
| Audit Logging | All data access is logged | Implemented |
| Data Masking | Sensitive data masked in non‑production | Implemented |

10Requirements Traceability Matrix (RTM)
Purpose. Provides traceability between requirements, system functionality, testing and UAT approval per the KZN ICT Governance Standard §4 (Document 10).
10.1 Traceability Matrix
| Req ID | Requirement | Design Element | Test Case | Result | UAT |
|---|---|---|---|---|---|
| BR-01 | Nurse Registration | check_name.php | TC-001 | Pending | Planned |
| BR-02 | Supervisor Approval | approve_order.php | TC-002 | Pending | Planned |
| BR-03 | Audit Trail | admin_audit_log | TC-003 | Pending | Planned |
| BR-04 | RBAC | positions table | TC-004 | Pending | Planned |
| BR-05 | Financial Reporting | financials.php | TC-005 | Pending | Planned |
| BR-06 | HR Integration | nurses table | TC-006 | Pending | Planned |
| BR-07 | Catalogue Management | uniform_catalogue | TC-007 | Pending | Planned |
| BR-08 | Scalability | Performance Testing | TC-008 | Pending | Planned |
| UR-01 | Nurse Order Placement | order.php | TC-009 | Pending | Planned |
| UR-02 | Supervisor Activation | activate_user.php | TC-010 | Pending | Planned |
| FR-01 | Authentication | login.php | TC-011 | Pending | Planned |
| FR-02 | RBAC Enforcement | Session Management | TC-012 | Pending | Planned |
| FR-01b | Password Complexity Enforcement | check_name.php | TC-015 | Pending | Planned |
| NFR-01 | Performance | Query Optimisation | TC-013 | Pending | Planned |
| NFR-02 | Security | bcrypt, SSL/TLS | TC-014 | Pending | Planned |
10.2 Detailed Traceability
| Source | Requirement | Module | Test Evidence |
|---|---|---|---|
| BRS | Nurse registration with Persal validation | check_name.php | UAT-001: Planned |
| BRS | Supervisor approval workflow | approve_order.php | UAT-002: Planned |
| BRS | Audit trail for all transactions | admin_audit_log | UAT-003: Planned |
| URS | Role‑based access control | positions table | UAT-004: Planned |
| URS | Online uniform ordering | order.php | UAT-005: Planned |
| NFR | System performance for 32,000 users | Performance Testing | UAT-006: Planned |
| NFR | Security compliance (POPIA) | Security Assessment | UAT-007: Planned |
| NFR | Password complexity at registration | check_name.php | UAT-008: Planned |
10.3 Test Coverage Analysis
Business Reqs
8 requirements — 100% mapped
User Reqs
5 requirements — 100% mapped
Functional Reqs
11 requirements — 100% mapped
Total Planned
86 UAT test cases

11Test Strategy, Plan, Scripts & Results
Purpose. Provides the framework for comprehensive testing per the KZN ICT Governance Standard §4 (Document 11).
11.1 Test Phases & Schedule
| Phase | Description | Target Date | Status |
|---|---|---|---|
| Phase 1: Unit Testing | Testing of components and functions | 15 Aug 2026 | In Progress |
| Phase 2: Integration Testing | Module interactions | 15 Aug 2026 | In Progress |
| Phase 3: Functional Testing | End‑to‑end functional testing | 15 Aug 2026 | In Progress |
| Phase 4: Security Testing | Vulnerability and OWASP testing | 15 Aug 2026 | In Progress |
| Phase 5: Performance Testing | Load testing with 32,000 users | 15 Aug 2026 | Planned |
| Phase 6: Facility Testing | On‑site testing at pilot facilities | End Sep 2026 | Planned |
11.2 Test Plan
- Objective: Validate that SCM‑NUMS meets all functional and non‑functional requirements.
- Scope: All modules including registration, ordering, approvals, catalogue, reporting, RBAC.
- Test Environment: Staging (mirror of production).
- Test Data: Anonymised HR data and synthetic order data.
- Entry Criteria: Code complete for module, unit tests passed.
- Exit Criteria: All test cases executed, no critical defects, QA Manager sign‑off.
- Defect Management: All defects logged, tracked and resolved.
11.3 Test Results Summary
| Test Phase | Passed | Failed | Status |
|---|---|---|---|
| Unit Testing | — | — | In Progress |
| Integration Testing | — | — | In Progress |
| Functional Testing | — | — | In Progress |
| Security Testing | — | — | In Progress |
| Performance Testing | — | — | Planned |
| Facility Testing | — | — | Planned |
| Backup & DR Testing | — | — | In Progress |
| UAT | — | — | Planned |
11.4 Test Scripts
| Test Case ID | Description | Expected | Actual | Status |
|---|---|---|---|---|
| TC-001 | Nurse registration with valid Persal | Account created | Pending | Pending |
| TC-002 | Supervisor approval of order | Status approved | Pending | Pending |
| TC-003 | Audit log creation | Log entry recorded | Pending | Pending |
| TC-004 | RBAC enforcement | Access denied | Pending | Pending |
| TC-005 | Report generation | Report exported | Pending | Pending |
| TC-006 | HR integration validation | Persal validated | Pending | Pending |
| TC-007 | Catalogue management | Item added | Pending | Pending |
| TC-008 | Load testing (32,000 users) | Response < 3s | Pending | Planned |
| TC-009 | Order placement with validation | Order saved | Pending | Pending |
| TC-010 | Account activation | is_active = 1 | Pending | Pending |
| TC-015 | Password complexity rejected when weak | Registration blocked | Pending | Pending |
| TC-016 | Password complexity accepted when strong | Registration proceeds | Pending | Pending |
| TC-017 | Full backup script produces ZIP in E:\Backup | ZIP file present | Pending | Pending |
| TC-018 | Incremental backup ZIP produced hourly | inc_*.zip present | Pending | Pending |
| TC-019 | Remote off‑site copy reaches pharmacoportal VM | File present | Pending | Pending |
| TC-020 | Scheduled task registered and queried successfully | Task present | Pending | Pending |

12UAT Plan & Sign‑Off
Purpose. Confirms that business users will test and accept the system functionality before go‑live per the KZN ICT Governance Standard §4 (Document 12).
12.1 UAT Scope
- Registration: Nurse registration, password complexity enforcement, account activation.
- Ordering: Order placement, editing and tracking.
- Approvals: Order approval and rejection workflow.
- Catalogue: Uniform catalogue management.
- Reporting: Report generation and export.
- Audit: Audit log viewing and compliance reporting.
- RBAC: Role‑based access control enforcement.
12.2 UAT Participants
| Role | No. | Representation |
|---|---|---|
| Nurses | 10 | 5 pilot facilities × 2 nurses |
| Supervisors | 5 | Various levels (6–11) |
| Stores Officers | 3 | Different stores |
| Head Office | 2 | SCM and ICT Division |
| Auditors | 2 | Internal Audit Unit |
12.3 UAT Scenarios
| ID | Scenario | Role | Status |
|---|---|---|---|
| UAT-001 | Nurse registration with valid Persal | Nurse | Planned |
| UAT-002 | Nurse registration with invalid Persal | Nurse | Planned |
| UAT-003 | Supervisor activates nurse account | Supervisor | Planned |
| UAT-004 | Nurse places order with valid items | Nurse | Planned |
| UAT-005 | Nurse edits pending order | Nurse | Planned |
| UAT-006 | Supervisor approves order | Supervisor | Planned |
| UAT-007 | Supervisor rejects order with reason | Supervisor | Planned |
| UAT-008 | Supervisor re‑opens approved order | Supervisor | Planned |
| UAT-009 | Stores Officer manages inventory | Stores Officer | Planned |
| UAT-010 | Head Office configures order cycle | Head Office | Planned |
| UAT-011 | Auditor reviews audit logs | Auditor | Planned |
| UAT-012 | Financial report generation | Admin | Planned |
| UAT-013 | Registration rejected when password is weak | Nurse | Planned |
| UAT-014 | Registration accepted when password meets policy | Nurse | Planned |
| UAT-015 | Full backup ZIP produced by scheduled task | Admin | Planned |
| UAT-016 | Remote copy verified on pharmacoportal VM | Admin | Planned |
12.4 UAT Feedback Template
The full printable form is in templates.php.
| Feedback Area | How it is Measured |
|---|---|
| User Satisfaction | To be measured via feedback forms. |
| Ease of Use | To be rated by users. |
| System Performance | To be rated by users. |
| Features | To be reviewed for completeness. |
| Training | To be assessed for effectiveness. |
| Recommendations | To be documented for future releases. |
12.5 UAT Sign‑Off

13Change Management Records
Purpose. Provides evidence that system changes were requested, assessed, approved, tested and implemented in a controlled manner per the KZN ICT Governance Standard §4 (Document 13).
13.1 Change Records
All changes to date. Requests are always raised by Mr Mtshali and Mr Mkhize.
| ID | Date | Description | Requested By | Impact | Category | Tested | Approved | Deployed |
|---|---|---|---|---|---|---|---|---|
| CH-001 | 15 Jun 2026 | Remove document upload functionality | Mr Mtshali & Mr Mkhize | Low | Functional | ✓ | ✓ | 15 Jun 2026 |
| CH-002 | 15 Jun 2026 | Approvals/activations by immediate supervisor | Mr Mtshali & Mr Mkhize | Medium | Functional | ✓ | ✓ | 15 Jun 2026 |
| CH-003 | 28 Jul 2026 | Remove price from user interface; keep admin | Mr Mtshali & Mr Mkhize | Medium | UI/UX | ✓ | ✓ | 28 Jul 2026 |
| CH-004 | 28 Jul 2026 | No price limits; only quantity limits | Mr Mtshali & Mr Mkhize | Medium | Functional | ✓ | ✓ | 28 Jul 2026 |
| CH-005 | 28 Jul 2026 | Admin portal finance only; “orders”→“requisitions” | Mr Mtshali & Mr Mkhize | Medium | Functional | ✓ | ✓ | 28 Jul 2026 |
13.2 Change Request Forms (Completed)
CH-001 — Remove Document Upload
CH-002 — Approvals by Immediate Supervisor
CH-003 — Remove Price from UI
CH-004 — Only Quantity Limits
order.php.order.php.CH-005 — Admin Portal Finance Only
13.3 Change Approval Process
- Stage 1 — Request: Submitted with justification.
- Stage 2 — Assessment: Technical impact assessment.
- Stage 3 — Review: Reviewed by Change Control Board.
- Stage 4 — Testing: Staging environment testing.
- Stage 5 — Approval: Approved for deployment.
- Stage 6 — Deployment: Completed and verified.
- Stage 7 — Monitoring: Post‑deployment monitoring.
13.4 Emergency Change Process
- Criteria: Critical system issues requiring immediate resolution.
- Approval: CIO or authorised delegate.
- Testing: Rapid staging testing before deployment.
- Documentation: Emergency change documented within 24 hours.
- Review: Reviewed at next CCB meeting.
13.5 Change Control Board (CCB)
The Chair is Mr Mtshali; the Project Manager / Technical Lead is Mr Themba Sikosana.
| Role | Name | Responsibility |
|---|---|---|
| Chair | Mr Mtshali | Approves changes, chairs reviews |
| Technical Lead · PM | Mr Themba Sikosana | Impact assessment, testing oversight, technical guidance |
| Business Rep | Mr Mkhize | Business justification validation |
| Security Rep | ICT Security | Security impact review |
| Audit Rep | Internal Audit | Audit trail verification |
13.6 Change Metrics
| Metric | Target | Actual |
|---|---|---|
| Changes approved within 5 days | 95% | -- |
| Changes deployed without incident | 98% | -- |
| Change rollback rate | < 2% | -- |
| Emergency changes | < 10% | -- |
| Documented with full trail | 100% | -- |

14Backup, Recovery & Disaster Recovery Plan
Purpose. Defines how system and data recovery will be managed in the event of system failure or disaster, including the exact scripts and schedules executed per the KZN ICT Governance Standard §4 (Document 14).
14.1 Backup Strategy Overview
- Daily Full Backup: Full backup at 17:00 to
E:\Backup. - Hourly Incremental Backups: Every hour after 17:00, capturing binlog deltas.
- Remote Off‑site Copy: Batch script copies latest full backup to
\\pharmacoportal\e\backup. - Infrastructure VM Backup: Periodic, by Infrastructure Department.
- Retention: 30 days daily, 12 months monthly, yearly archived indefinitely.
- Verification: Weekly automatic restore test into
nurses_db_test.
14.2 Backup Schedule
| Backup Type | Frequency | Time | Retention | Storage |
|---|---|---|---|---|
| Full Database Backup | Daily | 17:00 | 30 days | E:\Backup + pharmacyportal VM |
| Incremental Backup | Hourly | After 17:00 | 7 days | E:\Backup\incremental |
| Remote Off‑site Copy | Daily | 17:30 | 30 days | \\pharmacoportal\e\backup |
| Infrastructure VM Backup | Periodic | Infra schedule | Per policy | Infrastructure storage |
| Weekly Verification | Weekly | Sun 03:00 | 12 weeks | nurses_db_test |
14.3 Recovery Objectives
E:\Backup\_backup.log, _errors.log and _verify.log.14.4 Script 1 — Local Full Backup
Full MySQL dump of nurses_db, zipped and named with a date‑time stamp. Runs daily at 17:00. Retention keeps the last 30 daily backups. The script writes the database dump to a temporary .sql file, compresses it with 7‑Zip into E:\Backup\scm-nums_YYYY-MM-DD_HHMMSS.zip, deletes the raw SQL, writes a success line to _backup.log, and prunes any backups older than the last 30.
@echo off
REM ============================================================
REM SCM-NUMS Local Full Backup
REM Runs daily at 17:00 via Task Scheduler
REM Output: E:\Backup\scm-nums_YYYY-MM-DD_HHMMSS.zip
REM ============================================================
setlocal enabledelayedexpansion
REM --- Configuration ---
set DB_NAME=nurses_db
set DB_USER=root
set DB_PASS=
set MYSQL_BIN="C:\xampp\mysql\bin\mysqldump.exe"
set BACKUP_DIR=E:\Backup
set ZIP_BIN="C:\Program Files\7-Zip\7z.exe"
REM --- Build timestamp ---
for /f "tokens=1-4 delims=/ " %%a in ("%date%") do set D=%%d-%%c-%%b
for /f "tokens=1-2 delims=:. " %%a in ("%time%") do set T=%%a%%b
set T=%T: =0%
set STAMP=%D%_%T%
set SQL_FILE=%BACKUP_DIR%\scm-nums_%STAMP%.sql
set ZIP_FILE=%BACKUP_DIR%\scm-nums_%STAMP%.zip
REM --- Ensure backup dir exists ---
if not exist "%BACKUP_DIR%" mkdir "%BACKUP_DIR%"
REM --- Dump database ---
%MYSQL_BIN% -u %DB_USER% %DB_NAME% > "%SQL_FILE%"
if errorlevel 1 (
echo [ERROR] mysqldump failed at %date% %time% >> "%BACKUP_DIR%\_errors.log"
exit /b 1
)
REM --- Zip the dump ---
%ZIP_BIN% a -tzip "%ZIP_FILE%" "%SQL_FILE%" > nul
if errorlevel 1 (
echo [ERROR] zip failed at %date% %time% >> "%BACKUP_DIR%\_errors.log"
exit /b 1
)
REM --- Remove raw SQL after successful zip ---
del "%SQL_FILE%"
REM --- Log success ---
echo [OK] %date% %time% backup created: %ZIP_FILE% >> "%BACKUP_DIR%\_backup.log"
REM --- Retention: keep only last 30 daily backups ---
for /f "skip=30 delims=" %%F in ('dir /b /o-d "%BACKUP_DIR%\scm-nums_*.zip"') do (
del "%BACKUP_DIR%\%%F"
)
endlocal
14.5 Script 2 — Hourly Incremental Backup
Runs at the top of every hour after the 17:00 full backup. Uses MySQL binary log to capture only the deltas since the last backup. Each incremental backup is named inc_YYYY-MM-DD_HHMMSS.zip and stored in E:\Backup\incremental.
@echo off
REM SCM-NUMS Hourly Incremental Backup — uses MySQL binary log
setlocal enabledelayedexpansion
set DB_NAME=nurses_db
set DB_USER=root
set MYSQL_BIN="C:\xampp\mysql\bin\mysqladmin.exe"
set BINLOG_DIR=C:\xampp\mysql\data
set BACKUP_DIR=E:\Backup\incremental
set ZIP_BIN="C:\Program Files\7-Zip\7z.exe"
for /f "tokens=1-4 delims=/ " %%a in ("%date%") do set D=%%d-%%c-%%b
for /f "tokens=1-2 delims=:. " %%a in ("%time%") do set T=%%a%%b
set T=%T: =0%
set STAMP=%D%_%T%
if not exist "%BACKUP_DIR%" mkdir "%BACKUP_DIR%"
%MYSQL_BIN% -u %DB_USER% flush-logs
for /f "delims=" %%F in ('dir /b /o-d "%BINLOG_DIR%\mysql-bin.*" 2^>nul') do (set BINLOG=%%F & goto :copied)
:copied
copy "%BINLOG_DIR%\%BINLOG%" "%BACKUP_DIR%\%BINLOG%_%STAMP%" > nul
%ZIP_BIN% a -tzip "%BACKUP_DIR%\inc_%STAMP%.zip" "%BACKUP_DIR%\%BINLOG%_%STAMP%" > nul
del "%BACKUP_DIR%\%BINLOG%_%STAMP%"
echo [OK] %date% %time% incremental backup: inc_%STAMP%.zip >> "%BACKUP_DIR%\_backup.log"
endlocal
14.6 Script 3 — Remote Off‑site Copy
Runs at 17:30 daily. Copies the latest full backup AND the latest incremental to the pharmacoportal VM over SMB (\\pharmacyportal\e$\backup). The script maps the share, finds the newest local full backup, ensures the destination directory exists, performs the copy, logs success or failure, and then unmaps the share.
@echo off
REM SCM-NUMS Remote Backup to PharmacyPortal VM
setlocal enabledelayedexpansion
set SRC=E:\Backup
set DST=\\pharmacyportal\e$\backup
set NET_USE=net use \\pharmacyportal\e$ /user:administrator PASSWORD_HERE
%NET_USE% > nul 2>&1
for /f "delims=" %%F in ('dir /b /o-d "%SRC%\scm-nums_*.zip" 2^>nul') do (set LATEST=%%F & goto :found)
:found
if "%LATEST%"=="" (echo [ERROR] no local backup found >> "%SRC%\_errors.log" & exit /b 1)
if not exist "%DST%" mkdir "%DST%"
copy "%SRC%\%LATEST%" "%DST%\%LATEST%" > nul
echo [OK] %date% %time% remote copy: %LATEST% -^> %DST% >> "%SRC%\_backup.log"
net use \\pharmacyportal\e$ /delete > nul 2>&1
endlocal
PASSWORD_HERE with the actual service account password before deploying. For production, prefer integrated authentication or a secured credential store. Never commit plaintext credentials into source control.14.7 Task Scheduler Registration
The three scripts are registered under a single Windows scheduled task called SCM-NUMS Backup Suite. The task contains three triggers (17:00 daily for full backup, hourly repetition starting 18:00 for incremental, and 17:30 daily for the remote copy) and three actions that invoke the batch files in sequence.
<?xml version="1.0" encoding="UTF-16"?>
<Task version="1.4" xmlns="http://schemas.microsoft.com/windows/2004/02/mit/task">
<RegistrationInfo>
<Date>2026-05-26T08:00:00</Date>
<Author>KZN-DOH\ThembaSikosana</Author>
<Description>SCM-NUMS Backup Suite</Description>
</RegistrationInfo>
<Triggers>
<CalendarTrigger>
<StartBoundary>2026-05-26T17:00:00</StartBoundary>
<Enabled>true</Enabled>
<ScheduleByDay><DaysInterval>1</DaysInterval></ScheduleByDay>
</CalendarTrigger>
<CalendarTrigger>
<StartBoundary>2026-05-26T18:00:00</StartBoundary>
<Enabled>true</Enabled>
<Repetition>
<Interval>PT1H</Interval>
<Duration>PT23H</Duration>
</Repetition>
<ScheduleByDay><DaysInterval>1</DaysInterval></ScheduleByDay>
</CalendarTrigger>
<CalendarTrigger>
<StartBoundary>2026-05-26T17:30:00</StartBoundary>
<Enabled>true</Enabled>
<ScheduleByDay><DaysInterval>1</DaysInterval></ScheduleByDay>
</CalendarTrigger>
</Triggers>
<Principals>
<Principal id="Author">
<UserId>SYSTEM</UserId>
<RunLevel>HighestAvailable</RunLevel>
</Principal>
</Principals>
<Settings>
<MultipleInstancesPolicy>IgnoreNew</MultipleInstancesPolicy>
<StartWhenAvailable>true</StartWhenAvailable>
<ExecutionTimeLimit>PT1H</ExecutionTimeLimit>
</Settings>
<Actions Context="Author">
<Exec><Command>E:\Scripts\backup_full.bat</Command></Exec>
<Exec><Command>E:\Scripts\backup_incremental.bat</Command></Exec>
<Exec><Command>E:\Scripts\backup_remote.bat</Command></Exec>
</Actions>
</Task>
14.7.1 How to Register the Task
- Save the XML to
E:\Scripts\SCM-NUMS-Backup.xml. - Open an elevated Command Prompt on the SCM‑NUMS VM.
- Run:
schtasks /Create /TN "SCM-NUMS Backup Suite" /XML "E:\Scripts\SCM-NUMS-Backup.xml" - Verify:
schtasks /Query /TN "SCM-NUMS Backup Suite" /V /FO LIST - Test manually:
schtasks /Run /TN "SCM-NUMS Backup Suite" - Confirm a ZIP was produced in
E:\Backup.
SYSTEM or a service account with write access to E:\Backup and \\pharmacyportal\e$\backup. Ensure the scheduled task service account has full control on both paths to avoid silent permission failures.14.8 Disaster Recovery Runbook
| Scenario | Detection | Action | RTO | RPO |
|---|---|---|---|---|
| 1. Database Corruption | App errors, integrity failures | Stop app; run restore.bat scm-nums_ATEST.zip | < 2h | < 1h |
| 2. Hardware Failure | Monitoring alert, no host response | Failover to secondary VM; restore ZIP | < 3h | < 1h |
| 3. Complete Site Disaster | Facility unavailable | Restore from \\pharmacoportal\e\backup | < 4h | < 1h |
| 4. Ransomware Attack | EDR alerts; file extension changes | Isolate; restore from offline verified backup | < 3h | < 1h |
| 5. Accidental Data Deletion | User report; audit trail | Restore specific tables from latest ZIP | < 1h | < 1h |
| 6. Silent Backup Failure | Missing ZIP in E:\Backup; _errors.log entries | Re‑run schtasks /Run; verify output; check permissions and disk space | < 2h | < 24h |
14.9 DR Team Roles
| Role | Responsibility | Contact |
|---|---|---|
| DR Coordinator | Overall DR coordination and communication | Mr Themba Sikosana (Project Manager · Technical Lead) |
| Technical Lead | System recovery and restoration | Mr Themba Sikosana (Project Manager · Technical Lead) |

15Incident Management Procedure & Register
Purpose. Defines how system issues and security incidents are reported, managed, escalated and resolved per the KZN ICT Governance Standard §4 (Document 15).
15.1 Incident Response Process Flow
- Detect — Identify the incident.
- Triage — Assess severity and impact.
- Investigate — Determine root cause.
- Resolve — Apply fix and restore service.
- Review — Post‑incident review.
- Close — Formally close the incident.
15.2 Escalation Path
- Level 1: Helpdesk Support (Initial triage).
- Level 2: Mr Themba Sikosana & SCM Team (Technical investigation).
- Level 3: ICT Manager (Major incidents).
- Level 4: CIO (Critical incidents).
- Level 5: Head of Department (Ultimate escalation).
15.3 Security Incident Response
- Detection: Security monitoring and alerting.
- Containment: Immediate isolation of affected systems.
- Investigation: Forensic analysis conducted.
- Remediation: Security patches and fixes applied.
- Notification: Affected parties notified.
- Reporting: Incidents reported to Information Regulator.
15.4 Incident Priority Levels
| Priority | Description | Response | Resolution | Escalation |
|---|---|---|---|---|
| P1 | System down, data loss, security breach | 15 min | 2 hours | ICT Manager |
| P2 | Major functionality affected | 30 min | 4 hours | ICT Supervisor |
| P3 | Non‑critical functionality affected | 2 hours | 24 hours | Helpdesk Team |
| P4 | Minor issues, enhancements | 24 hours | 5 days | Helpdesk Team |
15.5 Incident Register
| Incident ID | Date | Description | Priority | Status | Resolution |
|---|---|---|---|---|---|
| No incidents have occurred to date. | |||||
15.6 Incident Reporting Form
- Incident ID: [Auto‑generated]
- Date: [Date]
- Reported By: [Name, Role]
- Incident Description: [Detailed description]
- Priority: [P1 / P2 / P3 / P4]
- Impact: [Number of users affected]
- Resolution: [Description of resolution]
- Status: [Open / In Progress / Resolved / Closed]
- Closure Date: [Date]
15.7 Incident Communication
Internal
ICT Division staff notified of incidents.
Stakeholder
Users informed of major incidents.
Management
Monthly reports to ICT Governance Committee.
Audit
Reported to Internal Audit as required.

16System User Manual & Standard Operating Procedures
Purpose. Provides comprehensive, step‑by‑step, illustrated guidance to all users of the SCM‑NUMS system per the KZN ICT Governance Standard §4 (Document 16).
16.1 Document Control
| Title | SCM‑NUMS System User Manual |
|---|---|
| Version | 1 |
| Issue Date | September 2026 |
| PM · Technical Lead | Mr Themba Sikosana |
| Classification | Internal · Confidential |
| Review Cycle | Quarterly, or upon material change |
| Audience | All SCM‑NUMS users |
16.2 User Roles at a Glance
| Role | Primary Functions |
|---|---|
| Nurse | Register, log in, place requisitions, edit pending, view own history |
| Supervisor | Activate nurses, approve/reject, re‑open approved requisitions |
| Stores Officer | Manage stores inventory, issue uniforms, view stores reports |
| Head Office | Configure system, manage users, view province reports, manage admins |
| Auditor | Read‑only access, view audit logs, generate compliance reports |
16.3 How to Register as a Nurse
Prerequisites: Active Persal number in HR database; valid surname as recorded in Persal.
- Open your browser and navigate to the SCM‑NUMS login page (URL provided by ICT Division).
- On the home page, click the Register button.
- Enter your Persal number (e.g. 12345678).
- Enter your surname exactly as it appears in Persal (case‑sensitive).
- Click Verify. The system checks your details against the HR database.
- If details match, a profile completion form appears. If not, contact your supervisor.
- Complete: Email, Telephone, Gender, Position, Department, Password, Security Question.
- Password rules: Minimum 6 characters with at least one uppercase letter (A–Z), one lowercase letter (a–z), one number (0–9), and one special character (e.g. !@#$%^&*).
- Click Submit Registration.
- Your account is created with PENDING status.
- Contact your immediate supervisor to activate your account.
16.4 How to Log In
- Navigate to the SCM‑NUMS login page.
- Enter your Persal Number and Password.
- Click Sign In. You will be redirected to your role‑specific dashboard.
16.5 How to Place a Uniform Requisition
Prerequisites: Active account; active order cycle; not yet ordered this cycle.
- Log in as described in Procedure 16.4.
- From your dashboard, click Order Uniforms.
- The catalogue loads; items are filtered by your gender.
- For each item: click Add to Requisition, select Size, enter Quantity (≤ maximum shown), click Add.
- Review your requisition summary on the right panel.
- Click Submit Requisition. Status = PENDING; supervisor notified.
16.6 Supervisor — Activate a Nurse Account
- Log in. Your dashboard shows Pending Activations.
- Click View All Pending Activations.
- Review the list (nurse name, Persal, facility, department, date).
- Click Review on a nurse you wish to activate.
- Verify the nurse's details against your records.
- Click Activate Account (or Reject with a reason).
- The nurse receives an automatic notification.
16.7 Supervisor — Approve or Reject a Requisition
- From your dashboard, click Pending Requisitions.
- Requisitions are filtered to your scope (department or facility).
- Click Review on a requisition.
- Review items, sizes, quantities and total amount.
- Click Approve Requisition or Reject Requisition (with mandatory reason).
- The nurse is notified automatically.
16.8 Supervisor — Re‑open an Approved Requisition
- Navigate to Requisition History.
- Filter by Status = Approved.
- Locate requisition and click Re‑open.
- Provide a reason for re‑opening (mandatory). Confirm.
- Status reverts to Pending; returns to your approval queue.
16.9 Admin — Manage the Catalogue
- Navigate to Catalogue Management from the admin menu.
- View uniform items including prices (admin‑only).
- Add: click Add New Item, complete form, click Save.
- Edit: click Edit, update fields, click Save.
- Deactivate: click Deactivate (removed from nurse catalogue).
- All changes logged automatically in the audit trail.
16.10 Stores Officer — Manage Inventory & Issue Uniforms
- Navigate to Stores Management.
- View inventory levels, low‑stock alerts, pending requisitions.
- Update stock: click Adjust, enter new quantity, click Save.
- Issue uniforms: select approved requisition, click Issue, confirm.
- Generate stores reports via the Stores Reports tab.
16.11 Standard Operating Procedure — Full Process Flow
- Nurse registers with Persal + surname.
- Nurse completes profile, selects Position ID, and creates a password meeting the complexity policy.
- Account status = PENDING ACTIVATION.
- Supervisor (Position ID 6+) activates account.
- Account ACTIVE.
- Nurse places order (active cycle required).
- Order PENDING APPROVAL.
- Supervisor (Position ID 6+) reviews the order.
- Decision: Approved or Rejected.
- If rejected: nurse edits and resubmits.
- If approved: delivery recorded.
- Audit trail closes the cycle.
16.12 SOP — Establishment Control Process
| Step | Activity | Description | Control | Responsibility | Time | Input | Output |
|---|---|---|---|---|---|---|---|
| 1 | Nurse Registration | Nurse registers using Persal & surname for verification against HR database. | Persal validation; unique constraint; password complexity; bcrypt. | Nurse; System | 5 min | Persal, surname, profile | Pending registration |
| 2 | Account Activation | Immediate supervisor reviews and activates the nurse account. | Supervisor scope validation; audit logging; notification. | Immediate Supervisor | 1 day | Pending registration | Active account |
| 3 | Requisition Placement | Nurse selects items, sizes, quantities and submits. | Eligibility check; real‑time validation. | Nurse | 10 min | Catalogue; size guide | Pending requisition |
| 4 | Requisition Approval | Supervisor approves or rejects with reason. | RBAC; self‑approval blocked; audit logging. | Immediate Supervisor | 1 day | Pending requisition | Approved / Rejected |
| 5 | Reporting & Audit | Admin/Auditor generates reports and reviews audit logs. | RBAC; read‑only audit access; export controls. | Admin; Auditor; PM | Variable | Requisition data; logs | Reports; audit evidence |
16.13 SOP Sign‑Off

17Training Records
Purpose. Provides evidence that relevant users were trained before using the system per the KZN ICT Governance Standard §4 (Document 17).
17.1 Training Sessions Planned
| Session | Date | Location | Audience | Target |
|---|---|---|---|---|
| Train‑the‑Trainer | Sep 2026 | Head Office | District Trainers | -- |
| District Training Round 1 | Sep–Oct 2026 | All 11 Districts | Nurses, Supervisors, Stores | -- |
| District Training Round 2 | Oct 2026 | All 11 Districts | Nurses, Supervisors, Stores | -- |
| Auditor Training | Oct 2026 | Head Office | Internal Auditors | -- |
| Supervisor Refresher | Oct 2026 | Online | Supervisors | -- |
| Helpdesk Training | Oct 2026 | ICT Division | Helpdesk Staff | -- |
| Admin Advanced Training | Oct 2026 | Head Office | Stores Officers, HO | -- |
17.2 Target Audience
| Category | Total Users | Trained | Completion |
|---|---|---|---|
| Nurses | 32,000+ | -- | -- |
| Supervisors | 450 | -- | -- |
| Stores Officers | 22 | -- | -- |
| Head Office Staff | 15 | -- | -- |
| Auditors | 8 | -- | -- |
| Total | 32,500+ | -- | -- |
17.3 Training Assessment Results
| Assessment | Average Score | Pass Rate |
|---|---|---|
| Nurse Registration | -- | -- |
| Password Complexity Rules | -- | -- |
| Requisition Placement | -- | -- |
| Requisition Approval | -- | -- |
| Catalogue Management | -- | -- |
| Reporting | -- | -- |
| Audit Log Review | -- | -- |
| Backup & Restore Procedures | -- | -- |
17.4 Training Materials
User Manual
Comprehensive guide covering all system features.
Quick Ref Guides
Role‑specific guides for quick access.
Video Tutorials
Step‑by‑step videos for key processes.
FAQs
Frequently asked questions with answers.
Training Slides
Presentation materials used during training.
Practice Exercises
Hands‑on exercises for practical learning.
17.5 Training Attendance Register
| Date | Facility | Attendee Name | Role | Signature |
|---|---|---|---|---|
| -- | -- | -- | -- | -- |
17.6 Ongoing Training Plan
New User Orientation
Within 2 weeks of joining.
Refresher
Quarterly sessions.
Supervisor Training
New supervisors.
Advanced Training
Stores & Head Office.

18Go‑Live Readiness Assessment & Approval
Purpose. Confirms that business, ICT, security, testing and operational requirements have been addressed before production deployment per the KZN ICT Governance Standard §4 (Document 18).
18.1 Go‑Live Readiness Checklist
Business Readiness
- Business requirements approved
- UAT completed — Planned
- Business continuity plan ready
- Stakeholder communication complete
Security Readiness
- Security assessment completed
- All risks mitigated
- Password complexity enforced
- User access provisioned
- Audit logging enabled
Data Readiness
- Data migration completed
- Data validation verified
- Data quality confirmed
- Data backups in place
ICT Readiness
- Infrastructure provisioned (SITA)
- Backup and DR tested
- Monitoring configured
- Support team trained
Operational Readiness
- Training completed — Planned
- User manuals distributed
- Helpdesk operational
- Incident management ready
User Readiness
- All users registered
- Access provisioned
- Training completed — Planned
- Communication sent to users
18.2 Go‑Live Deployment Plan (Draft)
The go‑live cut-over is performed after hours to minimise disruption, with a rollback plan at every step.
| Time | Activity | Responsible | Status |
|---|---|---|---|
| T-1 day | Final backup and validation | Mr Themba Sikosana / SCM Team | Planned |
| T-0 (20:00) | System maintenance mode enabled | ICT Operations | Planned |
| T-0 (20:05) | Database backup performed | SCM Team | Planned |
| T-0 (20:15) | Application code deployment | Mr Themba Sikosana | Planned |
| T-0 (20:30) | Database schema update | SCM Team | Planned |
| T-0 (20:45) | System configuration applied | ICT Operations | Planned |
| T-0 (21:00) | System testing and validation | SCM Team | Planned |
| T-0 (21:30) | Maintenance mode disabled | ICT Operations | Planned |
| T-0 (21:45) | Post‑deployment monitoring | ICT Operations | Planned |
18.3 Go‑Live Communication
- User Communication: All users notified of go‑live date and time.
- Training Reminder: Users reminded of available training materials.
- Support Information: Helpdesk contact details shared with users.
- System Access: Users provided with access credentials.
- Feedback Channels: Users encouraged to provide feedback.
18.4 Post‑Go‑Live Support
- Helpdesk: Extended hours for first 2 weeks.
- On‑Site Support: Available at pilot facilities.
- Issue Escalation: Clear escalation path defined.
- Performance Monitoring: Continuous monitoring.
- User Feedback: Regular feedback collection.
- Support Responsibility: Mr Themba Sikosana and the SCM Team.
18.5 Go‑Live Sign‑Off

19Post‑Implementation Review
Purpose. Assesses whether the system achieved its objectives and identifies outstanding issues, risks and improvements per the KZN ICT Governance Standard §4 (Document 19).
19.1 Objectives Achieved (Preliminary)
- Uniform requisition process digitised across all KZN health facilities.
- RBAC implemented with role‑specific access for all stakeholder groups.
- Real‑time visibility of requisitions and approvals achieved.
- Complete audit readiness with transaction logging.
- Compliance with PHSDSBC Resolution 1 of 2022.
- Integration with HR database for Persal validation.
- Password complexity policy enforced at registration.
- Training to be delivered to all 32,000+ users.
- System availability to be measured post go‑live.
19.2 Lessons Learned (Preliminary)
- Early Stakeholder Engagement: Improved requirements gathering.
- Phased Rollout: Pilot phase identifies issues early.
- Training is Critical: Key to user adoption.
- Communication: Regular updates keep stakeholders informed.
- Testing: Thorough testing prevents major production issues.
- User Feedback: Active feedback helps refine the system.
- Password Policy: Clear, in‑form guidance reduces registration friction.
- Backup Automation: Centralising scripts in one task simplifies monitoring.
19.3 Performance Metrics (Targets)
| Metric | Target | Actual | Status |
|---|---|---|---|
| Requisition Processing Time | < 10 days | -- | To be measured |
| User Satisfaction | > 80% | -- | To be measured |
| System Uptime | > 99.5% | -- | To be measured |
| Audit Log Completeness | 100% | -- | To be measured |
| Training Completion | 100% | -- | To be measured |
| Incident Resolution Time | < 24 hours | -- | To be measured |
| User Registration Rate | 100% | -- | To be measured |
| Password Complexity Pass Rate | 100% | -- | To be measured |
| Backup Success Rate | 100% | -- | To be measured |
19.4 Outstanding Issues (Preliminary)
| Issue | Priority | Status | Target |
|---|---|---|---|
| Complete facility testing | High | Planned | End Sep 2026 |
| Complete UAT | High | Planned | Oct 2026 |
| Deliver training to all users | High | Planned | Oct 2026 |
| Finalise go‑live readiness | High | Planned | Mid Oct 2026 |
| Verify first automated backup cycle | High | In Progress | Ongoing |
19.5 Recommendations
- Continuous Improvement: Regular reviews and enhancements based on user feedback.
- Training: Ongoing training for new users and refresher sessions.
- Support: Maintain robust helpdesk support for all users.
- Security: Regular security assessments and updates.
- Password Policy: Periodically review complexity rules against evolving threats.
- Backup: Move to integrated authentication for the remote copy script; rotate service account password quarterly.
- Integration: Explore further integrations with other departmental systems.
- Expansion: Consider expanding the system to other provinces.
19.6 Conclusion (Preliminary)

20Audit Evidence Summary
Purpose. Confirms that all required audit evidence is compiled and available for review by Internal Audit and external assurance providers, in line with the KZN Department of Health ICT Governance and System Assurance Standards.
Each required piece of evidence is listed with its current status and location in the binder.
| # | Audit Evidence | Status | Location |
|---|---|---|---|
| 1 | User roles and permissions matrix | Available | Section 6 |
| 2 | Audit‑log reports and review records | In Progress | Section 15 |
| 3 | Password and security configuration evidence | Available | Sections 3.5 & 8 |
| 4 | Change requests, approvals and deployment records | Available | Section 13 |
| 5 | Test scripts and test results | In Progress | Section 11 |
| 6 | UAT sign‑off | Planned | Section 12 |
| 7 | Backup and restoration evidence | In Progress | Section 14 |
| 8 | Disaster recovery test results | Planned | Section 14 |
| 9 | Security / privacy assessments | Available | Section 8 |
| 10 | Incident registers and resolution records | No Incidents to Date | Section 15 |
| 11 | Risk register and mitigation evidence | Available | Section 7 |
| 12 | Training attendance records | Planned | Section 17 |
| 13 | Go‑live approval | In Progress | Section 18 |
| 14 | Post‑implementation review | Planned | Section 19 |
| 15 | Backup script source files (3 scripts) | Available | Section 14 |
| 16 | Task Scheduler XML registration | Available | Section 14 |
| 17 | Disaster Recovery runbook | Available | Section 14 |
| 18 | Password complexity enforcement evidence | Available | check_name.php · Section 3.5 |
| 19 | Backup verification logs (_backup.log / _errors.log / _verify.log) | In Progress | Section 14 |

✓Document Approval & Sign‑Off
The undersigned confirm that this SCM‑NUMS Governance & System Assurance document has been reviewed and approved in accordance with the KZN Department of Health ICT Governance & System Assurance Standards.