INCIDENT RESPONSE
Incident response at MedTalk
A structured approach to identifying, responding to, and recovering from security incidents.
Purpose
This policy establishes a structured and coordinated approach for identifying, responding to, managing, and recovering from information security and privacy incidents affecting MedTalk AI systems, services, and information assets.
- Protect the confidentiality, integrity and availability of MedTalk AI systems and data
- Safeguard patient, customer and organisational information
- Minimise operational disruption and business impact
- Meet legal, regulatory and contractual obligations, including under the Australian Privacy Act and the Notifiable Data Breaches (NDB) scheme
- Enable continuous improvement of MedTalk AI's security posture
Scope
Systems and environments
- Cloud infrastructure and SaaS platforms
- Corporate networks and infrastructure
- Endpoints and mobile devices
- Applications and development environments
- Third-party hosted services
- Data storage environments
Information assets
- Personal and sensitive information
- Healthcare data
- Customer data
- Corporate confidential information
- Credentials and authentication systems
- Intellectual property
Governance and regulatory alignment
MedTalk AI executive leadership maintains oversight of the organisation's incident response capability. The Chief Information Security Officer (CISO) oversees the incident response framework, escalates significant incidents to executives, and reports material incidents to leadership and governance forums; significant incidents may also be reported to the Executive Leadership Team, risk or security governance committees, and board or advisory stakeholders where required.
The incident response capability supports compliance with the Australian Privacy Act 1988, the Notifiable Data Breaches (NDB) Scheme, the ACSC Essential Eight, ISO/IEC 27001 Information Security Management, and relevant healthcare data protection obligations. Where MedTalk AI services operate across jurisdictions, additional regulatory requirements may also apply.
Definition of a security incident
A security incident is any event that compromises or threatens the confidentiality, integrity or availability of systems or information, or that violates organisational security policies, standards or acceptable use requirements. Not all events constitute incidents; events are assessed through the incident management process. Examples include:
- Unauthorised access to systems or data
- Credential compromise
- Phishing or business email compromise
- Malware or ransomware infection
- Data loss or unauthorised disclosure
- Misconfigured systems exposing sensitive information
- Insider misuse of systems
- Third-party security breaches affecting MedTalk AI data
- Denial-of-service attacks or system outages caused by malicious activity
Incident severity classification
| Severity | Example triggers | Response target |
|---|---|---|
| Critical (Severity 1) | Confirmed breach of sensitive or personal information, ransomware affecting core services, widespread service disruption, active compromise of production systems | Acknowledged within 15 minutes; response mobilised within 1 hour |
| High (Severity 2) | Potential exposure of sensitive information, targeted malware, significant service degradation, exploited high-risk vulnerabilities | Acknowledged within 30 minutes; response initiated within 4 hours |
| Medium (Severity 3) | Suspicious activity with limited impact, localised malware infections, policy violations with potential risk | Response initiated within one business day |
| Low (Severity 4) | Minor policy breaches, false positives, informational alerts requiring monitoring only | Monitored; no active response required |
Incident response lifecycle
- Preparation: documented response procedures, incident response roles and contact lists, monitoring and detection tools, security telemetry, secure coordination channels, awareness training and periodic response exercises.
- Identification: potential incidents are identified through security monitoring, automated alerts, user reports, vendor notifications, or external threat intelligence, then validated, assessed for severity and impact, and recorded.
- Containment: isolating affected systems, disabling compromised accounts, blocking malicious network activity, and restricting access, prioritising minimising further damage while preserving evidence.
- Eradication: removing malware or malicious code, patching vulnerabilities, resetting compromised credentials, and removing unauthorised access mechanisms.
- Recovery: restoring systems from trusted backups, reintroducing systems to the network, verifying system integrity, and implementing additional monitoring before returning systems to production.
- Post-Incident Review:for significant incidents, a documented review of the timeline, root cause, response effectiveness, control gaps and required remediation, tracked through MedTalk's risk management process.
Roles and responsibilities
- Incident Commander: leads response activities, declares incident severity, coordinates response teams, approves containment and recovery actions, and provides executive updates.
- Security Operations: monitors and detects incidents, performs technical investigation and triage, coordinates containment, and maintains incident documentation.
- Privacy Officer: assesses whether personal information has been compromised, conducts breach assessments under the NDB scheme, and coordinates regulatory notifications where required.
- Legal and Compliance: provides legal advice, reviews regulatory obligations, and supports external communications and disclosures.
- IT Operations and Engineering: implements technical containment and recovery actions, system restoration and patching.
- Communications and Customer Teams: manage authorised internal and external communications, including customer notifications where required.
Reporting and breach notification
All personnel must report suspected incidents immediately through MedTalk's monitored security contact, published at /.well-known/security.txt, or via internal service desk and security operations channels. Reports should include a description of the event, affected systems, when the activity was observed, and any available evidence. Personnel must not attempt to investigate or remediate incidents independently unless authorised.
Where an incident involves potential compromise of personal information, MedTalk AI conducts a breach assessment under the Notifiable Data Breaches (NDB) scheme. If an eligible data breach is confirmed, MedTalk AI may be required to notify the Office of the Australian Information Commissioner (OAIC) and affected individuals, as soon as practicable after the breach is identified and assessed.
Third-party incidents, documentation and review
Where incidents originate from or affect third-party providers, the vendor must notify MedTalk AI promptly; MedTalk AI assesses the impact on its systems and data and may require investigation reports and remediation plans. Vendor incidents involving MedTalk AI data may trigger internal response processes and regulatory obligations.
All incidents are documented in a designated incident management system, including the timeline, evidence and investigation findings, response actions, impact assessment, and post-incident review outcomes, retained in accordance with MedTalk AI's information governance and regulatory obligations.
MedTalk AI maintains incident response readiness through annual incident response exercises, security awareness training for all personnel, and role-specific training for response teams. This policy is reviewed annually, following any major security incident, or after significant changes to systems or regulatory obligations.
Contact
Security & Compliance: support@medtalk.co
Legal / compliance: legal@medtalk.co