Table of Contents

This document pack constitutes the complete ICT Governance and System Assurance framework for the SCM-NUMS, in full compliance with the KZN Department of Health ICT Governance and System Assurance Standards.

Abbreviations & Acronyms

The following abbreviations and acronyms are used throughout this document. Each is expanded upon first use in the relevant section, and consolidated here for ease of reference.

1. Project Charter & Project Plan

Purpose: Defines the system purpose, scope, objectives, stakeholders, responsibilities, and implementation approach.

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 completed on 15 October 2026, delivering all planned objectives within scope and budget.

1.2 Project Identification

1.3 Project Purpose

The SCM-NUMS project 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.

The system addresses the following key challenges faced by the Department:

• Inefficient Manual Processes: Paper-based ordering was slow, error-prone, and lacked transparency.
• Lack of Visibility: Management had no real-time view of ordering patterns or expenditure.
• Audit Difficulties: Manual processes made it difficult to produce audit evidence.
• Fraud Risk: Lack of traceability created opportunities for mismanagement.
• Inconsistent Practices: No standardisation across districts and facilities.

1. Project Charter & Project Plan (Continued)

1.4 Project Scope

1.5 Project Objectives

1.6 Project Milestones

2. Business Requirements Specification (BRS/BRD)

Purpose: Documents the business requirements and expected system functionality.

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 in receiving their uniforms, supervisors struggle with tracking and managing orders, and management lacks visibility into ordering patterns and expenditure.

Specific problems identified include:

• Time Delays: Order processing takes 30+ days from request to delivery.
• Data Errors: Manual data entry leads to incorrect sizes, quantities, and nurse details.
• Lost Records: Paper forms are frequently lost or misplaced.
• No Audit Trail: Cannot track who ordered, who approved, or when changes were made.
• Inconsistent Practices: Each facility has different ordering procedures.
• Financial Leakage: Lack of visibility leads to budget overspending.

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 at any stage.
• Enable Complete Audit Trail: Every transaction is logged and traceable.
• Standardise Across Districts: Consistent ordering practices across all 11 districts.
• Ensure Compliance: Full compliance with PHSDSBC Resolution 1 of 2022.
• Improve Financial Accountability: Track expenditure and prevent fraud.

2.3 Key Business Requirements

2. Business Requirements Specification (Continued)

2.4 Stakeholder Groups

2.5 Business Process Changes

The implementation of SCM-NUMS introduces significant improvements to the business processes:

2.6 Success Criteria

• User Adoption: 100% of nurses registered within 6 months of deployment.
• Order Processing: Average order processing time reduced to under 10 days.
• Audit Readiness: All transactions logged and traceable.
• User Satisfaction: >80% positive feedback from users.
• System Performance: 99.5% uptime with response times under 3 seconds.

3. User & System Requirements (URS/FRS/NFR)

Purpose: Documents user requirements and defines the functional and non-functional requirements that the system must meet.

3.1 User Requirements

3.2 Functional Requirements

3. User & System Requirements (Continued)

3.3 Non-Functional Requirements

3.4 Non-Functional Requirements Detail

Security (NFR-02)

• Passwords stored using bcrypt hashing with salt.
• Session timeout after 30 minutes of inactivity.
• All traffic encrypted via HTTPS (SSL/TLS).
• CSRF protection tokens on all forms.
• Input sanitisation and prepared statements to prevent SQL injection.
• XSS prevention through output encoding.
• Account lockout after 5 failed login attempts.

Performance (NFR-01)

• Database indexes on foreign keys for fast queries.
• Optimised queries for order history and reporting.
• Caching mechanisms for frequently accessed data.
• Load testing to be conducted before go-live.

Usability (NFR-07)

• Fully responsive design using CSS media queries.
• Touch-friendly interfaces for mobile devices.
• Clear navigation with role-specific menus.
• Intuitive forms with validation feedback.
• Visual representations of uniform items.

4. Functional & Non-Functional Requirements

Purpose: Detailed breakdown of Functional and Non-Functional Requirements.

