Incident Response Plan

Purpose and Scope

This Incident Response Plan is maintained in accordance with the HIPAA Security Rule, 45 CFR §164.308(a)(6), which requires covered entities and business associates to implement policies and procedures to address security incidents, and with the HIPAA Breach Notification Rule, 45 CFR §164.400–414, which governs the notification requirements following the discovery of a breach of unsecured protected health information (PHI).

This plan applies to all security incidents that affect or may affect electronic PHI (ePHI) stored, processed, or transmitted by Ax Hill Tecnologia da Informação LTDA under the Klinity platform. It also applies to incidents affecting the underlying AWS infrastructure operated on behalf of Klinity.

Definition of a security incident: for the purposes of this plan, a security incident is any attempted or successful unauthorized access, use, disclosure, modification, or destruction of ePHI, or interference with system operations.

Incident Classification

Incidents are classified into two categories:

• Confirmed breach: unauthorized acquisition, access, use, or disclosure of unsecured ePHI that compromises its security or privacy, unless a specific HIPAA exception applies (45 CFR §164.402).
• Security event (non-breach): a security incident that does not result in unauthorized access to ePHI, or where the probability of compromise is low after risk assessment. Examples include a failed login attempt, a detected intrusion attempt that was blocked, or a misconfiguration with no data exposure.

All security events are documented and investigated. Only confirmed breaches trigger the notification obligations described in this plan.

Response Protocol

Step 1 — Identification

Security incidents may be identified through:

• Automated monitoring alerts from AWS CloudTrail or application logs
• Anomalies detected in audit log patterns
• Reports from affected users or third parties
• Vulnerability disclosures submitted to security@klinity.com

Upon identification, the incident is logged with the date, time, source of discovery, and initial description. A preliminary classification (breach or non-breach) is made.

Step 2 — Containment

Containment begins immediately upon identification:

• Compromised user accounts are suspended via the banned_at mechanism, which blocks all access at the authentication middleware level without requiring token revocation.
• If infrastructure credentials are believed to be compromised, they are rotated immediately in AWS Secrets Manager and IAM.
• Affected systems are isolated at the network level if necessary (e.g., security group modifications in the AWS VPC).
• All containment actions are documented in real time with timestamps.

Step 3 — Impact Assessment

Following containment, a full impact assessment is conducted to determine:

• Which ePHI was accessed, used, or disclosed without authorization
• The number of individuals whose ePHI was involved
• Whether the incident qualifies as a breach under 45 CFR §164.402, applying the four-factor risk assessment (nature and extent of ePHI involved; the unauthorized person who used the ePHI; whether ePHI was actually acquired or viewed; the extent to which the risk has been mitigated)
• The root cause and timeline of the incident

The assessment is documented in writing. If the incident is classified as a confirmed breach, Step 4 is initiated.

Step 4 — Notification

For confirmed breaches, notification follows the timelines and requirements below:

• Affected individuals: notified within 60 calendar days of the date of discovery of the breach (45 CFR §164.404). Notification is sent via email (the primary contact on file) and, where applicable, by written notice. The notification includes:
  • A description of what happened, including the date of breach and discovery
  • The types of ePHI involved
  • Steps individuals should take to protect themselves
  • A description of what Klinity is doing to investigate and mitigate the breach
  • Contact information for Klinity's security team
• Brazilian data protection authority (ANPD): notified as required by LGPD Art. 48 within a reasonable timeframe, not to exceed the 72-hour window recommended by the ANPD for high-risk incidents.
• Business associates: AWS and AssemblyAI are notified per the terms of their respective Business Associate Agreements (BAAs) if the incident involves their systems or data processed by them.

Step 5 — Remediation

After the incident is contained and notifications are sent:

• Root causes are identified and technical fixes are implemented and deployed.
• The effectiveness of existing controls is re-evaluated in light of the incident, and the Risk Assessment is updated accordingly.
• Additional preventive controls are implemented where gaps are identified.

Step 6 — Documentation

A complete written record of the incident is maintained, including:

• Date and time of discovery and containment
• Full description of the incident and root cause
• Scope of ePHI involved and individuals affected
• All notifications sent, their dates, and recipients
• Remediation actions taken and their dates
• Lessons learned and policy updates resulting from the incident

Incident documentation is retained for a minimum of six years from the date of creation or last effective date (45 CFR §164.414(b)).

Reporting a Security Concern

To report a suspected vulnerability, security incident, or potential breach, contact the Klinity security team at security@klinity.com. Reports are acknowledged within 24 hours during business days.

Practitioners who believe their account may have been compromised should also change their password immediately via the Klinity login page and contact the security team.

Plan Review

This plan is reviewed at least annually and updated immediately following any confirmed security incident or material change to the platform's architecture, infrastructure, or applicable regulations.