1. Objectives

The objectives of the assessment are to:
Assess the security posture of the AI Scribe solution across the front-end plugin, back-end services, APIs, data flows, storage components, admin functions, and approved deployment evidence, with direct environment testing limited to agreed non-production access.
Verify whether appropriate controls are in place to protect sensitive patient data, including audio, transcripts, consent records, original AI-generated notes, and clinician-edited notes.
Evaluate authentication, authorization, session/context inheritance from the host system, and access boundaries between the AI Scribe and existing clinical systems.
Assess the adequacy of audit logging, traceability, monitoring, retention, and incident-readiness arrangements.
Identify vulnerabilities and exploitable weaknesses through structured security testing, including vulnerability assessment and penetration testing, and recommend remediation actions ranked by severity and implementation priority.

2. Scope of work

The external assessor will perform an application-led security assessment covering, at minimum, the following areas. Direct testing of PHDC infrastructure, internal networks, or production systems is excluded unless explicitly approved in writing; where access is limited, the assessor should review available architecture, configuration evidence, and technical walkthroughs.

2.1 Application Security
Assessment of the AI Scribe application components, including:
● The embedded front-end plugin/web component used inside the host clinical application
● Front-end to back-end communications
● Back-end APIs and service endpoints
● Admin console functionality
● Note generation, editing, confirmation, and submission workflows
● Error handling and user-facing failure modes that may affect confidentiality, integrity, or availability.

2.2 API and Integration Security
Review and testing of:
● API authentication and authorization mechanisms
● Trust relationship with the host system security context
● Exposure of endpoints used for recording, consent events, transcripts, summaries, edited SOAP notes, metadata, admin operations, and service health
● Secure transport and resilience of front-end/back-end integration
● Risks arising from integration into existing EMR or departmental systems.

2.3 Data Protection and Privacy Controls
Assessment of controls protecting:
● Consultation audio recordings
● Consent recordings and consent status records
● Raw transcripts
● Original AI-generated SOAP notes
● Clinician-edited SOAP notes
● Metadata and logs associated with the consultation and note lifecycle.
This should include review of:
● Encryption in transit and at rest
● Access controls and least privilege
● Segregation of duties
● Data minimization
● Data retention and deletion arrangements
● Security of stored artefacts and archives.

2.4 Infrastructure and Environment Security
Evidence-based review of the infrastructure and environment controls supporting the AI Scribe services, including as applicable and subject to available access:
● Network exposure and segmentation
● Server and container hardening
● Configuration of runtime services
● Secrets and key management
● Patch and dependency management
● Logging, monitoring, and alerting
● Scalability and resilience considerations that have security impact
● Disaster recovery and operational recovery readiness.

2.5 Administrative and Operational Security
Assessment of:
● Admin console access and role-based control
● Security of model configuration features
● Access to recording artefacts, transcripts, and metadata
● Monitoring and patient consent statistics views
● Service health features and any privileged administrative operations.

2.6 Auditability and Non-Repudiation
Review whether the solution adequately maintains auditable records of:
● Patient consent events
● Note generation events
● Clinician review and editing
● Version history between original and edited content
● Access to sensitive artefacts
● Administrative changes.

3. Methodology

The assessor is expected to apply an industry-standard methodology combining document review, technical verification, and controlled security testing. The methodology should include:
● Review of relevant architecture, technical specifications, API/interface documentation, and deployment/configuration artefacts
● Interviews or walkthrough sessions with the implementation team
● Threat-informed review of the end-to-end data flow
● Configuration and hardening review based on available environment evidence, approved test access, and implementation-team walkthroughs
● Static and/or dynamic assessment of in-scope application and API interfaces in approved test/staging environments
● Vulnerability assessment
● Penetration testing of agreed in-scope application, API, and admin components, excluding PHDC production infrastructure or internal network testing unless separately authorized
● Validation of remediation options for high and critical findings.
Testing must be carefully coordinated to avoid disruption to operational systems and must be performed only against approved environments. The final report should explicitly state any access limitations, assumptions, and residual risks arising from components that could only be reviewed through documentation or walkthroughs.