4.1 Functional Requirements Detail

FR-01: Registration

• Users access registration page via register.php.
• Enter Persal number and surname for verification against nurses table.
• If already registered, user is notified.
• If verified, user proceeds to profile completion.
• Profile includes: email, telephone, gender, position, department, password, security question.
• Position selection determines supervisor level and authority.
• Management positions (Level 7+) auto-assigned to Hospital Management Services department.
• Account created with is_active = 0 pending supervisor activation.

FR-02: Authentication

• Login via login.php with Persal number and password.
• Password verified using bcrypt comparison.
• Session created with user ID, role, district, facility.
• Session timeout after 30 minutes.
• Failed login attempts tracked for security monitoring.
• Account lockout after 5 consecutive failures.

FR-03: RBAC

• Access control based on positions.level and positions.scope.
• Five user roles: Nurse, Supervisor, Stores Officer, Head Office, Auditor.
• Menu items filtered based on role permissions.
• Action-level permissions (view, create, edit, delete, approve).
• Data-level filtering (own data, team data, district data, province data).
• Supervision scope: Department (Level 6) or Facility (Level 7+).

FR-04: Catalogue Management

• Uniform items stored in uniform_catalogue table.
• CRUD operations for administrators.
• Items filtered by gender (male/female/unisex).
• Each item includes: name, category, color, price, sizes, max quantity per order.
• Items can be activated or deactivated.
• Catalogue changes logged in admin_audit_log.

FR-05: Order Placement

• Access via order.php from nurse dashboard.
• System checks eligibility: active account, active cycle, not already ordered.
• Users select items, sizes, and quantities.
• Real-time total amount calculation.
• Order saved to uniform_orders with status 'pending'.
• Items saved to order_items table.
• User marked as having ordered in current cycle (user_order_limits).

4. Functional & Non-Functional Requirements (Continued)

FR-06: Approval Workflow

• Supervisors view pending orders in their dashboard.
• Orders are filtered based on supervision scope (department or facility).
• Supervisor reviews order details via approve_order.php.
• Approval updates status to 'approved' and records approved_by and approved_date.
• Rejection requires a reason and updates status to 'rejected'.
• Rejection reason stored in rejection_reason field.
• All approvals logged in supervisor_approvals table.
• Supervisors cannot approve their own orders.

FR-07: Audit Logging

• admin_audit_log: Admin actions (activate, deactivate, edit, login).
• 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 address, user agent.
• Logs are tamper-evident and stored indefinitely.
• Auditors have read-only access to all logs.

FR-08: Reporting

• Access via financials.php for administrators.
• Reports available: District Breakdown, Facility Breakdown, Item Summary.
• Filters: district, facility, date range.
• Export to Excel (XLSX) and Print (PDF).
• Financial summaries: total order value, average order value, pending value.
• Performance metrics: order counts, completion rates.
• Auditors have access to compliance reports.

FR-09: Activation

• Supervisors activate nurse accounts via activate_user.php.
• Activation updates is_active = 1 in nurses_users.
• Activation logged in supervisor_approvals.
• Supervisors can only activate nurses within their supervision scope.
• Supervisors cannot activate their own account.
• Activation sends notification to the nurse.

FR-10: Order Editing

• Users can edit pending orders via edit_order.php.
• Only orders with status 'pending' can be edited.
• Users can modify quantities, sizes, add/remove items.
• Total amount recalculated in real-time.
• Changes saved to order_items table.
• Order remains in 'pending' status for re-approval.

4.2 Non-Functional Requirements Detailed Specifications

5. System Architecture / Technical Design

Purpose: Documents the system architecture, components, infrastructure, integrations and technical design.

5.1 Architecture Overview

SCM-NUMS is built on a four-layer architecture designed for security, scalability, performance, and maintainability.

5.2 Four-Layer Architecture

5.3 Technology Stack Justification

