> For the complete documentation index, see [llms.txt](https://incident-tracker.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://incident-tracker.gitbook.io/docs/support/security/phi-security-overview.md). # PHI Security Overview Protected Health Information Safeguards for Incident Tracker {% hint style="warning" %} This document is intended for compliance officers, IT administrators, and procurement teams evaluating Incident Tracker for use in healthcare or PHI-handling environments. For questions or to request a Business Associate Agreement (BAA), contact . {% endhint %} *** ### 1. Data Storage & Encryption Incident Tracker stores all data — including any PHI entered into incident reports, attachments, or user records — in a cloud-hosted environment with layered encryption controls. **Encryption at Rest** All database records and file attachments are encrypted at rest using AES-256. Encryption keys are managed through a dedicated key management service with regular rotation schedules. **Encryption in Transit** All data transmitted between end-user devices and Incident Tracker servers is encrypted using TLS 1.2 or higher. Unencrypted HTTP connections are rejected. **Cloud Infrastructure** Incident Tracker is hosted on Azure SOC 2 Type II-certified cloud infrastructure. Physical data centers employ multi-layer physical security controls including biometric access, 24/7 surveillance, and redundant power systems. **File Attachments** Attachments uploaded to incident reports (including images, documents, or media that may contain PHI) are stored in encrypted object storage, isolated per tenant, and accessible only to authenticated users with appropriate report-level permissions. **Database Isolation** Each customer's data is logically isolated within the platform. Cross-tenant data access is architecturally prevented. *** ### 2. Access Controls & Role-Based Permissions Access to PHI within Incident Tracker is governed by a layered permission model that enforces the minimum-necessary standard required under HIPAA. **Role-Based Access Control (RBAC)** Incident Tracker provides configurable user roles at the site level. Permissions can be scoped to: * Viewing, editing, or submitting incident reports * Accessing specific report categories or location-based data * Viewing or managing attachments and private notes * Administrative functions including user management and system configuration **Authentication** Incident Tracker supports multiple authentication methods to align with your organization's identity governance: * Standalone credential-based login (email + password) * Microsoft SSO via Azure Entra ID (SAML / OAuth 2.0) * Google SSO * SCIM-based automated provisioning and deprovisioning through Azure Entra ID **SCIM Provisioning** Organizations using Microsoft Entra ID can automate user lifecycle management via SCIM 2.0. When a user is deprovisioned in Entra ID, their Incident Tracker access is automatically revoked, reducing the risk of orphaned accounts retaining access to PHI. **Private Notes** Incident reports may include Private Notes — a restricted field visible only to users with explicit permission. This feature supports use cases where sensitive clinical or PHI-adjacent details must be captured but restricted from general staff view. **Session Management** * Sessions are token-based and expire after a configurable period of inactivity * Mobile app sessions are tied to device-level authentication and support SSO-enforced re-authentication * Administrators can revoke active sessions via the Admin console *** ### 3. HIPAA Compliance Posture Incident Tracker is designed to support HIPAA-compliant workflows for covered entities and business associates operating in healthcare and related industries. The following summarizes our alignment with the HIPAA Security Rule. | Safeguard Category | Requirement | Incident Tracker Approach | | ------------------ | ----------------------------- | ---------------------------------------------------------------------------------------- | | Administrative | Risk Analysis & Management | Ongoing internal risk assessments; documented policies for PHI handling | | Administrative | Workforce Training | Staff training on PHI handling and security policies | | Administrative | Access Management | RBAC with least-privilege defaults; SCIM auto-deprovisioning | | Technical | Access Control | Unique user IDs; SSO and MFA supported; role-scoped data access | | Technical | Audit Controls | Activity logs capture report access, edits, exports, and admin actions | | Technical | Transmission Security | TLS 1.2+ enforced for all data in transit | | Technical | Encryption at Rest | AES-256 encryption for all stored data and attachments | | Physical | Facility Access Controls | Hosted on Azure SOC 2 Type II-certified infrastructure with physical access restrictions | | Physical | Workstation & Device Controls | Mobile app supports SSO; platform accessible only via authenticated sessions | *** ### 4. Data Retention & Deletion Incident Tracker's data retention and deletion capabilities are designed to support both operational needs and compliance obligations. **Configurable Retention Periods** Administrators can configure data retention policies appropriate to their regulatory environment. Incident records, attachments, and user data are retained for the duration specified by the organization. **Data Deletion on Request** Organizations may request deletion of their data at any time. Upon contract termination, customer data is deleted from production systems within **30 days**. Deletion from backup systems follows the backup rotation schedule, with a maximum retention period of **7 years** across the following tiers: * Daily backups: retained for 7 days * Weekly backups: retained for 5 weeks * Monthly backups: retained for 12 months * Yearly backups: retained for 7 years **Deletion & Recovery** Incident Tracker handles deletion differently depending on the type of data involved: * **Incident reports:** When a report is deleted, a snapshot of its contents is captured in the admin event log. If a report is removed in error, an administrator can reference this record and manually re-enter the report data. * **File attachments:** Attached files are not directly recoverable through the application after deletion. Recovery of attachments requires a formal backup restoration through Incident Tracker support. **Attachment Lifecycle** File attachments are subject to the same retention and deletion controls as the incident records they are associated with. Orphaned attachments are periodically purged. **Backup Encryption** All backups are encrypted using the same AES-256 standard applied to production data. Backups are retained for a rolling period and are inaccessible to external parties. *** ### 5. Business Associate Agreement (BAA) As a vendor that may process, store, or transmit PHI on behalf of covered entities, Incident Tracker is prepared to execute a Business Associate Agreement (BAA) in compliance with 45 CFR § 164.308(b) and related provisions of the HIPAA Rules. **BAA Availability** A standard BAA is available to all customers whose use of Incident Tracker involves PHI. Custom BAA terms may be reviewed on a case-by-case basis for enterprise agreements. **Scope of Agreement** The BAA covers Incident Tracker's role as a business associate with respect to PHI entered into or processed through the platform. It addresses permitted uses and disclosures, safeguard obligations, breach notification responsibilities, and subcontractor requirements. **Subcontractors** Incident Tracker maintains BAAs with its cloud infrastructure and key subservice providers that may have access to PHI. A list of subprocessors is available upon request. **How to Request** To request a BAA or inquire about existing agreements, contact . *** ### 6. Incident Response & Breach Notification Incident Tracker maintains a formal incident response program aligned with HIPAA breach notification requirements under 45 CFR §§ 164.400–414. **Breach Detection** Security monitoring tools and alerting systems are in place to detect anomalous access patterns, unauthorized data access, and potential security incidents in near real time. **Internal Response Process** Upon detection of a potential PHI breach, our security team initiates a documented incident response workflow including containment, investigation, risk assessment, and remediation steps. **Customer Notification** In the event of a confirmed breach involving customer PHI, Incident Tracker will notify affected customers without unreasonable delay and within the timeframe required by HIPAA (no later than 60 days following discovery of the breach). **Notification Contents** Breach notifications will include the nature of the PHI involved, the individuals affected, a description of what occurred, steps taken to mitigate harm, and recommended actions for the covered entity. **Regulatory Reporting** Incident Tracker will cooperate with covered entities in meeting their obligations to notify HHS and, where required, affected individuals and media outlets. *** ### 7. Audit Logging & Monitoring Incident Tracker maintains comprehensive audit logs to support accountability, forensic investigation, and compliance reporting requirements. **Events Captured in Audit Logs** * User login and logout events (including failed login attempts) * Report creation, viewing, editing, and deletion * Attachment uploads, downloads, and deletions * Private note access * Administrative actions (user management, settings changes, role modifications) * SCIM provisioning and deprovisioning events * SSO authentication events * Data export actions **Log Integrity & Retention** Audit logs are write-protected and cannot be modified or deleted by end users or administrators within the platform. Logs are retained for a minimum of **6 years** in accordance with HIPAA requirements and are available for review upon request or during compliance audits. **Access to Logs** Administrators can access activity logs within the Admin console for operational review. Full audit log exports for compliance or forensic purposes are available to authorized personnel upon request. *** ### 8. Summary of Safeguards | Control Area | Measure | Status | | ---------------------------- | -------------------------------------------------- | ----------- | | Encryption at Rest | AES-256 for all data and attachments | ✓ In Place | | Encryption in Transit | TLS 1.2+ enforced; HTTP rejected | ✓ In Place | | Access Control | RBAC with least-privilege defaults | ✓ In Place | | Authentication | SSO (Microsoft/Google), standalone login | ✓ In Place | | MFA Support | Supported via SSO provider (e.g., Azure MFA) | ✓ Via SSO | | SCIM Provisioning | Automated user lifecycle via Entra ID | ✓ In Place | | Audit Logging | Comprehensive, tamper-resistant activity logs | ✓ In Place | | Data Isolation | Logical per-tenant data separation | ✓ In Place | | Backup Encryption | AES-256 encrypted, rolling retention | ✓ In Place | | BAA Availability | Standard BAA available upon request | ✓ Available | | Breach Notification | Notification within HIPAA-required timeframes | ✓ In Place | | Infrastructure Certification | Azure SOC 2 Type II-certified cloud infrastructure | ✓ In Place | *** For additional information or to send a BAA for review, contact .