4. Required Expertise of the Service Provider

The service provider should demonstrate:
● Proven experience in independent application security assessments and penetration testing
● Experience assessing web applications, APIs, and integrated enterprise systems
● Experience with healthcare, public sector, or other sensitive-data environments
● Strong understanding of privacy and information-security controls relevant to sensitive personal information
● Ability to communicate findings clearly to both technical and non-technical stakeholders
● Independence from the implementation team.

5. Responsibilities

5.1 Client / Project Team Responsibilities
The project team will:
● Provide relevant documents, architecture material, and technical walkthroughs
● Provide access to approved test/staging environments and clarify any PHDC infrastructure or network areas that are out of scope or only available for evidence review
● Provide nominated technical contacts for coordination
● Support clarification of expected workflows and data flows
● Review and respond to draft findings.

5.2 Service Provider Responsibilities
The service provider will:
● Conduct the assessment professionally and independently
● Protect all information accessed during the assignment
● Limit testing to the approved scope and environment, and avoid active testing of PHDC production infrastructure or internal networks unless separately authorized
● Promptly notify the client of any critical findings requiring urgent action
● Deliver all outputs within the agreed timelines.

6. Confidentiality and Information Handling

The assessor will be required to sign appropriate confidentiality and non-disclosure undertakings. All information accessed during the assessment, including architecture details, screenshots, logs, sample data, and vulnerability findings, must be treated as strictly confidential and must not be disclosed to any third party without written authorization.

7. Indicative Timeline

The engagement should be planned so that findings can be used to implement priority hardening actions before final production release. This aligns with the project delivery plan, where the external security assessment is scheduled before final production hardening and go-live.
A practical sequence would be:
● Week 1: kickoff, document review, access setup
● Week 2: technical assessment and testing
● Week 3: reporting and readout
● Week 4: remediation verification, if required

8. Deliverables

The service provider should deliver:
● An agreed assessment plan and confirmed scope
● A technical findings report with severity ratings, evidence, affected components, and prioritized remediation recommendations
● A summary of residual risks and limitations, including areas not directly tested because of limited PHDC infrastructure or network access
● A readout session for technical and project stakeholders
● A remediation verification note or retest report, if required.

8.1 Selection Criteria
Proposals may be evaluated against:
● Relevant experience
● Understanding of the assignment
● Quality of proposed methodology
● Strength of the proposed team
● Ability to work within the required timeframe
● Cost and value for money.

8.2 Proposal Required Documentation
● Introduction to company’s precious relevant work (1 page with reference)
● Scope of Work (Narrative 1 page) in relation to the call for proposals
● Costing and Timeline (1-2 pages) as below, for each activity:
○ Scope of Work
○ Duration and Due Date
○ Costing
● CV Including qualifications of the relevant staff members
● Rate Justification of each staff member (sent upon request)
Eligibility Requirements for Companies (contract):
● Based in South Africa preferred

Companies required to submit the following Documents
● CV including qualifications of relevant staff members
● Rate Justification Form for each staff member (sent upon request) if using day rates in ZAR
● If following CDC budget guidelines, please ensure to follow the CDC rules for budgeting by following link below:
● Company Registration certificate
● Tax Clearance Certificate
● Introduction to company’s previous relevant work – references/capability statement
Eligibility Requirements for individuals (consultancy):
● Based in South Africa preferred
Individuals required to submit the following Documents
● CV with relevant qualifications
● Rate justification form
● Tax Clearance Certification
● Bank data of the consultant
● Proof of address
● ID or Passport of the consultant
● Confirmation of any external or competing interests
● Introduction to consultant’s previous relevant work (references/capability statement)
● Scope of Work (Narrative one page) in relation to the call for proposals
● Costing and Timeline (1-2 pages) as per the table below