• Operating System (SITA VM): Windows 10 Enterprise (22H2). SITA provides enterprise-grade hosting, security, and compliance for government systems.
• PHP 8.2: Performance improvements, security features, rapid development capabilities.
• MariaDB: ACID-compliant relational database with strong performance and security features.
• Apache 2.4: Industry-standard web server with robust security features.
• HTTPS: All data in transit is encrypted using SSL/TLS certificates.

5. System Architecture / Technical Design (Continued)

5.4 Key Database Tables

5.5 Integration Points

• HR Database Integration: Nurses are validated against the nurses table during registration.
• Excel/CSV Export: Reports can be exported for management and audit purposes.
• Browser Print: Reports and order confirmations can be printed directly from the browser.
• Future Integration: Planned integration with SCM Stores Module.

5.6 Security Architecture

• Authentication: bcrypt password hashing, session-based authentication, 30-minute timeout.
• Authorization: RBAC with position-based hierarchy and scope restrictions.
• Data Security: SSL/TLS encryption, prepared statements, CSRF protection, XSS prevention.
• Audit: Comprehensive logging of all user actions.

6. User Roles & Access Matrix

Purpose: Defines user roles, permissions and the information/functions accessible to each role.

6.1 Role Hierarchy

6.2 Position Hierarchy

6.3 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 entire facility.
• Self-Supervision: No user can supervise themselves.
• Higher Level Rule: Supervisor must have a higher level than supervisee.

6. User Roles & Access Matrix (Continued)

6.4 Access Matrix

6.5 Data Access Scopes

6.6 Role Descriptions

Nurse

• Can register, place orders, view own order history, edit pending orders.
• Cannot approve orders or activate accounts.

Supervisor

• Can approve/reject orders from supervisees.
• Can activate nurse accounts.
• Can re-open approved orders.
• Cannot approve own orders.

Stores Officer

• Manages stores inventory & requisition fulfilment.
• Issues uniforms to nurses.
• Generates stores reports.
• Read access to requisitions & audit logs.

Head Office

• Highest level of access.
• Configures system settings and order cycles.
• Manages all users province-wide.

Auditor

• Read-only access to all data.
• Can view audit logs and compliance reports.

7. Risk Register

Purpose: Identifies system, operational, security and implementation risks and their mitigation actions.

7.1 Risk Management Overview

The risk management process for SCM-NUMS follows a structured approach to identify, assess, mitigate, and monitor risks throughout the system lifecycle. The risk register is maintained by the ICT Governance Committee and reviewed quarterly.

7.2 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.

7.3 Risk Register

7. Risk Register (Continued)

7.4 Risk Mitigation Details

R-01: Unauthorised Access

• RBAC enforced at every level of the application.
• bcrypt hashing with salt for password storage.
• 30-minute timeout with secure session handling.
• IP logging and user agent tracking for all actions.
• 5 failed login attempts triggers account lockout.

R-02: System Downtime

• SITA-hosted virtual machine with high availability configuration.
• Apache with load balancing for traffic distribution.
• 24/7 system monitoring with alerting.
• Secondary failover systems in place.
• Uptime Target: 99.5%.

R-03: Data Loss

• Full daily backup at 5:00 PM, then hourly incremental backups.
• MariaDB dump + application code backup.
• Primary on-site + Secondary off-site encrypted storage.
• Retention: 30 days daily, 12 months monthly.
• Monthly restore tests verify backup integrity.

R-04: POPIA Non-Compliance

• Full privacy impact assessment conducted.
• All data classified and protected accordingly.
• Strict RBAC with audit logging.
• Users can view and request correction of their data.

R-05: User Resistance

• Comprehensive training delivered to all users.
• User manuals and quick reference guides provided.
• Phased rollout starting with pilot facilities.
• Dedicated helpdesk for user support.

R-07: Cybersecurity Attack

• Prepared statements (PDO) for all database queries.
• Output encoding for all user-supplied data.
• Tokens on all forms and state-changing requests.
• Regular security assessments and penetration testing.
• Web Application Firewall in place.

7.5 Risk Monitoring

• Quarterly Review: Reviewed by ICT Governance Committee.
• Incident Tracking: All security incidents logged and investigated.
• Audit Findings: Regular audits identify new risks.
• User Feedback: Operational risks identified through feedback.
• System Monitoring: Continuous monitoring for performance and security.

8. Information Security / Privacy Assessment

Purpose: Identifies security and privacy risks and the controls implemented to address them, including applicable POPIA requirements.

8.1 Security Controls

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 the Protection of Personal Information Act (POPIA):

8. Information Security / Privacy Assessment (Continued)

8.3 Security Architecture

The security architecture of SCM-NUMS is built on a multi-layered approach to ensure comprehensive protection:

8.4 Privacy Impact Assessment

• Data Collected: Persal number, name, surname, email, telephone, gender, position, department, facility, district.
• Purpose of Collection: Uniform management, order processing, supervisor approval, audit.
• Data Retention: Active records stored indefinitely; inactive records archived after 5 years.
• Data Sharing: Data is not shared with third parties without consent.
• Data Subject Rights: Users can access, correct, and request deletion of their data.
• Security Measures: All personal data protected through 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 as required.

9. Data Management & Retention Requirements

Purpose: Defines data ownership, classification, access, retention, archiving and disposal requirements.

9.1 Data Classification

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 is granted based on user role and position level.
• Least Privilege: Users have minimum access required for their role.
• Data Filtering: Users can only access data within their scope.
• Audit Logging: All data access is logged and auditable.
• Regular Reviews: User access is reviewed quarterly.

9.4 Data Retention Schedule

9. Data Management & Retention Requirements (Continued)

9.5 Data Quality Management

• Validation: Data is validated against HR database during registration.
• Verification: Supervisors verify nurse details before activation.
• Data Integrity: ACID-compliant transactions ensure data consistency.
• Duplicate Prevention: Unique constraint on Persal number prevents duplicates.
• Regular Audits: Data quality reviews are conducted quarterly.

9.6 Data Backup Strategy

See Section 14 for the complete backup strategy, scripts, schedules, and DR procedures. Backup is performed daily at 17:00, followed by hourly incremental backups, plus a script-based offsite copy to the pharmacyportal VM and a local PC. The VM itself is backed up periodically by the Infrastructure Department.

9.7 Data Archiving and Disposal

• Archiving: Data is archived after the retention period expires.
• Archival Format: Data is exported to encrypted storage format.
• Disposal: Data is securely deleted using industry-standard methods.
• Retention Verification: Regular audits ensure compliance with retention policies.

9.8 Data Security Measures

9.9 Data Breach Response

• Detection: Continuous monitoring and alerting.
• Containment: Immediate isolation of affected systems.
• Investigation: Root cause analysis conducted.
• Notification: Affected parties notified within 72 hours.
• Remediation: Security patches and fixes applied.
• Reporting: Breaches reported to Information Regulator as required.

10. Requirements Traceability Matrix (RTM)

Purpose: Provides traceability between requirements, system functionality, testing and UAT approval.

10.1 RTM Overview

The RTM ensures that every requirement is linked to a specific design element, test case, and UAT sign-off. This provides full visibility into coverage and validation of all requirements.

10.2 Traceability Matrix

10. Requirements Traceability Matrix (Continued)

10.3 Detailed Traceability

10.4 Test Coverage Analysis

• Business Requirements: 8 requirements, 100% mapped.
• User Requirements: 5 requirements, 100% mapped.
• Functional Requirements: 10 requirements, 100% mapped.
• Non-Functional Requirements: 10 requirements, 100% mapped.
• Total Test Cases Planned: 85 UAT test cases.

10.5 RTM Sign-Off (Pending)

11. Test Strategy, Test Plan, Test Scripts & Results

Purpose: Provides the framework for comprehensive testing, including templates and plans, to be executed before go-live.

11.1 Test Strategy Overview

The testing strategy for SCM-NUMS follows a comprehensive, multi-phase approach. Testing is currently underway and will be completed before go-live.

11.2 Test Phases & Schedule

11.3 Test Plan

• Objective: To validate that SCM-NUMS meets all functional and non-functional requirements.
• Scope: All modules including registration, ordering, approvals, catalogue, reporting, RBAC.
• Test Environment: Staging environment (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, sign-off by QA Manager.
• Defect Management: All defects logged, tracked, and resolved.

11. Test Strategy, Test Plan, Test Scripts & Results (Continued)

11.4 Test Script Template

11.5 Test Results Template

12. UAT Plan & Sign-Off

Purpose: Confirms that business users will test and accept the system functionality before go-live.

12.1 UAT Overview

User Acceptance Testing (UAT) will be conducted to validate that the SCM-NUMS system meets the needs of its users and performs as expected in real-world scenarios.

12.2 UAT Scope

• Registration: Nurse registration and account activation process.
• 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.3 UAT Participants (Planned)

12.4 UAT Test Scenarios (Planned)

12. UAT Plan & Sign-Off (Continued)

12.5 UAT Test Execution Plan

• Test Duration: To be conducted after internal testing (target: September 2026).
• Test Environment: Staging environment (mirror of production).
• Test Data: Realistic test data to be created for each scenario.
• Defect Management: All defects to be logged and resolved.
• Sign-Off: Business users will sign off on successful completion.

12.6 UAT Feedback Template

• 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.7 UAT Sign-Off (Pending)

13. Change Management Records

Purpose: Provides evidence that system changes were requested, assessed, approved, tested and implemented in a controlled manner.

13.1 Change Management Process Flow

13.2 Change Records

13.3 Change Detail — CH-001 to CH-005

CH-001: Remove Document Upload

• Business Justification: Duplicated HR records; unnecessary attack surface.
• Impact: Low — no user workflows depended on this feature.
• Testing: Regression suite passed; no orphaned records.
• Rollback: Restore code from tagged release v1.2.

CH-002: Approvals by Immediate Supervisor

• Business Justification: Aligns with PHSDSBC supervision hierarchy.
• Impact: Medium — affects every approval workflow.
• Testing: Scope-based routing tests passed for all levels.

CH-003: Remove Price from User Interface

• Business Justification: Avoid bias in requisition quantities.
• Impact: Medium — user-facing change; admin retains price visibility.

CH-004: Only Quantity Limits

• Business Justification: Finance uses quantity caps, not rand caps.
• Impact: Medium — updated validation logic in order.php.

CH-005: Admin Portal — Finance Only; "Orders" → "Requisitions"

• Business Justification: Clarifies language throughout the system.
• Impact: Medium — label changes plus admin menu re-scoping.

13. Change Management Records (Continued)

13.4 Change Request Form Template

The following template is used for all change requests. The fields are identical to those stored in the document_change_records table (editable via update.php).

13.5 Change Approval Process

1. Stage 1 — Request: Change request submitted with justification.
2. Stage 2 — Assessment: Technical impact assessment conducted.
3. Stage 3 — Review: Change reviewed by Change Control Board.
4. Stage 4 — Testing: Testing conducted in staging environment.
5. Stage 5 — Approval: Change approved for deployment.
6. Stage 6 — Deployment: Deployment completed and verified.
7. Stage 7 — Monitoring: Post-deployment monitoring conducted.

13.6 Emergency Change Process

• Criteria: Critical system issues requiring immediate resolution.
• Approval: CIO or authorised delegate approval.
• Testing: Rapid testing in staging before deployment.
• Documentation: Emergency change documented within 24 hours.
• Review: Emergency changes reviewed at next CCB meeting.

13.7 Release Management

• Major Releases: Quarterly (new features, major enhancements).
• Minor Releases: Monthly (bug fixes, small enhancements).
• Hotfixes: As needed (critical fixes).
• Release Schedule: Planned releases communicated in advance.
• Rollback Procedure: Documented rollback plans for all releases.

13. Change Management Records (Continued)

13.8 Change Control Board (CCB)

13.9 Change Metrics (To Be Updated)

14. Backup, 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.

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 the latest full backup to \\pharmacyportal\e$\backup and to another local PC.
• Infrastructure VM Backup: Performed periodically by the Infrastructure Department.
• Retention: 30 days of daily backups, 12 months of monthly backups, yearly backups archived indefinitely.
• Verification: Weekly automatic restore test into nurses_db_test.

14.2 Backup Schedule

14.3 Recovery Objectives

14.4 Script 1 — Local Full Backup (E:\Backup\backup_full.bat)

Full MySQL dump of nurses_db, zipped and named with the date-time stamp. Runs daily at 17:00. Retention keeps the last 30 daily backups.

@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.

@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 pharmacyportal VM over SMB (\\pharmacyportal\e$\backup).

@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

14.7 Task Scheduler Registration

The following XML is imported into Windows Task Scheduler to register all three scripts on the correct schedule.

<?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

1. Save the XML to E:\Scripts\SCM-NUMS-Backup.xml.
2. Open an elevated Command Prompt on the SCM-NUMS VM.
3. Run: schtasks /Create /TN "SCM-NUMS Backup Suite" /XML "E:\Scripts\SCM-NUMS-Backup.xml"
4. Verify: schtasks /Query /TN "SCM-NUMS Backup Suite" /V /FO LIST
5. Test manually: schtasks /Run /TN "SCM-NUMS Backup Suite"
6. Confirm a ZIP was produced in E:\Backup.

14.8 Disaster Recovery Runbook

14.9 DR Team Roles

15. Incident Management Procedure / Register

Purpose: Defines how system issues and security incidents are reported, managed, escalated and resolved.

15.1 Incident Management Overview

The incident management process ensures that all system issues and security incidents are properly reported, tracked, investigated, and resolved. The process follows industry best practices and is aligned with KZN Health ICT standards.

Note: To date, no incidents have occurred. The following procedures, templates, and documentation are in place. Responsibility for support is with Mr Themba Sikosana and the SCM Team. Reports are developed by Mr Themba Sikosana.

15.2 Incident Response Process Flow

15.3 Incident Priority Levels

15.4 Incident Register (To Be Populated)

15. Incident Management Procedure / Register (Continued)

15.5 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.6 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 as required.
• Reporting: Incidents reported to Information Regulator.

15.7 Incident Communication

• Internal Communication: ICT Division staff notified of incidents.
• Stakeholder Communication: Users informed of major incidents.
• Management Reporting: Monthly incident reports to ICT Governance Committee.
• Audit Reporting: Incidents reported to Internal Audit as required.

15.8 Incident Reporting Form

16. System User Manual — Introduction & Overview

Purpose: Provides comprehensive, step-by-step, illustrated guidance to all users of the SCM-NUMS system.

16.1 About This Manual

This User Manual is designed for all SCM-NUMS users — Nurses, Supervisors, Stores Officers, Head Office staff, and Auditors. It provides detailed, step-by-step instructions with illustrations for every task you will perform. Each procedure includes prerequisites, numbered steps with reference images, expected outcomes, and troubleshooting tips.

16.2 Document Control

16.3 System Overview

SCM-NUMS (Nurse Uniform Management System) is a web-based platform that digitises the nurse uniform ordering, approval, and distribution process across the KwaZulu-Natal Department of Health. The system serves over 32,000 nurses across 11 districts and 700+ health facilities.

User Roles at a Glance

16.4 How to Register as a Nurse

Prerequisites: Active Persal number in HR database; valid surname as recorded in Persal.

1. Open your browser and navigate to the SCM-NUMS login page (URL provided by ICT Division).
2. On the home page, click the "Register" button.
3. The registration form will appear. In the Persal Number field, enter your Persal number (e.g., 12345678).
4. In the Surname field, enter your surname exactly as it appears in Persal (case-sensitive).
5. Click "Verify". The system will check your details against the HR database.
6. If your details match, a profile completion form will appear. If they do not match, contact your supervisor.
7. Complete the following fields:
   • Email Address: Your official work email.
   • Telephone: Your contact number (e.g., 033 395 2121).
   • Gender: Select Male or Female.
   • Position: Select your nursing position from the dropdown.
   • Department: Select your department.
   • Password: Minimum 12 characters with uppercase, lowercase, number, special character.
   • Security Question: Select a question and provide an answer.
8. Click "Submit Registration".
9. Your account will be created with PENDING status.
10. Contact your immediate supervisor to activate your account.

Expected Outcome: Your account is created and awaiting supervisor activation.

Troubleshooting: If your Persal details are not found, verify the number and surname match Persal exactly.

16.5 How to Log In

Prerequisites: Activated account; valid password.

1. Navigate to the SCM-NUMS login page.
2. Enter your Persal Number.
3. Enter your Password.
4. Click "Sign In".
5. You will be redirected to your role-specific dashboard.

Troubleshooting: After 5 failed attempts, your account will be locked for 30 minutes.

16.6 How to Place a Uniform Requisition

Prerequisites: Active account; active order cycle; not yet ordered this cycle.

1. Log in as described in Procedure 16.5.
2. From your dashboard, click "Order Uniforms".
3. The catalogue will load. Items are automatically filtered by your gender.
4. For each item:
   • Click "Add to Requisition".
   • Select the Size (refer to the size chart).
   • Enter the Quantity (must not exceed the maximum shown).
   • Click "Add".
5. Review your requisition summary on the right panel.
6. Click "Submit Requisition".
7. Your requisition is now in PENDING status; supervisor is notified.

Note: Prices are not displayed on the user interface. Only the Admin/Finance portal displays prices.

16.7 Supervisor: Activate a Nurse Account

Prerequisites: Logged in as supervisor; nurse within your supervision scope.

1. Log in. Your dashboard shows "Pending Activations".
2. Click "View All Pending Activations".
3. Review the list. Each row shows: nurse name, Persal, facility, department, date.
4. Click "Review" on a nurse you wish to activate.
5. Verify the nurse's details against your records.
6. To activate: click "Activate Account". To reject: click "Reject", provide a reason, and confirm.
7. The nurse receives an automatic notification.

16.8 Supervisor: Approve or Reject a Requisition

Prerequisites: Logged in as supervisor; pending requisition from a supervisee.

1. From your dashboard, click "Pending Requisitions".
2. Requisitions are filtered to your scope (department or facility).
3. Click "Review" on a requisition.
4. Review items, sizes, quantities, and total amount.
5. To approve: click "Approve Requisition".
6. To reject: click "Reject Requisition", enter a clear reason (mandatory), and confirm.
7. The nurse is notified automatically.

Note: You cannot approve your own requisition.

16.9 Supervisor: Re-open an Approved Requisition

Prerequisites: Logged in as supervisor; requisition is currently Approved.

1. Navigate to "Requisition History".
2. Filter by status = Approved.
3. Locate the requisition and click "Re-open".
4. Provide a reason for re-opening (mandatory).
5. Confirm. Status reverts to Pending and returns to your approval queue.

16.10 Admin: Manage the Catalogue

Prerequisites: Logged in as Stores Officer or Head Office.

1. Navigate to "Catalogue Management" from the admin menu.
2. View the list of uniform items, including prices (admin-only view).
3. To add a new item: click "Add New Item". Complete the form, then click "Save".
4. To edit: click "Edit", update fields, click "Save".
5. To deactivate: click "Deactivate". Deactivated items no longer appear in the nurse catalogue.
6. All changes are logged automatically in the audit trail.

16.11 Stores Officer: Manage Inventory & Issue Uniforms

Prerequisites: Logged in as Stores Officer.

1. Navigate to "Stores Management".
2. View current inventory levels, low-stock alerts, and pending requisitions.
3. To update stock: click "Adjust", enter new quantity, and Save.
4. To issue uniforms: select an approved requisition, click "Issue", confirm, and the nurse is notified.
5. Generate stores reports via the "Stores Reports" tab.

16.12 Standard Operating Procedure — Full Process Flow

The diagram below shows the end-to-end SCM-NUMS workflow from nurse registration through requisition delivery and audit closure.

16.13 Standard Operating Procedure — Document Control

16.14 SOP — Establishment Control Process

16.15 SOP Sign-Off

17. Training Records

Purpose: Provides evidence that relevant users were trained before using the system.

17.1 Training Program Overview

A comprehensive training program will be developed and delivered to ensure all users are proficient in using the SCM-NUMS system. Training includes instructor-led sessions, hands-on practice, and self-paced learning materials.

17.2 Training Sessions Planned

17.3 Training Materials Provided

• User Manual: Comprehensive guide covering all system features.
• Quick Reference 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.4 Training Completion Statistics

17. Training Records (Continued)

17.5 Training Assessment Results (To Be Populated)

17.6 Training Attendance Register Template

17.7 Training Feedback Template

• Training Quality: To be rated by users.
• Training Relevance: To be rated by users.
• Training Materials: To be rated by users.
• Trainer Effectiveness: To be rated by users.
• Recommendations: To be documented for future sessions.

17.8 Ongoing Training Plan

• New User Orientation: Training for all new nurses within 2 weeks of joining.
• Refresher Training: Quarterly refresher sessions for existing users.
• Supervisor Training: Specialised training for new supervisors.
• Advanced Training: Stores Officer and Head Office advanced training.
• Training Materials: Continuously updated based on feedback.

18. Go-Live Readiness Assessment & Approval

Purpose: Confirms that business, ICT, security, testing and operational requirements have been addressed before production deployment.

18.1 Go-Live Overview

The go-live process for SCM-NUMS will follow a structured approach. A comprehensive readiness assessment will be conducted to verify that all requirements are met before deployment. Go-live is scheduled for mid-October 2026.

18.2 Go-Live Readiness Checklist

18.3 Go-Live Approval (Pending)

18. Go-Live Readiness Assessment & Approval (Continued)

18.4 Go-Live Deployment Plan (Draft)

18.5 Go-Live Communication

• User Communication: All users will be notified of go-live date and time.
• Training Reminder: Users will be reminded of training materials available.
• Support Information: Helpdesk contact details will be shared with all users.
• System Access: Users will be provided with access credentials.
• Feedback Channels: Users will be encouraged to provide feedback.

18.6 Post-Go-Live Support

• Helpdesk: Extended hours for first 2 weeks.
• On-Site Support: Support teams available at pilot facilities.
• Issue Escalation: Clear escalation path defined.
• Performance Monitoring: System performance monitored continuously.
• User Feedback: Regular user feedback collection.
• Support Responsibility: Mr Themba Sikosana and the SCM Team.

18.7 Go-Live Sign-Off (Pending)

19. Post-Implementation Review

Purpose: Assesses whether the system achieved its objectives and identifies outstanding issues, risks and improvements.

19.1 Post-Implementation Overview

The PIR will be conducted after go-live to evaluate whether the SCM-NUMS system has achieved its intended objectives and to identify any outstanding issues, risks, or improvement opportunities.

19.2 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.
• ⏳ Training to be delivered to all 32,000+ users.
• ⏳ System availability to be measured post go-live.

19.3 Performance Metrics (Targets)

19. Post-Implementation Review (Continued)

19.4 Lessons Learned (Preliminary)

• Early Stakeholder Engagement: Improved requirements gathering.
• Phased Rollout: Pilot phase identifies issues before province-wide deployment.
• Training is Critical: Comprehensive training is key to user adoption.
• Communication: Regular updates keep stakeholders informed.
• Testing: Thorough testing prevents major issues in production.
• User Feedback: Active feedback helps refine the system.

19.5 Outstanding Issues (Preliminary)

19.6 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.
• Integration: Explore further integrations with other departmental systems.
• Expansion: Consider expanding the system to other provinces.

19.7 Conclusion (Preliminary)

Audit Evidence Summary

The following audit evidence has been compiled and is available for review by Internal Audit and external assurance providers, in line with the KZN Department of Health ICT Governance and System Assurance Standards.