diff --git a/3rd_party_policy.md b/3rd_party_policy.md index 2319944..49d21b1 100644 --- a/3rd_party_policy.md +++ b/3rd_party_policy.md @@ -27,10 +27,16 @@ BloomAPI makes every effort to assure all 3rd party organizations are compliant 4. A standard business associate agreement with Customers and Partners is defined and includes the required security controls in accordance with the organization's security policies. Additionally, responsibility is assigned in these agreements. 5. BloomAPI has Service Level Agreements (SLAs) with Subcontractors with an agreed service arrangement addressing liability, service definitions, security controls, and aspects of services management. * BloomAPI utilizes monitoring tools to regularly evaluate Subcontractors against relevant SLAs. +6. Subcontractors that create, receive, maintain, or transmit PHI or Part 2 records for BloomAPI must enter into written agreements requiring restrictions, conditions, and safeguards at least as protective as those applicable to BloomAPI. These agreements must include breach reporting obligations, return or destruction obligations, and restrictions on redisclosure. 7. Third parties are unable to make changes to any BloomAPI infrastructure without explicit permission from BloomAPI. Additionally, no BloomAPI Customers or Partners have access outside of their own environment, meaning they cannot access, modify, or delete anything related to other 3rd parties. 8. Whenever outsourced development is utilized by BloomAPI, all changes to production systems will be approved and implemented by BloomAPI workforce members only. All outsourced development requires a formal contract with BloomAPI. -9. BloomAPI maintains and annually reviews a list all current Partners and Subcontractors. -10. BloomAPI assesses security requirements and compliance considerations with all Partners and Subcontracts. +9. BloomAPI maintains and annually reviews a list of all current Partners and Subcontractors. +10. BloomAPI assesses security requirements and compliance considerations with all Partners and Subcontractors. 11. Regular review is conducted as required by SLAs to assure security and compliance. These reviews include reports, audit trails, security events, operational issues, failures and disruptions, and identified issues are investigated and resolved in a reasonable and timely manner. -13. Any changes to Partner and Subcontractor services and systems are reviewed before implementation. -14. For all partners, BloomAPI reviews activity annually to assure partners are in line with SLAs in contracts with BloomAPI. +12. Any changes to Partner and Subcontractor services and systems are reviewed before implementation. +13. For all partners, BloomAPI reviews activity annually to assure partners are in line with SLAs in contracts with BloomAPI. +14. BloomAPI maintains an inventory of third-party services that may create, receive, maintain, or transmit PHI or Part 2 records, including the service purpose, type of data involved, agreement status, and review date. +15. New subprocessors must be reviewed for PHI and Part 2 exposure, agreement status, data categories, retention, breach notice commitments, and security controls before use with regulated Customer data. +16. Tools or subprocessors that are not authorized for PHI or Part 2 records may not receive PHI, Part 2 records, patient identifiers, message bodies, patient names, clinical content, or other regulated Customer data. + +Current subprocessors and related service review status are maintained in [Subprocessors](subprocessors.md). diff --git a/README.md b/README.md index dfada7e..7a3fe98 100644 --- a/README.md +++ b/README.md @@ -1,13 +1,13 @@ # HIPAA Compliance Policies Our policies have been written with modern, cloud-based technology vendors in mind. We looked far and wide for policy -examples that fit our company, and couldn't find any. So we wrote our own. Importantly, these policies have been through -three external audits--two HIPAA audits, and one HITRUST audit. +examples that fit our company, and couldn't find any. So we wrote our own. These policies are internally maintained and +reviewed at least annually by our Security Officer and Privacy Officer. ## Policy Index * [Introduction](introduction.md) -* [HIPAA Inheritance for BloomText Customers](hipaa_inheritance.md) +* [BloomText Shared Responsibility Matrix](shared_responsibility_matrix.md) * [Policy Management Policy](policy_management_policy.md) * [Risk Management Policy](risk_management_policy.md) * [Roles Policy](roles_policy.md) @@ -18,6 +18,7 @@ three external audits--two HIPAA audits, and one HITRUST audit. * [Facility Access Policy](facility_access_policy.md) * [Incident Response Policy](incident_response_policy.md) * [Breach Policy](breach_policy.md) +* [Part 2 SUD Records Policy](part_2_sud_records_policy.md) * [Disaster Recover Policy](disaster_recovery_policy.md) * [Disposable Media Policy](disposable_media_policy.md) * [IDS Policy](ids_policy.md) @@ -27,6 +28,7 @@ three external audits--two HIPAA audits, and one HITRUST audit. * [Employees Policy](employees_policy.md) * [Approved Tools Policy](approved_tools_policy.md) * [3rd Party Policy](3rd_party_policy.md) +* [Subprocessors](subprocessors.md) * [Key Definitions](key_definitions.md) * [BloomAPI HIPAA Business Associate Agreement ("BAA")](bloomapi_hipaa_business_associate_agreement.md) * [HIPAA Mappings to BloomAPI Controls](hipaa_mapping_to_bloomapi_controls.md) diff --git a/approved_tools_policy.md b/approved_tools_policy.md index 3deba60..43aa980 100644 --- a/approved_tools_policy.md +++ b/approved_tools_policy.md @@ -1,3 +1,7 @@ # Approved Tools Policy -BloomAPI utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by BloomAPI, or they are hosted by a Subcontractor with appropriate business associate agreements in place to preserve data integrity. Use of other tools requires approval from BloomAPI leadership. +BloomAPI utilizes a suite of approved software tools for internal use by workforce members. These software tools are either self-hosted, with security managed by BloomAPI, or they are hosted by a Subcontractor with appropriate business associate agreements and, where applicable, Part 2 or qualified service organization terms in place to preserve data integrity and confidentiality. Use of other tools requires approval from BloomAPI leadership. + +Workforce members may not enter PHI, ePHI, Part 2 records, Customer credentials, incident details containing identifiers, or other regulated Customer data into unapproved tools, including generative AI tools, ticketing systems, messaging systems, analytics tools, debugging services, or file sharing services. Emergency use of an unapproved tool requires documented approval by the Security Officer or Privacy Officer and must be reviewed after the emergency. + +Workforce members must access systems containing PHI, ePHI, or Part 2 records using a BloomAPI-managed browser (Google Workspace-managed Chrome signed in with a BloomAPI account), in which browser extensions are restricted by default to an administrator-approved allowlist. Installing or using browser extensions outside that allowlist on any profile used to access regulated Customer data is prohibited, and the same emergency-approval and post-review process described above applies to any exception. diff --git a/auditing_policy.md b/auditing_policy.md index c84b447..d3c9749 100644 --- a/auditing_policy.md +++ b/auditing_policy.md @@ -26,12 +26,12 @@ This policy applies to all BloomAPI Add-on systems, that store, transmit, or pro ## Applicable Standards from the HIPAA Security Rule -* 45 CFR ¬ß 164.308(a)(1)(ii)(D) - Information System Activity Review -* 45 CFR ¬ß 164.308(a)(5)(ii)(B) & (C) - Protection from Malicious Software & Log-in Monitoring -* 45 CFR ¬ß 164.308(a)(2) - HIPAA Security Rule Periodic Evaluation -* 45 CFR ¬ß 164.312(b) - Audit Controls -* 45 CFR ¬ß 164.312(c)(2) - Mechanism to Authenticate ePHI -* 45 CFR ¬ß 164.312(e)(2)(i) - Integrity Controls +* 45 CFR § 164.308(a)(1)(ii)(D) - Information System Activity Review +* 45 CFR § 164.308(a)(5)(ii)(B) & (C) - Protection from Malicious Software & Log-in Monitoring +* 45 CFR § 164.308(a)(2) - HIPAA Security Rule Periodic Evaluation +* 45 CFR § 164.312(b) - Audit Controls +* 45 CFR § 164.312(c)(2) - Mechanism to Authenticate ePHI +* 45 CFR § 164.312(e)(2)(i) - Integrity Controls # Auditing Policies @@ -45,7 +45,7 @@ This policy applies to all BloomAPI Add-on systems, that store, transmit, or pro * Application: Application level audit trails generally monitor and log all user activities, including data accessed and modified and specific actions. * System: System level audit trails generally monitor and log user activities, applications accessed, and other system defined specific actions. BloomAPI utilizes file system monitoring from OSSEC to assure the integrity of file system data. * Network: Network level audit trails generally monitor information on what is operating, penetrations, and vulnerabilities. -3. BloomAPI shall log all incoming and outgoing traffic to into and out of its environment. This includes all successful and failed attempts at data access and editing. Data associated with this data will include origin, destination, time, and other relevant details that are available to BloomAPI. +3. BloomAPI maintains logs from current audit and security event sources appropriate to the service. These logs may include HTTP/WAF traffic, system events, authentication and access events, monitoring alerts, error events, and incident investigation records depending on the system and configuration. 4. BloomAPI leverages process monitoring tools throughout its environment. 5. BloomAPI shall identify "trigger events" or criteria that raise awareness of questionable conditions of viewing of confidential information. The "events" may be applied to the entire BloomAPI Platform or may be specific to a Customer, partner, business associate, Platform Add-on or application (See Listing of Potential Trigger Events below). 6. BloomAPI's Security Officer and Privacy Officer are authorized to select and use auditing tools that are designed to detect network vulnerabilities and intrusions. Such tools are explicitly prohibited by others, including Customers and Partners, without the explicit authorization of the Security Officer. These tools may include, but are not limited to: @@ -89,9 +89,31 @@ This policy applies to all BloomAPI Add-on systems, that store, transmit, or pro ## Audit Log Security Controls and Backup -4. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy. -5. All audit logs are encrypted in transit and at rest to control access to the content of the logs. -6. Audit logs shall be stored on a separate system to minimize the impact auditing may have on the privacy system and to prevent access to audit trails by those with system administrator privileges. This is done to apply the security principle of "separation of duties" to protect audit trails from hackers. +1. Audit logs shall be protected from unauthorized access or modification, so the information they contain will be made available only if needed to evaluate a security incident or for routine audit activities as outlined in this policy. +2. Audit logs are encrypted in transit and at rest where supported by the logging system and hosting environment. +3. Audit logs should be stored or protected in a manner that limits the ability of production system administrators to alter audit evidence without detection. + +## Current Audit and Security Event Sources + +BloomAPI currently uses the following sources for audit, monitoring, and security event review: + +1. Google Cloud Armor HTTP and WAF logs for network and application-edge traffic visibility. +2. Server and machine logs for system activity, service behavior, and authentication events where available. +3. Customer account login and access events where available in application records. +4. Database records that track last activity for Customer accounts. +5. Grafana alerts for operational and security-relevant monitoring events. +6. Sentry alerts and error events for application diagnostics. +7. Incident tickets, investigation notes, and breach analysis records created during security or privacy investigations. + +## Recommended Audit Log Gaps and TODOs + +The following items must be verified before they are represented as completed audit controls: + +1. Confirm whether GCP Cloud Audit Logs are enabled and retained for IAM, administrative, and configuration changes. +2. Confirm whether BloomAPI stores explicit login history or only last-activity records. +3. Confirm whether support or administrator access to Customer accounts is logged separately. +4. Confirm whether failed login and MFA events are logged and retained. +5. Confirm whether production deploy and change logs are retained for audit review. ## Workforce Training, Education, Awareness and Responsibilities @@ -110,11 +132,10 @@ This policy applies to all BloomAPI Add-on systems, that store, transmit, or pro ## Retention of Audit Data -1. Audit logs shall be maintained based on organizational needs. There is no standard or law addressing the retention of audit log/trail information. Retention of this information shall be based on: -A. Organizational history and experience. -B. Available storage space. -1. Reports summarizing audit activities shall be retained for a period of six years. -3. Log data is currently retained and readily accessible for a 1-month period. Beyond that, log data is available via cold backup. +1. Raw operational log retention depends on the logging source, system configuration, storage limits, and security needs. BloomAPI verifies each current log source before representing a final retention period as a completed control. +2. Reports summarizing audit activities shall be retained for a period of six years. +3. Security incident records, breach investigation documentation, risk assessments, access review evidence, and policy records are retained according to the applicable policy and legal/compliance requirements. +4. Raw operational logs are distinct from legal and compliance records. A six-year documentation requirement does not mean every raw machine or application log is retained for six years. ## Potential Trigger Events diff --git a/baa_covered_entity.txt b/baa_covered_entity.txt index df2793e..bfb34ad 100644 --- a/baa_covered_entity.txt +++ b/baa_covered_entity.txt @@ -1,6 +1,6 @@ BUSINESS ASSOCIATE AGREEMENT -This Business Associate Agreement (this “Agreement”) by and between _______________ (“Covered Entity”) and BloomAPI, Inc. (“Business Associate”), is entered into on ____________, 201_ (“Effective Date”), for the purposes of complying with the Health Insurance Portability and Accountability Act of 1996 and regulations promulgated thereunder (“HIPAA”) and the security provisions of the American Recovery and Reinvestment Act of 2009, also known as the Health Information Technology for Economic and Clinical Health Act (the “HITECH Act”). +This Business Associate Agreement (this “Agreement”) by and between _______________ (“Covered Entity”) and BloomAPI, Inc. (“Business Associate”), is entered into on ____________, 20__ (“Effective Date”), for the purposes of complying with the Health Insurance Portability and Accountability Act of 1996 and regulations promulgated thereunder (“HIPAA”), the security provisions of the American Recovery and Reinvestment Act of 2009, also known as the Health Information Technology for Economic and Clinical Health Act (the “HITECH Act”), and, where applicable, the Confidentiality of Substance Use Disorder Patient Records regulations at 42 CFR Part 2 (“Part 2”). WITNESSETH @@ -20,6 +20,8 @@ I. DEFINITIONS. For the purposes of this Agreement, capitalized terms shall hav c. “Unsecured PHI” shall mean PHI that is not rendered unusable, unreadable, or indecipherable to unauthorized individuals through the use of a technology or methodology specified by the Secretary (e.g., encryption). This definition applies to both hard copy PHI and electronic PHI. + d. “Part 2 Records” shall mean records subject to 42 CFR Part 2 that are created, received, maintained, or transmitted by Business Associate for or on behalf of Covered Entity. + II. OBLIGATIONS OF BUSINESS ASSOCIATE. a. Use and Disclosure of PHI. @@ -41,6 +43,8 @@ II. OBLIGATIONS OF BUSINESS ASSOCIATE. vi. Business Associate acknowledges that, as between Business Associate and Covered Entity, all PHI shall be and remain the sole property of Covered Entity, including any and all forms thereof developed by Business Associate in the course of its fulfillment of its obligations pursuant to the Agreement and Service Agreement. vii. To the extent that Business Associate is to carry out any of Covered Entity’s obligations that are regulated by HIPAA, Business Associate shall comply with the HIPAA requirements that apply to the Covered Entity in the performance of such obligation. + + viii. To the extent Business Associate creates, receives, maintains, or transmits Part 2 Records for or on behalf of Covered Entity, Business Associate shall use and disclose such records only as permitted by this Agreement, the Service Agreement, Covered Entity's written instructions, and applicable law. Business Associate shall not use or disclose Part 2 Records in civil, criminal, administrative, or legislative proceedings against a patient unless authorized by a valid Part 2-compliant consent or court order. b. Safeguards. Business Associate shall employ appropriate administrative, technical and physical safeguards, consistent with the size and complexity of Business Associate’s operations, to protect the confidentiality of PHI and to prevent the use or disclosure of PHI in any manner inconsistent with the terms of this Agreement. Business Associate shall comply, where applicable, with Subpart C of 45 C.F.R. Part 164 with respect to electronic PHI to prevent use or disclosure of such electronic PHI other than as provided for by this Agreement. @@ -49,7 +53,7 @@ II. OBLIGATIONS OF BUSINESS ASSOCIATE. d. Individuals’ Rights to Their PHI. i. To the extent Business Associate maintains PHI in a Designated Record Set, in order to allow Covered Entity to respond to a request by an Individual for access to PHI pursuant to 45 CFR Section 164.524, Business Associate, within ten (10) business days upon receipt of written request by Covered Entity, shall make available to Covered Entity such PHI. - + 1. In the event that any Individual requests access to PHI directly from Business Associate, Business Associate shall forward such request to Covered Entity within five (5) business days. 2. Covered Entity will be responsible for making all determinations regarding the grant or denial of an Individual’s request for PHI and Business Associate will make no such determinations. Except as Required by Law, only Covered Entity will be responsible for releasing PHI to an Individual pursuant to such a request. Any denial of access to PHI determined by Covered Entity pursuant to 45 CFR Section 164.524, and conveyed to Business Associate by Covered Entity, shall be the responsibility of Covered Entity, including resolution or reporting of all appeals and/or complaints arising from denials. @@ -57,7 +61,7 @@ II. OBLIGATIONS OF BUSINESS ASSOCIATE. ii. To the extent Business Associate maintains PHI in a Designated Record Set, in order to allow Covered Entity to respond to a request by an Individual for an amendment to PHI, Business Associate shall, within ten (10) business days upon receipt of a written request by Covered Entity, make available to Covered Entity such PHI. 1. In the event that any Individual requests amendment of PHI directly from Business Associate, Business Associate shall forward such request to Covered Entity within five (5) business days. - + 2. Covered Entity will be responsible for making all determinations regarding the grant or denial of an Individual’s request for an amendment to PHI and Business Associate will make no such determinations. Any denial of amendment to PHI determined by Covered Entity pursuant to 45 CFR Section 164.526, and conveyed to Business Associate by Covered Entity, shall be the responsibility of Covered Entity, including resolution or reporting of all appeals and/or complaints arising from denials. 3. Within ten (10) business days of receipt of a request from Covered Entity to amend an individual’s PHI in the Designated Record Set, Business Associate shall incorporate any approved amendments, statements of disagreement, and/or rebuttals into its Designated Record Set as required by 45 CFR Section 164.526. @@ -70,15 +74,15 @@ II. OBLIGATIONS OF BUSINESS ASSOCIATE. 3. Business Associate shall implement an appropriate record keeping process to enable it to comply with the requirements of this Agreement. - e. Disclosure to Third Parties. Business Associate shall obtain and maintain a written agreement with each subcontractor or agent that has or will have access to PHI, which is received from, or created or received by, Business Associate for or on behalf of Covered Entity, pursuant to which agreement such subcontractor and agent agrees to be bound by the same restrictions, terms, and conditions that apply to Business Associate pursuant to the Agreement with respect to such PHI. + e. Disclosure to Third Parties. Business Associate shall obtain and maintain a written agreement with each subcontractor or agent that has or will have access to PHI, which is received from, or created or received by, Business Associate for or on behalf of Covered Entity, pursuant to which agreement such subcontractor and agent agrees to be bound by restrictions, terms, conditions, and safeguards at least as protective as those that apply to Business Associate pursuant to the Agreement with respect to such PHI. Where the subcontractor or agent will access Part 2 Records, the agreement must also require compliance with applicable Part 2 restrictions. f. Reporting Obligations. - i. In the event of a Breach of any Unsecured PHI that Business Associate accesses, maintains, retains, modifies, records, or otherwise holds or uses on behalf of Covered Entity, Business Associate shall report such Breach to Covered Entity as soon as practicable, but in no event later than ten (10) business days after the date the Breach is discovered. Notice of a Breach shall include, to the extent such information is available: (i) the identification of each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, or disclosed during the Breach; (ii) the date of the Breach, if known, and the date of discovery of the Breach; (iii) the scope of the Breach; and (iv) the Business Associate’s response to the Breach. - - ii. In the event of a use or disclosure of PHI that is improper under this Agreement but does not constitute a Breach, Business Associate shall report such use or disclosure to Covered Entity within ten (10) business days after the date on which Business Associate becomes aware of such use or disclosure. - - iii. In the event of any successful Security Incident, Business Associate shall report such Security Incident in writing to Covered Entity within ten (10) business days of the date on which Business Associate becomes aware of such Security Incident. The parties acknowledge that unsuccessful Security Incidents (e.g., pings) occur within the normal course of business and shall not be reported pursuant to this Agreement. + i. In the event of a Breach of any Unsecured PHI that Business Associate accesses, maintains, retains, modifies, records, or otherwise holds or uses on behalf of Covered Entity, Business Associate shall report such Breach to Covered Entity as soon as practicable, but in no event later than ten (10) business days after discovery. Notice of a Breach shall include, to the extent such information is available: (i) the identification of each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, or disclosed during the Breach; (ii) the date of the Breach, if known, and the date of discovery of the Breach; (iii) the scope of the Breach; and (iv) the Business Associate’s response to the Breach. Business Associate shall supplement the notice as additional information becomes available. + + ii. In the event of a use or disclosure of PHI that is improper under this Agreement but does not constitute a Breach, Business Associate shall report such use or disclosure to Covered Entity as soon as practicable, but in no event later than ten (10) business days after Business Associate becomes aware of such use or disclosure. + + iii. In the event of any successful Security Incident, Business Associate shall report such Security Incident in writing to Covered Entity as soon as practicable, but in no event later than ten (10) business days after Business Associate becomes aware of such Security Incident. The parties acknowledge that unsuccessful Security Incidents (e.g., pings) occur within the normal course of business and shall not be reported pursuant to this Agreement. III. OBLIGATIONS OF COVERED ENTITY. @@ -115,8 +119,10 @@ V. MISCELLANEOUS. b. Interpretation. Any ambiguity in this Agreement shall be resolved to permit the parties to comply with HIPAA and the HITECH Act. c. Conflicting Terms. In the event that any terms of this Agreement conflict with any terms of the Service Agreement, the terms of this Agreement shall govern and control. + + d. Existing Agreements. Existing signed agreements remain governed by their executed terms unless amended in writing by the parties. - d. Notices. Any notices pertaining to this Agreement shall be given in writing and shall be deemed duly given when personally delivered to a Party or a Party's authorized representative as listed below or sent by means of a reputable overnight carrier, or sent by means of certified mail, return receipt requested, postage prepaid. Notices shall be deemed given upon receipt. Notices shall be addressed to the appropriate Party as follows: + e. Notices. Any notices pertaining to this Agreement shall be given in writing and shall be deemed duly given when personally delivered to a Party or a Party's authorized representative as listed below or sent by means of a reputable overnight carrier, or sent by means of certified mail, return receipt requested, postage prepaid. Notices shall be deemed given upon receipt. Notices shall be addressed to the appropriate Party as follows: If to Covered Entity: ________________ @@ -134,7 +140,7 @@ Attn: Compliance Officer -e. Severability. The provisions of this Agreement shall be severable, and if any provision of this Agreement shall be held or declared to be illegal, invalid or unenforceable, the remainder of this Agreement shall continue in full force and effect as though such illegal, invalid or unenforceable provision had not been contained herein. + f. Severability. The provisions of this Agreement shall be severable, and if any provision of this Agreement shall be held or declared to be illegal, invalid or unenforceable, the remainder of this Agreement shall continue in full force and effect as though such illegal, invalid or unenforceable provision had not been contained herein. IN WITNESS WHEREOF, each of the undersigned has duly executed this Agreement on behalf of the party and on the date set forth below. @@ -160,9 +166,3 @@ Print: ___________________________ Title: ___________________________ Date: ___________________________ - - - - - - diff --git a/baa_downstream.txt b/baa_downstream.txt index dae7b9e..6582334 100644 --- a/baa_downstream.txt +++ b/baa_downstream.txt @@ -1,6 +1,6 @@ BUSINESS ASSOCIATE AGREEMENT - This Business Associate Agreement (“Agreement”) by and between ____________ (“Company”) and BloomAPI, Inc. (“Service Provider”), is entered into on this _______ day of __________, 20___ (“Effective Date”), for the purposes of complying with the privacy and security regulations issued by the United States Department of Health and Human Services under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”) and the security provisions of the American Recovery and Reinvestment Act of 2009, also known as the Health Information Technology for Economic and Clinical Health Act (the “HITECH Act”). Company and Service Provider are collectively referred to as the “Parties.” + This Business Associate Agreement (“Agreement”) by and between ____________ (“Company”) and BloomAPI, Inc. (“Service Provider”), is entered into on this _______ day of __________, 20___ (“Effective Date”), for the purposes of complying with the privacy and security regulations issued by the United States Department of Health and Human Services under the Health Insurance Portability and Accountability Act of 1996 (“HIPAA”), the security provisions of the American Recovery and Reinvestment Act of 2009, also known as the Health Information Technology for Economic and Clinical Health Act (the “HITECH Act”), and, where applicable, the Confidentiality of Substance Use Disorder Patient Records regulations at 42 CFR Part 2 (“Part 2”). Company and Service Provider are collectively referred to as the “Parties.” WITNESSETH @@ -20,6 +20,8 @@ I. Definitions B. “Secretary” shall have the meaning ascribed to this term in 45 CFR Section 160.103. + C. “Part 2 Records” shall mean records subject to 42 CFR Part 2 that are created, received, maintained, or transmitted by Service Provider for or on behalf of Company. + II. Confidentiality of PHI A) Obligations of Service Provider @@ -38,6 +40,8 @@ II. Confidentiality of PHI Service Provider further represents that, to the extent Service Provider requests that Company disclose PHI to Service Provider, such request is only for the minimum necessary PHI for the accomplishment of the Service Provider’s purpose. + To the extent Service Provider creates, receives, maintains, or transmits Part 2 Records for or on behalf of Company, Service Provider shall use and disclose such records only as permitted by this Agreement, the Service Agreement, Company instructions, and applicable law. Service Provider shall not use or disclose Part 2 Records in civil, criminal, administrative, or legislative proceedings against a patient unless authorized by a valid Part 2-compliant consent or court order. + iii) Availability of Books and Records Service Provider shall permit the Secretary and his or her delegates to audit Service Provider’s internal practices, books and records at reasonable times as they pertain to the use and disclosure of PHI in order to ensure that Company and/or Service Provider is in compliance with HIPAA. Such information shall be made available in a time and manner designated by Company or the Secretary. @@ -72,7 +76,7 @@ II. Confidentiality of PHI III. Disclosure to Third Parties - Service Provider shall obtain and maintain an agreement with each subcontractor or agent that has or will have access to PHI, pursuant to which agreement such subcontractor or agent agrees to be bound by the same restrictions, terms, and conditions that apply to Service Provider pursuant to the Agreement with respect to such PHI. + Service Provider shall obtain and maintain an agreement with each subcontractor or agent that has or will have access to PHI, pursuant to which agreement such subcontractor or agent agrees to be bound by restrictions, terms, conditions, and safeguards at least as protective as those that apply to Service Provider pursuant to the Agreement with respect to such PHI. Where the subcontractor or agent will access Part 2 Records, the agreement must also require compliance with applicable Part 2 restrictions. IV. Safeguards @@ -80,7 +84,7 @@ IV. Safeguards V. Reporting of Breaches and Improper Disclosures - In the event of a Breach of any Unsecured PHI that Service Provider accesses, maintains, retains, modifies, records, or otherwise holds or uses on behalf of Company, Service Provider shall report such Breach to Company as soon as practicable, but in no event later than three (3) business days after the date the Breach is discovered. Notice of a Breach shall include, to the extent such information is available: (i) the identification of each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, or disclosed during the Breach; (ii) the date of the Breach, if known, and the date of discovery of the Breach; (iii) the scope of the Breach; and (iv) the Service Provider’s response to the Breach. + In the event of a Breach of any Unsecured PHI that Service Provider accesses, maintains, retains, modifies, records, or otherwise holds or uses on behalf of Company, Service Provider shall report such Breach to Company as soon as practicable, but in no event later than three (3) business days after discovery. Notice of a Breach shall include, to the extent such information is available: (i) the identification of each individual whose PHI has been, or is reasonably believed to have been, accessed, acquired, or disclosed during the Breach; (ii) the date of the Breach, if known, and the date of discovery of the Breach; (iii) the scope of the Breach; and (iv) the Service Provider’s response to the Breach. Service Provider shall supplement the notice as additional information becomes available. In the event of a use or disclosure of PHI that is improper under this Agreement but does not constitute a Breach, Service Provider shall report such use or disclosure to Company within five (5) business days after the date on which Service Provider becomes aware of such use or disclosure. diff --git a/bloomapi_hipaa_business_associate_agreement.md b/bloomapi_hipaa_business_associate_agreement.md index ecadf80..9371a99 100644 --- a/bloomapi_hipaa_business_associate_agreement.md +++ b/bloomapi_hipaa_business_associate_agreement.md @@ -1,6 +1,6 @@ # BloomAPI HIPAA Business Associate Agreement ("BAA") -This HIPAA Business Associate Agreement (this "BAA") defines the rights and responsibilities of Provider and Customer with respect to Protected Health Information ("PHI") as defined in the Health Insurance Portability and Accountability Act of 1996 and the regulations promulgated thereunder, including the HITECH Act and Omnibus Rule, as each may be amended from time to time (collectively, "HIPAA"). This BAA shall be applicable only in the event and to the extent Provider meets, with respect to Customer, the definition of a Business Associate set forth at 45 C.F.R. §160.103, or applicable successor provisions. This BAA shall only be applicable to Customer's Hosting Services or Services to the extent that Customer uses the Hosting Services for Customer's Applications and as specified in the Platform as a Service Agreement of which this Exhibit C is attached and fully referenced and incorporated herein (the "SaaS Agreement"). This BAA is intended to ensure that Business Associate and Customer will establish and implement appropriate safeguards where Business Associate may receive, create, maintain, use or disclose in connection with the functions, activities and services that Business Associate performs on behalf of Customer solely to perform its duties and responsibilities under the SaaS Agreement. +This HIPAA Business Associate Agreement (this "BAA") defines the rights and responsibilities of Provider and Customer with respect to Protected Health Information ("PHI") as defined in the Health Insurance Portability and Accountability Act of 1996 and the regulations promulgated thereunder, including the HITECH Act and Omnibus Rule, as each may be amended from time to time (collectively, "HIPAA"). Where Customer uses the Services for records subject to 42 CFR Part 2, this BAA also supports Customer's and Business Associate's applicable obligations for substance use disorder patient records. This BAA shall be applicable only in the event and to the extent Provider meets, with respect to Customer, the definition of a Business Associate set forth at 45 C.F.R. §160.103, or applicable successor provisions. This BAA shall only be applicable to Customer's Hosting Services or Services to the extent that Customer uses the Hosting Services for Customer's Applications and as specified in the Platform as a Service Agreement of which this Exhibit C is attached and fully referenced and incorporated herein (the "SaaS Agreement"). This BAA is intended to ensure that Business Associate and Customer will establish and implement appropriate safeguards where Business Associate may receive, create, maintain, use or disclose in connection with the functions, activities and services that Business Associate performs on behalf of Customer solely to perform its duties and responsibilities under the SaaS Agreement. 1. Applicability and Definitions. This BAA applies only where: 1. Customer uses the Hosting Services to store or transmit any PHI as defined in 45 C.F.R. §160.103 @@ -10,6 +10,7 @@ This HIPAA Business Associate Agreement (this "BAA") defines the rights and resp * "HITECH ACT" shall mean the Health Information Technology for Economic and Clinical Health Act. * "Individual" shall have the same meaning as the term "individual" in 45 CFR § 160.103 and shall include a person who qualifies as a personal representative in accordance with 45 CFR § 164.502(g). * "Privacy Rule" shall mean the Standards for Privacy of Individually Identifiable Health Information at 45 CFR part 160 and part 164, subparts A and E. + * "Part 2 Records" shall mean substance use disorder patient records subject to 42 CFR Part 2 that are received by Business Associate from or on behalf of Customer. * "Protected Health Information" or "PHI" shall have the same meaning as the term "protected health information" in 45 CFR § 160.103, limited to the information received by Business Associate from or on behalf of Customer. * "Required By Law" shall have the same meaning as the term "required by law" in 45 CFR § 164.103. * "Security Rule" shall mean the Security Standards for the Protection of Electronic Protected Health Information, located at 45 CFR Part 160 and Subparts A and C of Part 164. @@ -19,22 +20,24 @@ This HIPAA Business Associate Agreement (this "BAA") defines the rights and resp 4. Obligations of Business Associate. 1. Limit on Uses and Disclosures. Business Associate will use or disclose PHI only as permitted by this BAA or as required by law, provided that any such use or disclosure would not violate HIPAA if done by a Covered Entity, unless permitted for a Business Associate under HIPAA. 2. Safeguards. Business Associate will use reasonable and appropriate safeguards to prevent Use or Disclosure of PHI other than as provided for by this BAA, consistent with the requirements of Subpart C of 45 C.F.R. Part 164 (with respect to Electronic PHI) as determined by Business Associate and as reflected in the SaaS Agreement, which includes Disk Encryption and Encryption In-Transit services. - 3. Reporting. For all reporting obligations under this BAA, the parties acknowledge that, because Business Associate does not know the details of PHI contained in any of Customer Applications, there will be no obligation on the Business Associate to provide information about the identities of the Individuals who may have been affected, or a description of the type of information that may have been subject to a Security Incident, Impermissible Use or Disclosure, or Breach. Business Associate will ensure Customer access to Audit Logging to help Customer in addressing Customer's obligations for reporting under this BAA. Customer acknowledges Business Associate is under no obligation to provide additional support for Customer's BAA reporting obligations but may choose to provide such additional services at its sole discretion or at Customer expense. - 4. Reporting of Impermissible Uses and Disclosures. Business Associate will report to Customer any Use or Disclosure of PHI not permitted or required by this BAA of which Business Associate becomes aware. - 5. Reporting of Security Incidents. Business Associate will report to Customer on no less than fourteen business (14) days from the date any Security Incidents involving PHI of which Business Associate becomes aware in which there is a successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an Information System in a manner that risks the confidentiality, integrity, or availability of such information. Notice is hereby deemed provided, and no further notice will be provided, for unsuccessful attempts at such unauthorized access, use, disclosure, modification, or destruction, such as pings and other broadcast attacks on a firewall, denial of service attacks, port scans, unsuccessful login attempts, or interception of encrypted information where the key is not compromised, or any combination of the above. - 6. Reporting of Breaches. Business Associate will report to Customer any Breach of Customer's Unsecured PHI that Business Associate may discover to the extent required by 45 C.F.R. § 164.410. Business Associate will make such report without unreasonable delay, and in no case later than four (4) hours after discovery of such Breach. Business Associate undertakes no obligation to report network security related incidents which occur on its managed network but does not directly involve Customer's use of Hosting Services. - 7. Subcontractors. Business Associate will ensure that any subcontractors that create, receive, maintain, or transmit PHI on behalf of Business Associate agree to restrictions and conditions at least as stringent as those found in this BAA, and agree to implement reasonable and appropriate safeguards to protect PHI. + 2.1. Part 2 Records. To the extent Business Associate creates, receives, maintains, or transmits Part 2 Records for or on behalf of Customer, Business Associate will use and disclose such records only as permitted by this BAA, the SaaS Agreement, Customer instructions, and applicable law. Business Associate will not use or disclose Part 2 Records in civil, criminal, administrative, or legislative proceedings against a patient unless authorized by a valid Part 2-compliant consent or court order. + 3. Reporting. For all reporting obligations under this BAA, the parties acknowledge that, because Business Associate does not know the details of PHI contained in any of Customer Applications, there will be no obligation on the Business Associate to provide information about the identities of the Individuals who may have been affected, or a description of the type of information that may have been subject to a Security Incident, Impermissible Use or Disclosure, or Breach. Business Associate will make available audit logging information within its control to help Customer address Customer's obligations under this BAA, to the extent reasonably available and legally permitted. Customer acknowledges Business Associate is under no obligation to provide additional support for Customer's BAA reporting obligations but may choose to provide such additional services at its sole discretion or at Customer expense. + 4. Reporting of Impermissible Uses and Disclosures. Business Associate will report to Customer any Use or Disclosure of PHI not permitted or required by this BAA of which Business Associate becomes aware without unreasonable delay and no later than ten (10) business days after Business Associate becomes aware of such Use or Disclosure. + 5. Reporting of Security Incidents. Business Associate will report to Customer without unreasonable delay and no later than ten (10) business days after Business Associate becomes aware of any Security Incident involving PHI in which there is a successful unauthorized access, use, disclosure, modification, or destruction of information or interference with system operations in an Information System in a manner that risks the confidentiality, integrity, or availability of such information. Notice is hereby deemed provided, and no further notice will be provided, for unsuccessful attempts at such unauthorized access, use, disclosure, modification, or destruction, such as pings and other broadcast attacks on a firewall, denial of service attacks, port scans, unsuccessful login attempts, or interception of encrypted information where the key is not compromised, or any combination of the above. + 6. Reporting of Breaches. Business Associate will report to Customer any Breach of Customer's Unsecured PHI that Business Associate may discover to the extent required by 45 C.F.R. § 164.410. Business Associate will make such report without unreasonable delay, and in no case later than ten (10) business days after discovery of such Breach. Business Associate will supplement the report as additional information becomes available. Business Associate undertakes no obligation to report network security related incidents which occur on its managed network but does not directly involve Customer's use of Hosting Services. + 7. Subcontractors. Business Associate will ensure that any subcontractors that create, receive, maintain, or transmit PHI on behalf of Business Associate agree to restrictions, conditions, requirements, and safeguards at least as protective as those found in this BAA, and agree to implement reasonable and appropriate safeguards to protect PHI. Where a subcontractor will create, receive, maintain, or transmit Part 2 Records, Business Associate will require the subcontractor to comply with applicable Part 2 restrictions. 8. Access to PHI. Customer acknowledges that Business Associate is not required by this BAA to make disclosures of PHI to Individuals or any person other than Customer, and that Business Associate does not, therefore, expect to maintain documentation of such disclosure as described in 45 CFR § 164.528. In the event that Business Associate does make such disclosure, it shall document the disclosure as would be required for Customer to respond to a request by an Individual for an accounting of disclosures in accordance with 45 CFR §164.504(e)(2)(ii)(G) and §164.528, and shall provide such documentation to Customer promptly on Customer's request. In the event that a request for an accounting is made directly to Business Associate shall, within 5 Business Days, forward such request to Customer. 9. Accounting of Disclosures. Business Associate will make available to Customer the information required to provide an accounting of Disclosures in accordance with 45 C.F.R. § 164.528 of which Business Associate is aware, if requested by Customer. Because Business Associate cannot readily identify which Individuals are identified or what types of PHI are included in Customer Content, Customer will be solely responsible for identifying which Individuals, if any, may have been included in Customer Content that Provider has disclosed and for providing a brief description of the PHI disclosed. 10. Internal Records. Provider will make its internal practices, books, and records relating to the Use and Disclosure of PHI available to the Secretary of the U.S. Department of Health and Human Services ("HHS") for purposes of determining Customer compliance with HIPAA. Nothing in this section will waive any applicable privilege or protection, including with respect to trade secrets and confidential commercial information. 5. Customer's Obligations: - 1. Appropriate Use of HIPAA Accounts. Customer is responsible for implementing appropriate privacy and security safeguards in order to protect PHI in compliance with HIPAA and this BAA. Without limitation, Customer shall: (i) not include protected health information (as defined in 45 CFR 160.103) in any Services that are not or cannot be HIPAA compliant, (ii) utilize the highest level of audit logging in connection with its use of all Customer Applications, and (iii) maintain the maximum retention of logs in connection with its use of all Services. + 1. Appropriate Use of HIPAA Accounts. Customer is responsible for implementing appropriate privacy and security safeguards in order to protect PHI in compliance with HIPAA and this BAA. Without limitation, Customer shall: (i) not include protected health information (as defined in 45 CFR 160.103) in any Services that are not authorized for PHI under this BAA, (ii) utilize available audit logging appropriate to Customer's use of all Customer Applications, and (iii) maintain log retention appropriate to Customer's compliance obligations in connection with its use of all Services. 2. HIPAA Account Appropriate Configurations: Customer is solely responsible for configuring, and will configure, all Customer Applications as follows: 3. Encryption. Customer shall encrypt all PHI stored or transmitted outside the Services in accordance with the Secretary of HHS's Guidance to Render Unsecured Protected Health Information Unusable, Unreadable, or Indecipherable to Unauthorized Individuals, available at http://www.hhs.gov/ocr/privacy/hipaa/administrative/breachnotificationrule/brguidance.html, as it may be updated from time to time, and as may be made available on any successor or related site designated by HHS. 4. SSL Termination: All services must be served via SSL. Customer is responsible for providing, maintaining and updating a valid SSL certificate for use with the Service. SSL certificates must be a minimum of 4096 bit key size. Customer agrees to comply with Business Associate's requirements regarding SSL termination. 5. Necessary Consents. Customer warrants that it has obtained any necessary authorizations, consents, and other permissions that may be required under applicable law prior to placing Customer Content, including without limitation PHI, on the Services. 6. Restrictions on Disclosures. Customer shall not agree to any restriction requests or place any restrictions in any notice of privacy practices that would cause Business Associate to violate this BAA or any applicable law. 7. Compliance with HIPAA. Customer shall not request or cause Business Associate to make a Use or Disclosure of PHI in a manner that does not comply with HIPAA or this BAA. + 8. Part 2 Records. Customer is responsible for notifying Business Associate when Customer's use of the Services involves Part 2 Records and for obtaining any consent, authorization, notice, or court order required for Customer's use or disclosure of Part 2 Records through the Services. 6. Term and Termination 1. Term. The term of this BAA will commence on the SaaS Agreement Effective Date and will remain in effect until the earlier of the termination of the SaaS Agreement or notification by Customer that an account is no longer subject to this BAA. 2. Effect of Termination. At termination of this BAA, Business Associate, if feasible, will return or destroy all PHI that Business Associate still maintains, if any. If return or destruction is not feasible, Business Associate will extend the protections of this Agreement to the PHI, limit further uses and disclosures to those purposes that make the return of the PHI infeasible, and make not further use or disclosure of PHI. @@ -46,5 +49,6 @@ This HIPAA Business Associate Agreement (this "BAA") defines the rights and resp 1. Amendment. Customer and Business Associate agrees to take such action as is reasonably necessary to amend this HIPAA BAA from time to time as is necessary for either party to comply with the requirements of the Privacy Rule and related laws and regulations. 2. Survival. Customer and Business Associate's respective rights and obligations under this HIPAA BAA shall survive the termination of the Agreement. 3. Interpretation. Any ambiguity in the SaaS Agreement shall be resolved to permit Customer to comply with HIPAA and the Privacy Rule. + 4. Existing Agreements. Existing signed agreements remain governed by their executed terms unless amended in writing by the parties. SIGNATURE FOLLOWS diff --git a/breach_policy.md b/breach_policy.md index da251ee..a23fba7 100644 --- a/breach_policy.md +++ b/breach_policy.md @@ -1,10 +1,10 @@ # Breach Policy -To provide guidance for breach notification when impressive or unauthorized access, acquisition, use and/or disclosure of the ePHI occurs. Breach notification will be carried out in compliance with the American Recovery and Reinvestment Act (ARRA)/Health Information Technology for Economic and Clinical Health Act (HITECH) as well as any other federal or state notification law. +To provide guidance for breach notification when impermissible or unauthorized access, acquisition, use, and/or disclosure of PHI, ePHI, or Part 2 records occurs. Breach notification will be carried out in compliance with the HIPAA Breach Notification Rule, the Health Information Technology for Economic and Clinical Health Act (HITECH), 42 CFR Part 2 when applicable, contracts, and any other federal or state notification law. -The Federal Trade Commission (FTC) has published breach notification rules for vendors of personal health records as required by ARRA/HITECH. The FTC rule applies to entities not covered by HIPAA, primarily vendors of personal health records. The rule is effective September 24, 2009 with full compliance required by February 22, 2010. +The Federal Trade Commission (FTC) Health Breach Notification Rule applies to vendors of personal health records, PHR related entities, and third-party service providers that are not covered by HIPAA. The FTC finalized amendments effective July 29, 2024 that clarify the rule's application to health apps and similar technologies, unauthorized disclosures, electronic notice, consumer notice content, and FTC notice timing. BloomAPI evaluates FTC notice obligations when an incident involves non-HIPAA personal health record services or related third-party service provider duties. -The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on February 17, 2009. Title XIII of ARRA is the Health Information Technology for Economic and Clinical Health Act (HITECH). HITECH significantly impacts the Health Insurance Portability and Accountability (HIPAA) Privacy and Security Rules. While HIPAA did not require notification when patient protected health information (PHI) was inappropriately disclosed, covered entities and business associates may have chosen to include notification as part of the mitigation process. HITECH does require notification of certain breaches of unsecured PHI to the following: individuals, Department of Health and Human Services (HHS), and the media. The effective implementation for this provision is September 23, 2009 (pending publication HHS regulations). +The American Recovery and Reinvestment Act of 2009 (ARRA) was signed into law on February 17, 2009. Title XIII of ARRA is the Health Information Technology for Economic and Clinical Health Act (HITECH). HITECH significantly impacts the Health Insurance Portability and Accountability (HIPAA) Privacy and Security Rules. HITECH requires notification of certain breaches of unsecured PHI to individuals, the Department of Health and Human Services (HHS), and in some cases the media. The 2024 Part 2 final rule aligns Part 2 breach notification and enforcement with HIPAA for unsecured Part 2 records, with compliance required by February 16, 2026. In the case of a breach, BloomAPI shall notify all affected Customers. It is the responsibility of the Customers to notify affected individuals. @@ -24,15 +24,17 @@ In the case of a breach, BloomAPI shall notify all affected Customers. It is the 1. Discovery of Breach: A breach of ePHI shall be treated as "discovered" as of the first day on which such breach is known to the organization, or, by exercising reasonable diligence would have been known to BloomAPI (includes breaches by the organization's Customers, Partners, or subcontractors). BloomAPI shall be deemed to have knowledge of a breach if such breach is known or by exercising reasonable diligence would have been known, to any person, other than the person committing the breach, who is a workforce member or Partner of the organization. Following the discovery of a potential breach, the organization shall begin an investigation (see organizational policies for security incident response and/or risk management incident response) immediately, conduct a risk assessment, and based on the results of the risk assessment, begin the process to notify each Customer affected by the breach. BloomAPI shall also begin the process of determining what external notifications are required or should be made (e.g., Secretary of Department of Health & Human Services (HHS), media outlets, law enforcement officials, etc.) 2. Breach Investigation: The BloomAPI Security Officer shall name an individual to act as the investigator of the breach (e.g., privacy officer, security officer, risk manager, etc.). The investigator shall be responsible for the management of the breach investigation, completion of a risk assessment, and coordinating with others in the organization as appropriate (e.g., administration, security incident response team, human resources, risk management, public relations, legal counsel, etc.) The investigator shall be the key facilitator for all breach notification processes to the appropriate entities (e.g., HHS, media, law enforcement officials, etc.). All documentation related to the breach investigation, including the risk assessment, shall be retained for a minimum of six years. A template breach log is located [here](breach.log.pdf). -3. Risk Assessment: For an acquisition, access, use or disclosure of ePHI to constitute a breach, it must constitute a violation of the HIPAA Privacy Rule. A use or disclosure of ePHI that is incident to an otherwise permissible use or disclosure and occurs despite reasonable safeguards and proper minimum necessary procedures would not be a violation of the Privacy Rule and would not qualify as a potential breach. To determine if an impermissible use or disclosure of ePHI constitutes a breach and requires further notification, the organization will need to perform a risk assessment to determine if there is significant risk of harm to the individual as a result of the impermissible use or disclosure. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all notifications to appropriate Customers or that the use or disclosure did not constitute a breach. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address: - * Consideration of who impermissibly used or to whom the information was impermissibly disclosed; - * The type and amount of ePHI involved; - * The cause of the breach, and the entity responsible for the breach, either Customer, BloomAPI, or Partner. - * The potential for significant risk of financial, reputational, or other harm. -4. Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected BloomAPI Customers no later than 4 hours after the discovery of the breach. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay. +3. Risk Assessment: An impermissible use or disclosure of PHI is presumed to be a breach unless BloomAPI or the responsible regulated entity demonstrates a low probability that the PHI has been compromised. The organization shall document the risk assessment as part of the investigation in the incident report form noting the outcome of the risk assessment process. The organization has the burden of proof for demonstrating that all required notifications were made or that notification was not required. Based on the outcome of the risk assessment, the organization will determine the need to move forward with breach notification. The risk assessment and the supporting documentation shall be fact specific and address at least: + * The nature and extent of the PHI involved, including the types of identifiers and the likelihood of re-identification; + * The unauthorized person who used the PHI or to whom the disclosure was made; + * Whether the PHI was actually acquired or viewed; + * The extent to which the risk to the PHI has been mitigated; + * Whether the incident involves Part 2 records, SUD counseling notes, reproductive health information, or other specially protected information; + * The cause of the incident and the entity responsible for it, either Customer, BloomAPI, Partner, or Subcontractor. +4. Timeliness of Notification: Upon discovery of a breach, notice shall be made to the affected BloomAPI Customers without unreasonable delay and no later than ten (10) business days after discovery, unless a signed agreement requires a different timeline. BloomAPI attempts to provide an initial operational heads-up sooner when practical, but the contractual notice deadline is governed by the applicable BAA. It is the responsibility of the organization to demonstrate that all notifications were made as required, including evidence demonstrating the necessity of delay. 5. Delay of Notification Authorized for Law Enforcement Purposes: If a law enforcement official states to the organization that a notification, notice, or posting would impede a criminal investigation or cause damage to national security, the organization shall: - * If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting of the timer period specified by the official; or - * If the statement is made orally, document the statement, including the identify of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time. + * If the statement is in writing and specifies the time for which a delay is required, delay such notification, notice, or posting for the time period specified by the official; or + * If the statement is made orally, document the statement, including the identity of the official making the statement, and delay the notification, notice, or posting temporarily and no longer than 30 days from the date of the oral statement, unless a written statement as described above is submitted during that time. 6. Content of the Notice: The notice shall be written in plain language and must contain the following information: * A brief description of what happened, including the date of the breach and the date of the discovery of the breach, if known; * A description of the types of unsecured protected health information that were involved in the breach (such as whether full name, Social Security number, date of birth, home address, account number, diagnosis, disability code or other types of information were involved), if known; @@ -40,13 +42,14 @@ In the case of a breach, BloomAPI shall notify all affected Customers. It is the * A brief description of what BloomAPI is doing to investigate the breach, to mitigate harm to individuals and Customers, and to protect against further breaches. * Contact procedures for individuals to ask questions or learn additional information, which may include a toll-free telephone number, an email address, a web site, or postal address. 7. Methods of Notification: BloomAPI Customers will be notified via email and phone within the timeframe for reporting breaches, as outlined above. -8. Maintenance of Breach Information/Log: As described above and in addition to the reports created for each incident, BloomAPI shall maintain a process to record or log all breaches of unsecured ePHI regardless of the number of records and Customers affected. The following information should be collected/logged for each breach (see sample Breach Notification Log): +8. Part 2 Breach Handling: If an incident involves unsecured Part 2 records, the investigator shall document the Customer or program involved, whether BloomAPI is acting as a business associate, qualified service organization, lawful holder, or subcontractor, and whether Part 2 individual, HHS Secretary, media, Customer, contractual, or state-law notices are required. Part 2 records may not be used or disclosed in proceedings against a patient unless reviewed and approved under the Part 2 SUD Records Policy. +9. Maintenance of Breach Information/Log: As described above and in addition to the reports created for each incident, BloomAPI shall maintain a process to record or log all breaches of unsecured ePHI or Part 2 records regardless of the number of records and Customers affected. The following information should be collected/logged for each breach (see sample Breach Notification Log): * A description of what happened, including the date of the breach, the date of the discovery of the breach, and the number of records and Customers affected, if known. * A description of the types of unsecured protected health information that were involved in the breach (such as full name, Social Security number, date of birth, home address, account number, etc.), if known. * A description of the action taken with regard to notification of patients regarding the breach. * Resolution steps taken to mitigate the breach and prevent future occurrences. -10. Workforce Training: BloomAPI shall train all members of its workforce on the policies and procedures with respect to ePHI as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization. -11. Complaints: BloomAPI must provide a process for individuals to make complaints concerning the organization's patient privacy policies and procedures or its compliance with such policies and procedures. +10. Workforce Training: BloomAPI shall train all members of its workforce on the policies and procedures with respect to ePHI and Part 2 records as necessary and appropriate for the members to carry out their job responsibilities. Workforce members shall also be trained as to how to identify and report breaches within the organization. +11. Complaints: BloomAPI must provide a process for individuals to make complaints concerning the organization's patient privacy policies and procedures or its compliance with such policies and procedures, including Part 2 complaints when BloomAPI is subject to Part 2 requirements. 12. Sanctions: The organization shall have in place and apply appropriate sanctions against members of its workforce, Customers, and Partners who fail to comply with privacy policies and procedures. 13. Retaliation/Waiver: BloomAPI may not intimidate, threaten, coerce, discriminate against, or take other retaliatory action against any individual for the exercise by the individual of any privacy right. The organization may not require individuals to waive their privacy rights under as a condition of the provision of treatment, payment, enrollment in a health plan, or eligibility for benefits. diff --git a/configuration_management_policy.md b/configuration_management_policy.md index ea0019e..d3e530b 100644 --- a/configuration_management_policy.md +++ b/configuration_management_policy.md @@ -15,10 +15,13 @@ BloomAPI standardizes and automates configuration management through the use of 1. Ansible is used to standardize and automate configuration management. 2. No systems are deployed into BloomAPI environments without approval of the BloomAPI CTO. 3. All changes to production systems, network devices, and firewalls are approved by the BloomAPI CTO before they are implemented. Additionally, all changes are tested before they are implemented in production. -4. An up-to-date inventory of systems is maintained. All systems are categorized as production and utility to differentiate based on criticality. -5. Clocks are synchronized across all systems using NTP. Modifying time data on systems is restricted. -6. All front end functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers. -7. All software and systems are tested using end-to-end tests. -8. All committed code is reviewed using pull requests GitHub to assure software code quality and proactively detect potential security issues in development. -9. BloomAPI utilizes development and staging environments that mirror production to assure proper function. -10. All formal change requests require unique ID and authentication. +4. An up-to-date inventory of technology assets is maintained, including systems, applications, databases, network components, cloud resources, service accounts, and third-party services that create, receive, maintain, or transmit ePHI. All systems are categorized as production and utility to differentiate based on criticality. +5. BloomAPI maintains a network map or data flow diagram showing where ePHI enters, is processed, is stored, is transmitted, and leaves the BloomAPI environment. The inventory and network map are reviewed at least annually and after material changes. +6. Clocks are synchronized across all systems using NTP. Modifying time data on systems is restricted. +7. All front end functionality (developer dashboards and portals) is separated from backend (database and app servers) systems by being deployed on separate servers. +8. Production systems are segmented from development, staging, corporate, and public networks. Access between segments is restricted to approved ports, protocols, services, and identities. +9. All software and systems are tested using end-to-end tests. +10. All committed code is reviewed using pull requests GitHub to assure software code quality and proactively detect potential security issues in development. +11. BloomAPI utilizes development and staging environments that mirror production to assure proper function. +12. All formal change requests require unique ID and authentication. +13. Material changes affecting systems that create, receive, maintain, or transmit ePHI require evaluation of security impact, logging impact, backup impact, and any update needed to the asset inventory or network map. diff --git a/data_management_policy.md b/data_management_policy.md index acdceba..837a2ff 100644 --- a/data_management_policy.md +++ b/data_management_policy.md @@ -25,5 +25,9 @@ Violation of this policy and its procedures by workforce members may result in c * Name of the system * Date & time of backup * Where backup stored (or to whom it was provided) -5. Securely encrypt stored backups in a manner that protects them from loss or environmental damage. -6. Test backups and document that files have been completely and accurately restored from the backup media. +5. Cloud Spanner backups are retained for 30 days. +6. Securely encrypt stored backups in a manner that protects them from loss or environmental damage. +7. Protect backup encryption keys separately from encrypted backup data and limit key access to authorized workforce members. +8. Maintain backup protections that are resilient to accidental deletion, malicious alteration, ransomware, and compromise of a single production account where feasible. +9. Test backups at least annually and after material backup architecture changes, and document that files have been completely and accurately restored from the backup media. +10. Document recovery point objectives and recovery time objectives for critical systems and review them at least annually. diff --git a/data_retention_policy.md b/data_retention_policy.md index 7c749f2..3666255 100644 --- a/data_retention_policy.md +++ b/data_retention_policy.md @@ -9,7 +9,22 @@ Despite not being a requirement within HIPAA, BloomAPI understand and appreciate ## Data Retention Policy * Current BloomAPI Customers have data stored by BloomAPI as a part of the BloomAPI Service. -* Once a Customer ceases to be a Customer, as defined below, the following steps are +* Once a Customer ceases to be a Customer, as defined below, the following steps are followed: 1. Customer is sent a notice via email of change of standing, and given the option to reinstate account. 2. If no response to notice in #1 above within 7 days, or if Customer responds they do not want to reinstate account, Customer is sent directions for how to download their data from BloomAPI. 3. If Customer downloads data or does not respond to notices from BloomAPI within 30 days, BloomAPI may remove data from BloomAPI systems and Customer is sent notice of removal of data. + 4. Customer data retained in backups, logs, legal holds, security records, or other systems where immediate deletion is infeasible remains protected under BloomAPI policies and applicable agreements until it is deleted or destroyed in the normal retention cycle. + 5. Part 2 records are retained, returned, or destroyed according to Customer instructions, applicable Part 2 agreements, legal holds, and applicable law. + 6. Cloud Spanner backups are retained for 30 days. + +## Retention Verification TODOs + +The following retention details must be verified before final retention periods are represented as completed controls: + +* Google Cloud Armor log retention and export configuration. +* Server and machine log retention. +* Grafana alert history retention. +* Sentry event retention and whether PHI or Part 2 data can reach Sentry. +* Customer login history retention and whether the system stores full login history or only last activity. +* GCP Cloud Audit Logs retention and export configuration for IAM, administrative, and configuration changes. +* PostHog event retention and whether PHI or Part 2 data can reach PostHog. diff --git a/disaster_recovery_policy.md b/disaster_recovery_policy.md index 6bfeea6..a20a1e9 100644 --- a/disaster_recovery_policy.md +++ b/disaster_recovery_policy.md @@ -59,7 +59,7 @@ The following teams have been developed and trained to respond to a contingency ## Testing and Maintenance -The CTO shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan's execution. At a minimum the Contingency Plan shall be tested annually (within 365 days). The types of validation/testing exercises include technical testing. +The CTO shall establish criteria for validation/testing of a Contingency Plan, an annual test schedule, and ensure implementation of the test. This process will also serve as training for personnel involved in the plan's execution. At a minimum the Contingency Plan shall be tested annually (within 365 days) and after material changes to critical systems. The types of validation/testing exercises include technical testing. ### Technical Testing @@ -68,6 +68,7 @@ The primary objective of the technical test is to ensure the communication proce * Process from backup system at the alternate site; * Restore system using backups; and * Switch compute and storage resources to alternate processing site. +* Validate recovery point objectives, recovery time objectives, logging, monitoring, and access controls after restoration. ## 1. Notification and Activation Phase @@ -86,6 +87,7 @@ The notification sequence is listed below: * BloomAPI will be unavailable for more than 48 hours. * Hosting facility is damaged and will be unavailable for more than 24 hours. * Other criteria, as appropriate and as defined by BloomAPI. + * A security incident, ransomware event, or operational failure materially affects the confidentiality, integrity, or availability of ePHI and requires alternate processing or recovery procedures. * If the plan is to be activated, the CTO is to notify and inform team members of the details of the event and if relocation is required. * Upon notification from the CTO, group leaders and managers are to notify their respective teams. Team members are to be informed of all applicable information and prepared to respond and relocate if necessary. * The CTO is to notify the hosting facility partners that a contingency event has been declared and to ship the necessary materials (as determined by damage assessment) to the alternate site. diff --git a/employees_policy.md b/employees_policy.md index fb7e435..fbdf8e9 100644 --- a/employees_policy.md +++ b/employees_policy.md @@ -20,6 +20,8 @@ BloomAPI is committed to ensuring all workforce members actively address securit 2. All workforce members are granted access to formal organizational policies, which include the sanction policy for security violations. 3. All workforce members are educated about the approved set of tools to be installed on workstations. 4. All new workforce members are given HIPAA training within 30 days of beginning employment. Training includes HIPAA reporting requirements, including the ability to anonymously report security incidents, and the levels of compliance and obligations for BloomAPI and its Customers and Partners. -5. All remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. -6. Access to internal BloomAPI systems can be requested by emailing the Security Officer. All requests for access much be granted by the BloomAPI Security Officer. -7. Request for modifications of access for any BloomAPI employee can be made by emailing the Security Officer. +5. Workforce members whose duties may involve Customers subject to 42 CFR Part 2 receive training on Part 2 records, redisclosure restrictions, SUD counseling notes, legal-proceeding restrictions, breach escalation, and Customer notice obligations. +6. HIPAA and Part 2 training is refreshed at least annually and when material regulatory or policy changes affect workforce responsibilities. +7. All remote (teleworking) workforce members are trained on the risks, the controls implemented, their responsibilities, and sanctions associated with violation of policies. +8. Access to internal BloomAPI systems can be requested by emailing the Security Officer. All requests for access must be granted by the BloomAPI Security Officer. +9. Request for modifications of access for any BloomAPI employee can be made by emailing the Security Officer. diff --git a/hipaa_inheritance.md b/hipaa_inheritance.md deleted file mode 100644 index c6cad5b..0000000 --- a/hipaa_inheritance.md +++ /dev/null @@ -1,42 +0,0 @@ -# HIPAA Inheritance for BloomText Customers - -| **Administrative Controls** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Security Management Process - 164.308(a)(1)(i) | Risk Management Policy | Yes -Assigned Security Responsibility - 164.308(a)(2) | Roles Policy | Partially -Workforce Security - 164.308(a)(3)(i) | Employee Policies | Partially -Information Access Management - 164.308(a)(4)(i) | System Access Policy | Yes -Security Awareness and Training - 164.308(a)(5)(i) | Employee Policy | No -Security Incident Procedures - 164.308(a)(6)(i) | IDS Policy | Yes -Contingency Plan - 164.308(a)(7)(i) | Disaster Recovery Policy | Yes -Evaluation - 164.308(a)(8) | Auditing Policy | Yes - -| **Physical Safeguards** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Facility Access Controls - 164.310(a)(1) | Facility and Disaster Recovery Policies | Yes -Workstation Use - 164.310(b) | System Access, Approved Tools, and Employee Policies | Partially -Workstation Security - 164.310('c') | System Access, Approved Tools, and Employee Policies | Partially -Device and Media Controls - 164.310(d)(1) | Disposable Media and Data Management Policies | Yes - -| **Technical Safeguards** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Access Control - 164.312(a)(1) | System Access Policy | Partially -Audit Controls - 164.312(b) | Auditing Policy | Yes (optional) -Integrity - 164.312('c')(1) | System Access, Auditing, and IDS Policies | Yes (optional) -Person or Entity Authentication - 164.312(d) | System Access Policy | Yes -Transmission Security - 164.312(e)(1) | System Access and Data Management Policy | Yes - -| **Organizational Requirements** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Business Associate Contracts or Other Arrangements - 164.314(a)(1)(i) | Business Associate Agreements and 3rd Parties Policies | Partially - -| **Policies and Procedures and Documentation Requirements** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Policies and Procedures - 164.316(a) | Policy Management Policy | Partially -Documentation - 164.316(b)(1)(i) | Policy Management Policy | Partially - -| **HITECH Act - Security Provisions** HIPAA Rule | BloomAPI Control | Inherited ---- | --- | --- -Notification in the Case of Breach - 13402(a) and (b) | Breach Policy | Partially -Timelines of Notification - 13402(d)(1) | Breach Policy | Partially -Content of Notification - 13402(f)(1) | Breach Policy | Partially diff --git a/hipaa_mapping_to_bloomapi_controls.md b/hipaa_mapping_to_bloomapi_controls.md index 91edb15..fd4918c 100644 --- a/hipaa_mapping_to_bloomapi_controls.md +++ b/hipaa_mapping_to_bloomapi_controls.md @@ -16,8 +16,8 @@ Evaluation - 164.308(a)(8) | Auditing Policy | **Physical Safeguards** HIPAA Rule | BloomAPI Control --- | --- Facility Access Controls - 164.310(a)(1) | Facility and Disaster Recovery Policies -Workstation Use - 164.310(b) | System Access, Approved Tools, and Employee Policies -Workstation Security - 164.310('c') | System Access, Approved Tools, and Employee Policies +Workstation Use - 164.310(b) | System Access, Approved Tools, managed browser/extension controls, and Employee Policies +Workstation Security - 164.310('c') | System Access, Approved Tools, managed browser/extension controls, and Employee Policies Device and Media Controls - 164.310(d)(1) | Disposable Media and Data Management Policies | **Technical Safeguards** HIPAA Rule | BloomAPI Control @@ -41,4 +41,19 @@ Documentation - 164.316(b)(1)(i) | Policy Management Policy --- | --- Notification in the Case of Breach - 13402(a) and (b) | Breach Policy Timelines of Notification - 13402(d)(1) | Breach Policy -Content of Notification - 13402(f)(1) | Breach Policy \ No newline at end of file +Content of Notification - 13402(f)(1) | Breach Policy + +| **42 CFR Part 2 - SUD Records** Requirement | BloomAPI Control +--- | --- +Part 2 permitted uses, disclosures, and redisclosure restrictions | Part 2 SUD Records Policy, Business Associate Agreements, 3rd Party Policy +Part 2 legal-proceeding restrictions and SUD counseling note protections | Part 2 SUD Records Policy, Incident Response Policy +Part 2 breach notification and enforcement alignment with HIPAA | Part 2 SUD Records Policy, Breach Policy +Part 2 patient notice and Customer support requirements | Part 2 SUD Records Policy, Policy Management Policy + +| **HIPAA Security Rule Cybersecurity Readiness** Proposed 2025 NPRM Item | BloomAPI Control +--- | --- +Technology asset inventory and network map | Configuration Management Policy, Data Integrity Policy +Multi-factor authentication and access review | System Access Policy +Encryption, segmentation, backups, and recovery testing | Data Management Policy, Disaster Recovery Policy, Data Integrity Policy +Vulnerability scanning and penetration testing | Vulnerability Scanning Policy, Auditing Policy +Annual compliance evaluation and risk analysis documentation | Risk Management Policy, Auditing Policy, Policy Management Policy diff --git a/incident_response_policy.md b/incident_response_policy.md index e7fd0ff..55b2028 100644 --- a/incident_response_policy.md +++ b/incident_response_policy.md @@ -48,8 +48,9 @@ The BloomAPI incident response process follows the process recommended by SANS, 4. The Containment, Eradication, and Recovery Phases are highly technical. It is important to have them completed by a highly qualified technical security resource with oversight by the SIRT team. 5. Each individual on the SIRT and the technical security resource document all measures taken during each phase, including the start and end times of all efforts. 6. The lead member of the SIRT team facilitates initiation of a Security Incident Report (SIR) Form (See Appendix 2 for sample format) or an Incident Survey Form (See Appendix 4). The intent of the SIR form is to provide a summary of all events, efforts, and conclusions of each Phase of this policy and procedures. - 11. The Security Officer, Privacy Officer, or BloomAPI representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer. - 12. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to BloomAPI and potentially external. +11. The Security Officer, Privacy Officer, or BloomAPI representative appointed notifies any affected Customers and Partners. If no Customers and Partners are affected, notification is at the discretion of the Security and Privacy Officer. +12. In the case of a threat identified, the Security Officer is to form a team to investigate and involve necessary resources, both internal to BloomAPI and potentially external. +13. If an incident involves Part 2 records, SUD counseling notes, reproductive health information, legal process, law enforcement requests, or other specially protected information, the Privacy Officer is included in the response before disclosure or external production of records. ### Containment Phase (Technical) @@ -119,6 +120,14 @@ The Follow-up Phase represents the review of the security incident to look for " It is important to note that the processes surrounding security incident response should be periodically reviewed and evaluated for effectiveness. This also involves appropriate training of resources expected to respond to security incidents, as well as the training of the general population regarding the BloomAPI's expectation for them, relative to security responsibilities. The incident response plan is tested annually. +### Legal and Law Enforcement Requests + +1. Requests from law enforcement, regulators, courts, attorneys, public agencies, or other legal requestors for PHI, ePHI, Part 2 records, Customer data, logs, or account information must be escalated to the Privacy Officer before disclosure. +2. BloomAPI verifies the identity and authority of the requestor and documents the request, legal basis, review decision, information disclosed, date of disclosure, and any Customer notice. +3. BloomAPI notifies the affected Customer before disclosure unless prohibited by law, court order, or documented emergency circumstances. +4. BloomAPI discloses only the minimum necessary information required by the request and applicable law. +5. Requests involving Part 2 records or SUD counseling notes require review under the Part 2 SUD Records Policy before disclosure. + ## Security Incident Response Team (SIRT) Individuals needed and responsible to respond to a security incident make up a Security Incident Response Team (SIRT). Members may include the following: diff --git a/introduction.md b/introduction.md index 099849a..7cac4ba 100644 --- a/introduction.md +++ b/introduction.md @@ -1,23 +1,23 @@ # Introduction -BloomAPI, Inc ("BloomAPI") is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its customers. As providers of compliant, hosted infrastructure used by health technology vendors, developers, designers, agencies, custom development shops, and enterprises, BloomAPI strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by BloomAPI to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for BloomAPI Customers. +BloomAPI, Inc ("BloomAPI") is committed to ensuring the confidentiality, privacy, integrity, and availability of all electronic protected health information (ePHI) it receives, maintains, processes and/or transmits on behalf of its customers. As providers of hosted software and infrastructure used by health technology vendors, developers, designers, agencies, custom development shops, and enterprises, BloomAPI strives to maintain compliance, proactively address information security, mitigate risk for its Customers, and assure known breaches are completely and effectively communicated in a timely manner. The following documents address core policies used by BloomAPI to maintain compliance and assure the proper protections of infrastructure used to store, process, and transmit ePHI for BloomAPI Customers. -## Compliance Inheritance +## Shared Responsibility -BloomAPI provides compliant software for its Customers. +BloomAPI provides software and infrastructure controls that support Customer compliance obligations. -BloomAPI signs business associate agreements (BAAs) with its Customers. These BAAs outline BloomAPI obligations and Customer obligations, as well as liability in the case of a breach. In providing infrastructure and managing security configurations that are a part of the technology requirements that exist in HIPAA and HITRUST, as well as future compliance frameworks, BloomAPI manages various aspects of compliance for Customers. The aspects of compliance that BloomAPI manages for Customers are inherited by Customers, and BloomAPI assumes the risk associated with those aspects of compliance. In doing so, BloomAPI helps Customers achieve and maintain compliance, as well as mitigates Customers risk. +BloomAPI signs business associate agreements (BAAs) with its Customers. These BAAs outline BloomAPI obligations and Customer obligations, as well as liability in the case of a breach. In providing infrastructure and managing security configurations that are part of HIPAA, HITRUST, and other compliance frameworks, BloomAPI manages certain technical and operational safeguards for Customers. Customers remain responsible for their own legal, clinical, administrative, workforce, patient notice, consent, and account administration obligations. -Certain aspects of compliance cannot be inherited. Because of this, BloomAPI Customers, in order to achieve full compliance or HITRUST Certification, must implement certain organizational policies. These policies and aspects of compliance fall outside of the services and obligations of BloomAPI. +Certain aspects of compliance are Customer-owned. Because of this, BloomAPI Customers must implement their own organizational policies and procedures to meet obligations that fall outside of BloomAPI's services and agreements. -Below are mappings of HIPAA Rules to BloomAPI controls and a mapping of what Rules are inherited by Customers, both Add-on Customers and SaaS Customers. +Below are mappings of HIPAA Rules to BloomAPI controls and a shared responsibility matrix describing which obligations BloomAPI supports and which obligations remain Customer-owned. ## BloomAPI Organizational Concepts -The physical infrastructure environment is hosted at Google Cloud Platform (GCP). The network components and supporting network infrastructure is contained within GCP infrastructure and managed by GCP. BloomAPI does not have physical access into the network components. The BloomAPI environment consists of firewalls, ElasticSearch, Postgres database servers, Google Cloud Spanner, CockroachDB database servers, Google Cloud Datastore, Google Cloud PubSub, Logstash logging servers, Prometheus logging servers, Linux Ubuntu servers, and developer tool servers running on Linux Ubuntu. +The physical infrastructure environment is hosted in Google Cloud Platform (GCP). Network components and supporting network infrastructure are contained within GCP infrastructure and managed by GCP. BloomAPI does not have physical access to the network components. The BloomAPI environment uses GCP services, Google Cloud Armor, managed and self-managed databases, application servers, logging and monitoring systems, and developer tool systems. Specific systems, third-party subprocessors, and data flows are tracked in BloomAPI's internal asset inventory and third-party inventory. Within the BloomAPI Platform all data transmission is encrypted and all hard drives are encrypted so data at rest is also encrypted; this applies to all servers - databases, APIs, log servers, etc. BloomAPI assumes all data *may* contain ePHI, even though our Risk Assessment does not indicate this is the case, and provides appropriate protections based on that assumption. ## Version Control -Policies were last reviewed and updated May 11th, 2022. +Policies were last reviewed and updated June 2, 2026. diff --git a/key_definitions.md b/key_definitions.md index cc490de..a2a816a 100644 --- a/key_definitions.md +++ b/key_definitions.md @@ -18,7 +18,7 @@ * *Backup Service*: A logging service for unifying system and application logs, encrypting them, and providing a dashboard for them. Offered with all BloomAPI Add-ons and as an option for SaaS Customers. -* *Breach*: Means the acquisition, access, use, or disclosure of protected health information (PHI) in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. For purpose of this definition, "compromises the security or privacy of the PHI" means poses a significant risk of financial, reputational, or other harm to the individual. A use or disclosure of PHI that does not include the identifiers listed at §164.514(e)(2), limited data set, date of birth, and zip code does not compromise the security or privacy of the PHI. Breach excludes: +* *Breach*: Means the acquisition, access, use, or disclosure of protected health information (PHI) in a manner not permitted under the Privacy Rule which compromises the security or privacy of the PHI. An impermissible use or disclosure of PHI is presumed to be a breach unless BloomAPI, a Customer, or another responsible regulated entity demonstrates and documents a low probability that the PHI has been compromised based on the required HIPAA risk assessment factors. Breach excludes: 1. Any unintentional acquisition, access or use of PHI by a workforce member or person acting under the authority of a Covered Entity (CE) or Business Associate (BA) if such acquisition, access, or use was made in good faith and within the scope of authority and does not result in further use or disclosure in a manner not permitted under the Privacy Rule. 2. Any inadvertent disclosure by a person who is authorized to access PHI at a CE or BA to another person authorized to access PHI at the same CE or BA, or organized health care arrangement in which the CE participates, and the information received as a result of such disclosure is not further used or disclosed in a manner not permitted under the Privacy Rule. @@ -79,6 +79,8 @@ * *Partner*: Contractual bound 3rd party vendor with integration with the BloomAPI Platform. May offer Add-on services. +* *Part 2 Records*: Records subject to 42 CFR Part 2 relating to the identity, diagnosis, prognosis, or treatment of a patient with a substance use disorder that are maintained in connection with a federally assisted Part 2 program. BloomAPI treats such records as specially protected when a Customer identifies accounts, data, workflows, or integrations as subject to Part 2. + * *Platform*: The overall technical environment of BloomAPI. * *Protected Health Information (PHI)*: Individually identifiable health information that is created by or received by the organization, including demographic information, that identifies an individual, or provides a reasonable basis to believe the information can be used to identify an individual, and relates to: @@ -111,6 +113,8 @@ * Prioritizes risks; and * Results in recommended possible actions/controls that could reduce or offset the determined risk. +* *SUD Counseling Notes*: Notes recorded by a Part 2 program professional documenting or analyzing the contents of a conversation during a private substance use disorder counseling session or a group, joint, or family counseling session, and that are separated from the rest of the patient's SUD and medical record. SUD counseling notes receive protections similar to psychotherapy notes and require separate authorization unless another legal basis applies. + * *Risk Management*: Within this policy, it refers to two major process components: risk assessment and risk mitigation. This differs from the HIPAA Security Rule, which defines it as a risk mitigation process only. The definition used in this policy is consistent with the one used in documents published by the National Institute of Standards and Technology (NIST). * *Risk Mitigation*: Referred to as Risk Management in the HIPAA Security Rule, and is a process that prioritizes, evaluates, and implements security controls that will reduce or offset the risks determined in the risk assessment process to satisfactory levels within an organization given its mission and available resources. @@ -161,4 +165,3 @@ * *Workforce*: Means employees, volunteers, trainees, and other persons whose conduct, in the performance of work for a covered entity, is under the direct control of such entity, whether or not they are paid by the covered entity. - diff --git a/part_2_sud_records_policy.md b/part_2_sud_records_policy.md new file mode 100644 index 0000000..7534f73 --- /dev/null +++ b/part_2_sud_records_policy.md @@ -0,0 +1,49 @@ +# Part 2 SUD Records Policy + +BloomAPI may create, receive, maintain, or transmit substance use disorder (SUD) patient records for Customers that are Part 2 programs, HIPAA covered entities, business associates, lawful holders, or qualified service organizations. BloomAPI treats Part 2 records as specially protected health information when a Customer identifies data, accounts, workflows, or integrations as subject to 42 CFR Part 2. + +This policy is intended to support the 2024 updates to 42 CFR Part 2, which became effective April 16, 2024 and require compliance by February 16, 2026. Part 2 requirements are handled in addition to HIPAA, HITECH, state privacy laws, and BloomAPI's business associate agreements. + +## Applicable Standards + +* 42 CFR Part 2 - Confidentiality of Substance Use Disorder Patient Records +* 45 CFR Parts 160 and 164 - HIPAA Privacy, Security, Breach Notification, and Enforcement Rules +* HITECH Act breach notification requirements + +## Part 2 SUD Records Policies + +1. Customer identification of Part 2 records: + * Customers are responsible for notifying BloomAPI when their use of BloomAPI services involves Part 2 records. + * BloomAPI will record known Part 2 Customers, environments, integrations, and subprocessors in its compliance inventory. + * Where the status of data is uncertain and the Customer is a Part 2 program or lawful holder, BloomAPI will treat the data as Part 2 records until the Privacy Officer determines otherwise. +2. Permitted uses and disclosures: + * BloomAPI will use and disclose Part 2 records only as permitted by the applicable service agreement, business associate agreement, qualified service organization agreement or equivalent terms, Customer instructions, and applicable law. + * BloomAPI will not use or disclose Part 2 records for civil, criminal, administrative, or legislative proceedings against a patient unless the disclosure is authorized by a valid Part 2-compliant patient consent or court order and reviewed by the Privacy Officer or legal counsel. + * BloomAPI will not use or disclose SUD counseling notes without a separate authorization or other legal basis that specifically permits the use or disclosure. + * BloomAPI will not combine a consent for legal-proceeding use or disclosure of Part 2 records with any other consent. +3. Treatment, payment, and health care operations: + * When a Customer has obtained a valid Part 2 consent for treatment, payment, and health care operations, BloomAPI may support those uses and disclosures in accordance with Customer instructions and applicable agreements. + * Each disclosure made based on patient consent must include a copy of the consent or a clear explanation of the scope of the consent when BloomAPI is responsible for making the disclosure. +4. Redisclosure controls: + * BloomAPI will apply HIPAA minimum necessary principles and Part 2 redisclosure restrictions to Part 2 records. + * Subcontractors and other downstream recipients that create, receive, maintain, or transmit Part 2 records for BloomAPI must agree in writing to restrictions and safeguards at least as protective as those applicable to BloomAPI. + * BloomAPI will maintain records sufficient to identify downstream services and subprocessors that may receive Part 2 records. +5. Public health disclosures: + * BloomAPI may support public health disclosures of Part 2 records only at the Customer's direction or as required by law. + * Any public health disclosure without patient consent must use information de-identified in accordance with HIPAA de-identification standards unless another legal basis is approved by the Privacy Officer or legal counsel. +6. Breach handling: + * A breach of unsecured Part 2 records is handled under the BloomAPI Breach Policy and documented as a Part 2 incident. + * The incident owner must evaluate whether individual, HHS Secretary, media, Customer, or other notices are required under HIPAA, Part 2, contract, and state law. + * Beginning February 16, 2026, Part 2 complaints and breach reports may be investigated under HIPAA Enforcement Rule procedures. +7. Patient notices and Customer support: + * BloomAPI does not publish a Customer's HIPAA Notice of Privacy Practices or Part 2 Patient Notice unless contractually required. + * BloomAPI will support Customer requests for information needed to update notices, including known subprocessors and categories of uses or disclosures performed by BloomAPI. +8. Legal, law enforcement, and oversight requests: + * Requests for Part 2 records from law enforcement, regulators, courts, attorneys, or other legal requestors must be escalated to the Privacy Officer before any disclosure. + * BloomAPI will notify the affected Customer before disclosure unless prohibited by law or court order. + * BloomAPI will disclose only the minimum information required and will document the request, authority, reviewer, information disclosed, and any notice provided to the Customer. +9. Training: + * Workforce HIPAA training must include Part 2 awareness for workforce members who may handle Customer support, operations, security, legal, or compliance work involving SUD treatment Customers. + * Training must cover Part 2 redisclosure limits, legal-proceeding restrictions, SUD counseling notes, breach escalation, and Customer notice obligations. +10. Review: + * The Privacy Officer will review this policy at least annually and when HHS issues new Part 2, HIPAA Privacy Rule, or HIPAA Security Rule requirements affecting BloomAPI. diff --git a/risk_management_policy.md b/risk_management_policy.md index b17a41f..0847f00 100644 --- a/risk_management_policy.md +++ b/risk_management_policy.md @@ -23,6 +23,7 @@ This policy establishes the scope, objectives, and procedures of BloomAPI's info * These changes do not include routine updates to existing systems, deployments of new systems created based on previously configured systems, deployments of new Customers, or new code developed for operations and management of the BloomAPI Platform. 3. While making changes to BloomAPI physical equipment and facilities that introduce new, untested configurations. 4. BloomAPI performs periodic technical and non-technical assessments of the security rule requirements as well as in response to environmental or operational changes affecting the security of ePHI. + 5. BloomAPI performs and documents an enterprise risk analysis at least annually, including review of technology assets, network maps, ePHI data flows, reasonably anticipated threats and vulnerabilities, current safeguards, likelihood, impact, risk level, remediation owner, target remediation date, and residual risk acceptance. 3. BloomAPI implements security measures sufficient to reduce risks and vulnerabilities to a reasonable and appropriate level to: 1. Ensure the confidentiality, integrity, and availability of all ePHI BloomAPI receives, maintains, processes, and/or transmits for its Customers; 2. Protect against any reasonably anticipated threats or hazards to the security or integrity of Customer ePHI; @@ -32,6 +33,7 @@ This policy establishes the scope, objectives, and procedures of BloomAPI's info 5. All BloomAPI workforce members are expected to fully cooperate with all persons charged with doing risk management work, including contractors and audit personnel. Any workforce member that violates this policy will be subject to disciplinary action based on the severity of the violation according to BloomAPI's policies, which is outlined in the BloomAPI Policy Management Policy. 6. The implementation, execution, and maintenance of the information security risk analysis and risk management process is the responsibility of BloomAPI's Security Officer (or other designated employee), and the identified Risk Management Team. 7. All risk management efforts, including decisions made on what controls to put in place as well as those to not put into place, are documented and the documentation is maintained for six years. +8. BloomAPI tracks regulatory changes affecting HIPAA, HITECH, Part 2, and state breach notification laws. Proposed rules, including the 2025 HIPAA Security Rule cybersecurity NPRM, are tracked as readiness items until finalized and assigned a compliance date. ## Process Documentation diff --git a/roles_policy.md b/roles_policy.md index 62d975c..b8aeba0 100644 --- a/roles_policy.md +++ b/roles_policy.md @@ -21,7 +21,7 @@ The Privacy Officer is responsible for assisting with compliance and security tr 3. Manage relationships with customers and partners as those relationships affect security and compliance of ePHI. 4. Assist Security Officer as needed. -The current BloomAPI Privacy Officer is Eric Jain ([ejain@bloomapi.com](mailto:ejain@bloomapi.com)). +The current BloomAPI Privacy Officer is Tyler Brown ([tyler@bloomapi.com](mailto:tyler@bloomapi.com)). ## Workforce Training Responsibilities @@ -62,7 +62,7 @@ The current BloomAPI Privacy Officer is Eric Jain ([ejain@bloomapi.com](mailto:e The Security Officer is responsible for facilitating the training and supervision of all workforce members [164.308(a)(3)(ii)(A) and 164.308(a)(5)(ii)(A)], investigation and sanctioning of any workforce member that is in violation of BloomAPI security policies and non-compliance with the security regulations [164.308(a)(1)(ii)(c)], and writing, implementing, and maintaining all polices, procedures, and documentation related to efforts toward security and compliance [164.316(a-b)]. -The current BloomAPI Security Officer is Eric Jain ([ejain@bloomapi.com](mailto:ejain@bloomapi.com)). +The current BloomAPI Security Officer is Tyler Brown ([tyler@bloomapi.com](mailto:tyler@bloomapi.com)). ## Organizational Responsibilities diff --git a/shared_responsibility_matrix.md b/shared_responsibility_matrix.md new file mode 100644 index 0000000..67bcd20 --- /dev/null +++ b/shared_responsibility_matrix.md @@ -0,0 +1,32 @@ +# BloomText Shared Responsibility Matrix + +## Scope + +BloomText supports Customer compliance obligations by operating and securing the BloomText service. Customers remain responsible for their own legal, clinical, administrative, workforce, and patient-facing obligations. This matrix summarizes the division of responsibility and does not establish a Customer's overall HIPAA or Part 2 compliance by itself. + +Existing signed agreements remain governed by their executed terms unless amended in writing by the parties. + +## Matrix + +| Area | BloomText Responsibility | Customer Responsibility | Evidence/Notes | +| --- | --- | --- | --- | +| Business Associate Agreement | Provide a BloomText BAA when BloomText creates, receives, maintains, or transmits PHI for a Customer. | Execute the BAA before using BloomText for PHI and follow Customer obligations in the agreement. | Executed agreements control over this matrix. | +| Permitted PHI use | Use and disclose PHI only as permitted by the applicable agreement, Customer instructions, and law. | Decide what PHI is entered into BloomText and ensure the use is permitted for treatment, payment, operations, authorization, or another legal basis. | Customer owns clinical and legal basis for its PHI use. | +| Part 2/SUD identification | Support Part 2 safeguards when Customer identifies records, workflows, or integrations as subject to 42 CFR Part 2. | Notify BloomText when Customer is a Part 2 program, lawful holder, or otherwise uses BloomText for Part 2 records. | Part 2 status must be identified during contracting or onboarding. | +| Part 2 record identification/flagging | Maintain known Part 2 Customer/environments in compliance records when identified. | Identify which records, users, workflows, or integrations involve Part 2 records. | BloomText cannot reliably infer Part 2 status from message or record content alone. | +| Patient consent and authorization | Support Customer-configured workflows and protect records processed through BloomText. | Obtain and maintain any patient consent, HIPAA authorization, Part 2 consent, or other permission required for Customer's use of BloomText. | BloomText does not verify each patient consent unless contractually required. | +| NPP and Part 2 patient notices | Provide reasonable information about BloomText services, subprocessors, and safeguards when needed for Customer notices. | Maintain HIPAA Notice of Privacy Practices, Part 2 Patient Notice, and other patient-facing notices required by law. | Patient-facing notices are Customer-owned. | +| Part 2 redisclosure restrictions | Apply documented Part 2 restrictions to known Part 2 records and downstream services where applicable. | Avoid redisclosing Part 2 records except as permitted by consent, agreement, court order, or applicable law. | Redisclosure obligations may apply to both parties depending on role and data flow. | +| Part 2 law-enforcement/court-order review | Escalate legal requests for known Part 2 records to the Privacy Officer before disclosure. | Handle legal requests received directly by Customer and notify BloomText where Customer requires BloomText assistance. | Part 2 records may not be used in proceedings against a patient unless Part 2 requirements are satisfied. | +| SUD counseling notes | Protect known SUD counseling notes as specially protected information when Customer identifies them. | Identify SUD counseling notes and obtain separate authorization or other legal basis where required. | BloomText does not determine whether content is a SUD counseling note unless Customer identifies it. | +| Customer user provisioning/offboarding | Provide account, authentication, and access-control functionality for the BloomText service. | Create, approve, review, and remove Customer users and roles; promptly disable access when workforce members leave or change roles. | Shared controls depend on product configuration and Customer administration. | +| Customer workforce training | Provide product/security information as appropriate. | Train Customer workforce on HIPAA, Part 2, acceptable use, patient communication, and Customer policies. | Workforce training is Customer-owned. | +| Infrastructure security | Secure BloomText-controlled production infrastructure, hosting, network protections, and platform operations. | Secure Customer-managed devices, networks, accounts, browsers, endpoint security, and local workflows. | BloomText infrastructure is hosted in GCP using approved configurations. | +| Encryption | Encrypt BloomText-controlled transmission and storage where applicable. | Avoid exporting PHI/Part 2 records to insecure or unapproved tools and protect data outside BloomText. | Customer controls downstream exports and local copies. | +| Audit logging | Maintain audit and security event logging appropriate to the BloomText service and review log coverage periodically. | Review Customer-user activity where available and report suspicious activity to BloomText. | Specific log sources and retention depend on service configuration and verified retention settings. | +| Breach response | Investigate BloomText incidents, perform risk assessment, notify Customers under applicable BAAs, and support Customer notice obligations with available information. | Notify individuals, HHS, media, regulators, or others where Customer is responsible unless delegated by agreement. | Timelines are governed by signed agreements and applicable law. | +| Subprocessors | Review and maintain subprocessors that may create, receive, maintain, or transmit PHI or Part 2 records for BloomText. | Review BloomText subprocessor information where required by Customer's own compliance program. | See [Subprocessors](subprocessors.md). | +| Data retention/deletion | Apply BloomText retention, backup, deletion, and legal hold procedures for BloomText-controlled systems. | Download, export, retain, or delete Customer data as needed for Customer's legal and clinical obligations. | Backup and log deletion may follow separate retention cycles. | +| Legal/law-enforcement requests | Review legal requests received by BloomText and notify Customer where permitted. | Handle legal requests received directly by Customer and provide lawful instructions to BloomText when assistance is needed. | Part 2 and specially protected data require heightened review. | +| Customer devices and networks | Provide secure service endpoints and platform controls. | Secure endpoints, mobile devices, workstations, local networks, passwords, MFA factors, and browser sessions. | BloomText does not manage Customer endpoint security unless separately agreed. | +| Approved tools and data export | Maintain BloomText internal approved-tool restrictions for regulated Customer data. | Do not copy PHI, Part 2 records, patient identifiers, message bodies, or clinical content into unapproved third-party tools outside BloomText. | Customer controls its own external tools and exports. | diff --git a/subprocessors.md b/subprocessors.md new file mode 100644 index 0000000..7b65227 --- /dev/null +++ b/subprocessors.md @@ -0,0 +1,30 @@ +# Subprocessors + +BloomAPI reviews third-party services before they are permitted to create, receive, maintain, or transmit PHI or Part 2 records for BloomAPI. This document summarizes current subprocessor status for compliance review. It does not amend any signed agreement. + +## Subprocessor Review Policy + +1. New subprocessors must be reviewed before use with PHI or Part 2 records. +2. Review must consider data categories, PHI/Part 2 exposure, agreement status, security controls, retention, breach notice commitments, hosting location, and whether the service is an external recipient. +3. Services that are not authorized for PHI or Part 2 records may not intentionally receive PHI, Part 2 records, patient identifiers, message bodies, patient names, clinical content, or other regulated Customer data. +4. Existing signed agreements remain governed by their executed terms unless amended in writing by the parties. + +## Current Subprocessors and Related Services + +| Service | Purpose | Data Processed | PHI/Part 2 Status | Agreement Status | External Recipient? | Underlying Provider | Hosting/Region | Notes | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | +| Google Cloud Platform / Google Cloud Armor | Primary infrastructure, hosting, network security, and HTTP/WAF traffic protection | Production infrastructure data, network/security logs, and Customer data processed by covered services | Approved/eligible for PHI only for covered GCP services under BloomAPI's executed Google Cloud BAA and approved configuration; Part 2 use depends on Customer identification and approved configuration | Verify current BAA and covered services list | Yes | Google Cloud | us-central1 (US) | Region confirmed; details should be tracked in BloomAPI's asset inventory and third-party inventory. | +| Twilio | SMS delivery and messaging services | Patient phone numbers and SMS delivery metadata; message content where used by Customer workflows | Authorized for PHI identifiers and related messaging data under approved configuration; Part 2 use depends on Customer identification and approved configuration | BAA signed - attach/verify in BAA register | Yes | Twilio | To verify | Limit data sent to Twilio to what is necessary for messaging delivery and related operations. | +| SendGrid (Twilio) | Email delivery | Patient email addresses and email delivery metadata; email content where used by Customer workflows | Authorized for PHI identifiers and related email delivery data under approved configuration; Part 2 use depends on Customer identification and approved configuration | BAA signed - attach/verify in BAA register | Yes | Twilio / SendGrid | To verify | Limit data sent to SendGrid to what is necessary for email delivery and related operations. | +| Elastic Cloud | Search infrastructure | Search index data, which may contain message content, identifiers, and operational metadata | Authorized for PHI under approved configuration; Part 2 use depends on Customer identification and approved configuration | BAA signed - attach/verify in BAA register | Yes | Elastic | To verify | Search index contents must be protected as regulated Customer data when they include PHI, identifiers, message content, or Part 2 records. | +| Talkbox | Video service; currently inactive | Video session data and related identifiers if used | Authorized if used under approved configuration; Part 2 use depends on Customer identification and approved configuration | BAA signed - attach/verify in BAA register | Yes | Talkbox | To verify | Currently inactive. Re-review configuration, data flows, and agreement status before renewed production use. | +| Sentry | Error monitoring and application diagnostics | Error events, stack traces, metadata, and possible identifiers depending on configuration | Not authorized for PHI/Part 2 pending contract and technical scrubbing review | Verify BAA/DPA and configuration | Yes | Sentry | To verify | No PHI or Part 2 records should reach Sentry by design. Workforce and product telemetry must not intentionally send identifiers, message bodies, patient names, clinical content, or other regulated Customer data to Sentry until approval is documented. | +| PostHog | Product analytics | Product usage events and possible user/account metadata depending on configuration | Not authorized for PHI/Part 2 pending contract and technical routing review | Verify BAA/DPA and configuration | Yes | PostHog | To verify | No PHI or Part 2 records should reach PostHog by design. Product analytics must not intentionally include patient identifiers, message bodies, patient names, clinical content, or other regulated Customer data until approval is documented. | +| Grafana | Monitoring dashboards and alerts | Metrics, operational alerts, and observability data | Self-hosted monitoring; PHI/Part 2 status depends on what metrics, logs, labels, and alert destinations contain | Self-hosted; verify any external alert delivery channels | No, if fully self-hosted; verify alert destinations | GCP or other hosting provider to verify | To verify | Grafana itself is not an external subprocessor if self-hosted, but alert delivery channels, authentication providers, and notification destinations may be subprocessors. | + +## Review TODOs + +* Maintain a BAA register for GCP, Twilio, SendGrid, Elastic Cloud, Talkbox, and any other service authorized to create, receive, maintain, or transmit PHI or Part 2 records. The register should include agreement location, signing date, renewal or review date, covered services, and owner. +* Confirm Cloud Armor, GCP Cloud Audit Logs, and Sentry log/event retention periods. +* Confirm Sentry DPA/BAA status, data residency, event retention, scrubbing rules, allowed fields, and continued technical controls preventing PHI or Part 2 records from reaching Sentry. +* Review this document at least annually and after any material vendor, data-flow, or configuration change. diff --git a/systems_access_policy.md b/systems_access_policy.md index 9fc6a1a..d7ec2ef 100644 --- a/systems_access_policy.md +++ b/systems_access_policy.md @@ -36,10 +36,11 @@ Access to BloomAPI systems and application is limited for all users, including b * The request for access is retained for future reference. * All access to BloomAPI systems and services are reviewed and updated on an annual basis to assure proper authorizations are in place commiserate with job functions. * Any BloomAPI workforce member can request change of access by emailing the Security Officer. -* Access to systems is controlled using centralized user management and authentication. All authentication requests utilize two-factor authentication where supported. +* Access to systems is controlled using centralized user management and authentication. All workforce access to production systems, administrative systems, source code systems, cloud consoles, and systems that create, receive, maintain, or transmit ePHI requires multi-factor authentication unless the Security Officer documents a temporary exception and compensating controls. * Temporary accounts are not used unless absolutely necessary for business purposes. * In the case of non-personal information, such as generic educational content, identification and authentication may not be required. * Privileged users must first access systems using standard, unique user accounts before switching to privileged users and performing privileged tasks. +* Privileged access is granted only when required for a defined role or task, reviewed at least quarterly, and removed when it is no longer required. * All application to application communication using service accounts is restricted and not permitted unless absolutely needed. Automated tools are used to limit account access across applications and systems. * Generic accounts are not allowed on BloomAPI systems. * In cases of increased risk or known attempted unauthorized access, immediate steps are taken by the Security and Privacy Officer to limit access and reduce risk of unauthorized access. @@ -95,6 +96,7 @@ Access to BloomAPI systems and application is limited for all users, including b * An unauthorized individual is utilizing a user's User Login ID and password (a new password may be provided to the user if the user is not identified as providing the unauthorized individual with the User Login ID and password). * The Security Officer will terminate users' access rights immediately upon notification. * The Security Officer audits and may terminate access of users that have not logged into organization's information systems/applications for an extended period of time. +* Access to production systems and systems containing ePHI is reviewed at least quarterly. All other workforce access is reviewed at least annually. ## Paper Records @@ -108,3 +110,4 @@ BloomAPI does not use paper records for any sensitive information. Use of paper * All default system, application, and Partner passwords are changed before deployment to production. * All passwords used in configuration scripts are secured and encrypted. * If a user believes their user ID has been compromised, they are required to immediately report the incident to the Security Office. +* Password-only authentication may not be used for systems that create, receive, maintain, or transmit ePHI unless the Security Officer documents why multi-factor authentication is not feasible and approves compensating controls. diff --git a/tmp/done-plans/2026-06-02-immediate-hipaa-policy-cleanup.md b/tmp/done-plans/2026-06-02-immediate-hipaa-policy-cleanup.md new file mode 100644 index 0000000..af8eb5b --- /dev/null +++ b/tmp/done-plans/2026-06-02-immediate-hipaa-policy-cleanup.md @@ -0,0 +1,381 @@ +## Goal + +Implement the immediate HIPAA policy cleanup decisions: + +- Standardize BloomAPI/BloomText customer-facing BAA breach and security incident customer notice timelines to 10 business days. +- Preserve stricter downstream/subcontractor notice timelines unless counsel explicitly approves matching downstream and customer-facing timelines. +- Replace the stale HIPAA inheritance table with a practical shared responsibility matrix. +- Add a subprocessor policy/listing document covering GCP, Sentry, PostHog, and self-hosted Grafana at a level that does not overstate PHI/Part 2 readiness. +- Update audit logging and retention policy language to reflect current reality and capture retention TODOs that must be verified. +- Keep infrastructure language non-brittle and aligned with current GCP/Cloud Armor usage. + +## Why + +- Current BAA templates conflict: 4 hours, 3 business days, 5 business days, 10 business days, and the attached signed sample BAA says 30 calendar days. +- Customers need a clear shared responsibility model so BloomText does not imply customers inherit full HIPAA/Part 2 compliance. +- The policies should describe what BloomText actually logs today: Cloud Armor HTTP/WAF traffic, machine logs, login/access activity data, Grafana alerts, Sentry alerts, and related incident records. +- Subprocessors like Sentry and PostHog need explicit review status because PHI exposure depends on configuration and scrubbing. + +## What + +The repository will contain draft policy updates prepared for counsel review and operational verification. The plan does not require changing runtime systems. It updates documentation to match current intent, avoids unsupported compliance claims, and flags operational checks as TODOs where facts are not yet known. + +### Success Criteria + +- [x] Customer-facing BAA templates use 10 business days for Breach of Unsecured PHI, successful Security Incidents, and impermissible non-breach PHI uses/disclosures unless counsel later chooses a different distinction. +- [x] Downstream/subcontractor BAA templates either preserve stricter notice timelines or explicitly document the accepted operational risk of matching the customer-facing 10 business day deadline. +- [x] The markdown BAA typo “no less than fourteen business days” is removed. +- [x] `breach_policy.md` no longer promises 4-hour customer notice unless the business deliberately keeps that as an internal target. +- [x] `hipaa_inheritance.md` is replaced with `shared_responsibility_matrix.md`. +- [x] A subprocessor document exists and is linked from `README.md` and `3rd_party_policy.md`. +- [x] `auditing_policy.md` lists current log sources and separates current controls from retention TODOs. +- [x] `data_retention_policy.md` includes retention-check TODOs instead of unsupported retention claims. +- [x] Existing signed agreements disclaimer is present where readers could otherwise think repository updates amend executed contracts. +- [x] A no-overclaim scan has been run and each match is removed, softened, or justified. +- [x] `git diff --check` passes. +- [x] Local markdown links resolve. + +## All Needed Context + +### Documentation & References + +```yaml +- url: https://www.hhs.gov/hipaa/for-professionals/breach-notification/index.html + why: HIPAA breach notification baseline; BA notice is without unreasonable delay and no later than 60 days, but contracts can set shorter timelines. + +- url: https://www.hhs.gov/ocr/privacy/hipaa/understanding/coveredentities/contractprov.html + why: HHS sample BAA provisions and required BA contract topics. + +- url: https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html + why: Audit protocol categories for audit controls, information system activity review, and documentation evidence. + +- url: https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/fact-sheet-42-cfr-part-2-final-rule/index.html + why: Part 2 final rule effective/compliance dates and HIPAA alignment. + +- url: https://www.ftc.gov/node/78112 + why: FTC Health Breach Notification Rule amendments effective July 29, 2024. + +- file: baa_covered_entity.txt + why: Existing customer-facing BAA template currently uses 10 business days. + +- file: baa_downstream.txt + why: Existing downstream BAA currently uses 3/5 business day reporting windows. + +- file: bloomapi_hipaa_business_associate_agreement.md + why: Existing markdown BAA currently uses 4 hours and has an incorrect security incident sentence. + +- file: breach_policy.md + why: Internal breach policy currently says customer notice within 4 hours. + +- file: shared_responsibility_matrix.md + why: Replaces the former HIPAA inheritance table with a shared responsibility matrix. + +- file: auditing_policy.md + why: Needs current log sources and retention TODOs. + +- file: data_retention_policy.md + why: Needs retention-confirmation TODOs. + +- file: introduction.md + why: Already updated to non-brittle GCP/Cloud Armor infrastructure wording; verify it remains aligned. +``` + +### Files Being Changed + +``` +README.md ← MODIFIED +introduction.md ← MODIFIED +baa_covered_entity.txt ← MODIFIED +baa_downstream.txt ← MODIFIED +bloomapi_hipaa_business_associate_agreement.md ← MODIFIED +breach_policy.md ← MODIFIED +shared_responsibility_matrix.md ← NEW +3rd_party_policy.md ← MODIFIED +auditing_policy.md ← MODIFIED +data_retention_policy.md ← MODIFIED +subprocessors.md ← NEW +``` + +### Known Gotchas + +```text +CRITICAL: Do not claim Sentry or PostHog are approved for PHI unless BloomAPI has verified configuration, scrubbing, and BAA/DPA status. + +CRITICAL: Do not use "HIPAA inheritance" language in a way that implies customers become HIPAA compliant by using BloomText. Use "shared responsibility" framing. + +CRITICAL: BAA timelines are contractual commitments. Existing signed agreements with different timelines remain binding unless amended. + +CRITICAL: HIPAA permits up to 60 days for BA breach notice, but customer BAAs can require a shorter timeline. This plan uses the user's selected 10 business day default. + +CRITICAL: Do not treat "successful Security Incident," "Breach of Unsecured PHI," and "impermissible non-breach use/disclosure" as interchangeable. Preserve separate definitions and align only the deadlines selected in this plan. + +CRITICAL: For Breaches, use "after discovery" and keep discovery consistent with the breach policy. For impermissible non-breach uses/disclosures and successful Security Incidents, use "after BloomAPI becomes aware" unless counsel instructs otherwise. +``` + +## Implementation Blueprint + +### Architecture Overview + +This is a documentation-only cleanup. The immediate implementation should make the policy repository internally consistent and attorney-review-ready by aligning BAA timelines, replacing an overbroad inheritance table with shared responsibility language, and documenting current audit/subprocessor facts without overstating unverified controls. + +### Key Pseudocode + +```text +For each BAA/policy file: + locate Breach/Security Incident reporting language + replace customer-facing Breach notice window with "as soon as practicable, but no later than ten (10) business days after discovery" + replace customer-facing successful Security Incident and impermissible non-breach use/disclosure windows with "as soon as practicable, but no later than ten (10) business days after BloomAPI becomes aware" + preserve stricter downstream/subcontractor windows unless counsel approves matching 10 business days + preserve blanket notice language for unsuccessful Security Incidents + preserve "supplemental information as available" concept + +For shared responsibility matrix: + replace "Inherited: Yes/No/Partially" with: + Area | BloomText Responsibility | Customer Responsibility | Evidence/Notes + include HIPAA, Part 2, breach response, user management, audit logging, subprocessors, retention/deletion, legal requests + +For subprocessors: + create table with status labels: + Approved/eligible for PHI under verified agreement and approved configuration + Not approved for PHI + Not approved for PHI/Part 2 pending review + mark GCP as primary infrastructure eligible only for covered GCP services under BloomAPI's executed Google Cloud BAA and approved configuration + mark Sentry/PostHog as not approved for PHI/Part 2 pending review + treat self-hosted Grafana separately from external subprocessors and document any external alert recipients or underlying providers +``` + +### Data Models and Structure + +No runtime data models. The new subprocessor document should use this markdown structure: + +```markdown +# Subprocessors + +## Subprocessor Review Policy + +## Current Subprocessors + +| Subprocessor | Service | Data Processed | PHI/Part 2 Status | Agreement Status | Hosting/Region | Notes | +| --- | --- | --- | --- | --- | --- | --- | + +## Review TODOs +``` + +The shared responsibility matrix should use this markdown structure: + +```markdown +# BloomText Shared Responsibility Matrix + +## Scope + +## Matrix + +| Area | BloomText Responsibility | Customer Responsibility | Evidence/Notes | +| --- | --- | --- | --- | +``` + +### Tasks + +```yaml +Task 0: +PRE-EDIT INVENTORY: + - Run: + `rg -n "Breach|Security Incident|impermissible|improper|notice|notification|subprocessor|retention|audit" *.md *.txt` + - Review every affected clause before editing. + - Pay attention to incident_response_policy.md, part_2_sud_records_policy.md, approved_tools_policy.md, and hipaa_mapping_to_bloomapi_controls.md even if the main edits are elsewhere. + +Task 1: +MODIFY introduction.md: + - VERIFY line 17 remains non-brittle and does not list obsolete technologies such as CockroachDB. + - KEEP GCP, Google Cloud Armor, managed/self-managed databases, application servers, logging/monitoring, developer systems. + - KEEP reviewed date as June 2, 2026. + +Task 2: +MODIFY baa_covered_entity.txt: + - CONFIRM breach, impermissible use/disclosure, and successful Security Incident notice use "no later than ten (10) business days". + - USE "after discovery" for Breach notice. + - USE "after BloomAPI becomes aware" for impermissible non-breach uses/disclosures and successful Security Incidents. + - ADD supplemental notice language if missing: + "Business Associate will supplement the notice as additional information becomes available." + - PRESERVE unsuccessful Security Incident blanket notice. + - ADD a short disclaimer: + "Existing signed agreements remain governed by their executed terms unless amended." + +Task 3: +MODIFY baa_downstream.txt: + - PRESERVE downstream reporting as stricter than customer-facing reporting unless counsel explicitly approves otherwise. + - Recommended default: keep Breach reporting at three (3) business days and improper disclosure/successful Security Incident reporting at five (5) business days so BloomAPI has buffer to meet the 10 business day customer-facing deadline. + - If counsel directs downstream timelines to match the 10 business day customer-facing default, document that BloomAPI accepts the operational risk. + - ADD supplemental notice language if missing. + +Task 4: +MODIFY bloomapi_hipaa_business_associate_agreement.md: + - FIX "on no less than fourteen business (14) days" to "without unreasonable delay and no later than ten (10) business days". + - CHANGE breach reporting from four (4) hours to ten (10) business days. + - USE "after discovery" for Breach notice. + - USE "after BloomAPI becomes aware" for successful Security Incidents. + - ADD supplemental notice language. + - PRESERVE statement that unsuccessful Security Incidents are deemed noticed by the BAA. + - ADD existing signed agreement disclaimer. + +Task 5: +MODIFY breach_policy.md: + - CHANGE customer breach notice from "no later than 4 hours" to "without unreasonable delay and no later than ten (10) business days". + - OPTIONAL: keep an internal target sentence: + "BloomAPI attempts to provide an initial operational heads-up sooner when practical, but the contractual notice deadline is governed by the applicable BAA." + - Ensure Part 2 breach handling remains. + +Task 6: +REWRITE shared_responsibility_matrix.md: + - RENAME heading to "BloomText Shared Responsibility Matrix". + - Replace inherited yes/no table with: + Area | BloomText Responsibility | Customer Responsibility | Evidence/Notes. + - INCLUDE rows: + BAA + Permitted PHI use + Part 2/SUD identification + Patient consent and authorization + NPP/Part 2 patient notices + Customer user provisioning/offboarding + Customer workforce training + Infrastructure security + Encryption + Audit logging + Breach response + Subprocessors + Data retention/deletion + Legal/law-enforcement requests + Customer devices/networks + Approved tools/data export + Part 2 record identification/flagging + Part 2 redisclosure restrictions + Part 2 law-enforcement/court-order review + SUD counseling notes if applicable + - USE "BloomText supports" where the customer owns the legal/clinical decision. + - AVOID "inherits full compliance" framing. + +Task 7: +CREATE subprocessors.md: + - Add review policy and current subprocessor table. + - Include: + Google Cloud Platform / Google Cloud Armor: primary infrastructure, approved/eligible for PHI only for covered GCP services under BloomAPI's executed Google Cloud BAA and approved configuration; details tracked in asset inventory. + Sentry: error monitoring, not approved for PHI/Part 2 pending contract and technical scrubbing review. + PostHog: analytics, not approved for PHI/Part 2 pending contract and technical routing review. + Grafana: self-hosted monitoring; not itself an external subprocessor if truly self-hosted, but document external alert recipients and underlying provider. + - Add TODOs to verify BAA/DPA, PHI scrubbing, regions, and data categories. + - Add explicit rule that workforce and product telemetry must not intentionally send PHI, Part 2 records, identifiers, message bodies, patient names, or clinical content to Sentry/PostHog until approval is documented. + - Include columns for "External recipient?" and "Underlying provider". + +Task 8: +MODIFY README.md: + - Link shared responsibility matrix with current filename `shared_responsibility_matrix.md`. + - Add Subprocessors link. + - Avoid adding "HIPAA compliant" or "Part 2 compliant" claims. Prefer "supports customer compliance obligations" and "shared responsibility". + +Task 9: +MODIFY 3rd_party_policy.md: + - Link to subprocessors.md. + - Add requirement that new subprocessors must be reviewed for PHI/Part 2 exposure, BAA/DPA status, data categories, retention, and breach notice commitments before use. + - State unapproved tools may not receive PHI/Part 2 records. + +Task 10: +MODIFY auditing_policy.md: + - Rewrite broad promises like "BloomAPI shall log all incoming and outgoing traffic" into current capability statements where appropriate. + - Add "Current Audit and Security Event Sources" section listing: + Google Cloud Armor HTTP/WAF logs + server/machine logs + customer account login/access events where available + database last-activity records + Grafana alerts + Sentry alerts/errors + incident tickets/investigation notes + - Add "Recommended Audit Log Gaps/TODOs" section: + confirm GCP Cloud Audit Logs for IAM/admin/config changes + confirm explicit login history vs last activity only + confirm support/admin customer-account access logs + confirm failed login/MFA event logging + confirm production deploy/change logs + - Clean encoding artifact "45 CFR ¬ß" to "45 CFR §". + - Fix confusing retention numbering in current policy. + - Keep raw operational log retention separate from legal/compliance records. Do not collapse the six-year breach investigation retention requirement into all raw logs. + +Task 11: +MODIFY data_retention_policy.md: + - Add "Retention Verification TODOs" section: + Cloud Armor retention/export + server machine log retention + Grafana alert retention + Sentry event retention + login history retention + GCP Cloud Audit Logs retention/export + database backup retention + PostHog data retention and PHI exposure + - Do not set final numbers unless verified. + +Task 12: +VALIDATE: + - Run `git diff --check`. + - Run markdown link check: + `ruby -e 'Dir["*.md"].each { |f| File.read(f).scan(/\[[^\]]+\]\(([^)]+)\)/).flatten.each { |link| next if link.start_with?("http", "#", "mailto:"); path = link.split(":").first; puts "#{f}: missing #{link}" unless File.exist?(path) } }'` + - Run targeted stale phrase scan and review expected downstream/access-request matches manually: + `rg -n "4 hours|four \\(4\\)|no less than fourteen|CockroachDB|45 CFR ¬ß|201_|three \\(3\\) business|five \\(5\\) business" *.md *.txt` + - Run no-overclaim scan and remove, soften, or justify each match: + `rg -n "approved for PHI|HIPAA compliant|Part 2 compliant|inherit|inherits|certified|guarantee|all audit logs|all traffic|maximum retention|readily accessible" *.md *.txt` + - Manually verify README links, 3rd_party_policy.md link to subprocessors.md, and no old display text says "HIPAA Inheritance for BloomText Customers". +``` + +### Integration Points + +```yaml +POLICY_INDEX: + - README.md must link subprocessors.md and the shared responsibility matrix. + +BAA_CONTRACTS: + - Existing signed customer agreements remain authoritative. + - This plan standardizes repo templates for future outbound agreements. + - Customer-facing templates use 10 business days. + - Downstream templates remain stricter unless counsel approves otherwise. + +THIRD_PARTY_REVIEW: + - subprocessors.md becomes the table referenced by 3rd_party_policy.md. +``` + +## Validation Loop + +```bash +git diff --check +ruby -e 'Dir["*.md"].each { |f| File.read(f).scan(/\[[^\]]+\]\(([^)]+)\)/).flatten.each { |link| next if link.start_with?("http", "#", "mailto:"); path = link.split(":").first; puts "#{f}: missing #{link}" unless File.exist?(path) } }' +rg -n "4 hours|four \\(4\\)|no less than fourteen|CockroachDB|45 CFR ¬ß|201_|three \\(3\\) business|five \\(5\\) business" *.md *.txt +rg -n "approved for PHI|HIPAA compliant|Part 2 compliant|inherit|inherits|certified|guarantee|all audit logs|all traffic|maximum retention|readily accessible" *.md *.txt +``` + +## Final Validation Checklist + +- [ ] Customer-facing BAA notice windows are intentionally 10 business days. +- [ ] Downstream/subcontractor windows are intentionally stricter or counsel-approved to match. +- [ ] `breach_policy.md` aligns with BAA timeline. +- [ ] Shared responsibility matrix does not overstate customer inheritance. +- [ ] Subprocessor table clearly marks TBD/unapproved PHI status. +- [ ] Audit policy reflects current actual log sources. +- [ ] Retention TODOs are visible and not represented as completed controls. +- [ ] `git diff --check` passes. +- [ ] Markdown link check passes. + +## Anti-Patterns to Avoid + +- Do not represent TBD vendors as approved for PHI. +- Do not promise faster notice than operations can support. +- Do not remove downstream notice buffer accidentally. +- Do not hide customer-owned compliance responsibilities under "inherited" language. +- Do not add final retention numbers without verifying actual platform settings. + +## Deprecated Code / Docs To Remove + +- Remove obsolete CockroachDB mention from policy text if any remains. +- Remove `4 hours` customer breach deadline unless retained as non-contractual internal target. +- Remove old `45 CFR ¬ß` encoding artifacts. +- Remove legacy "inheritance" framing that implies customers fully inherit HIPAA compliance. + +## Confidence Score + +9/10. The implementation is documentation-only and the user's decisions are clear. Remaining risk is legal preference around whether downstream subprocessors should report faster than BloomAPI reports to customers. diff --git a/tmp/ready-plans/2026-06-02-future-hipaa-program-expansion.md b/tmp/ready-plans/2026-06-02-future-hipaa-program-expansion.md new file mode 100644 index 0000000..5a3dbca --- /dev/null +++ b/tmp/ready-plans/2026-06-02-future-hipaa-program-expansion.md @@ -0,0 +1,390 @@ +## Goal + +Create the future implementation plan for strengthening BloomAPI/BloomText's HIPAA, Part 2, audit, retention, and vendor compliance program after the immediate documentation cleanup is implemented. + +This future plan should not add aspirational claims to customer-facing policies until the operational controls are confirmed or implemented. + +## Why + +- The immediate policy cleanup will make the repository internally consistent, but several controls require operational confirmation before policies should claim them. +- HIPAA, Part 2, customer BAAs, and vendor management expectations require evidence: inventories, access reviews, logs, incident records, vendor agreements, and retention records. +- A future plan lets BloomAPI build the evidence program before adding stronger public or customer-facing claims. + +## What + +Implement an evidence-backed compliance expansion across six areas: + +1. Operational audit logging and retention. +2. Subprocessor/vendor review and PHI/Part 2 approval status. +3. Customer onboarding classification for HIPAA and Part 2. +4. Access review and administrative activity logging. +5. Incident and breach evidence records. +6. Customer-facing compliance artifacts. + +### Success Criteria + +- [ ] BloomAPI has a verified log inventory with owner, source, retention, export/archive status, PHI exposure, and incident-use value. +- [ ] Subprocessors have verified BAA/DPA status, data categories, PHI/Part 2 approval status, and retention/security posture. +- [ ] Customer onboarding captures whether HIPAA, Part 2, SUD counseling notes, or other specially protected data is involved. +- [ ] Administrative/support access to customer accounts is logged or a gap is formally tracked. +- [ ] GCP Cloud Audit Logs/IAM/admin/config logs are confirmed and exported if needed. +- [ ] Retention tiers are approved by leadership/counsel and reflected in policy only after implementation. +- [ ] Customer-facing compliance docs are updated only after evidence exists. + +## All Needed Context + +### Documentation & References + +```yaml +- url: https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html + why: HIPAA Security Rule administrative, physical, and technical safeguard context. + +- url: https://www.hhs.gov/hipaa/for-professionals/compliance-enforcement/audit/protocol/index.html + why: HHS audit protocol for evidence expectations. + +- url: https://www.hhs.gov/hipaa/for-professionals/security/hipaa-security-rule-nprm/factsheet + why: Proposed Security Rule cybersecurity readiness items; treat as readiness, not final law. + +- url: https://www.hhs.gov/hipaa/for-professionals/regulatory-initiatives/fact-sheet-42-cfr-part-2-final-rule/index.html + why: Part 2 final rule requirements and February 16, 2026 compliance date. + +- file: tmp/done-plans/2026-06-02-immediate-hipaa-policy-cleanup.md + why: This future plan assumes the immediate cleanup has been implemented first. + +- file: auditing_policy.md + why: Will be updated after log inventory is verified. + +- file: data_retention_policy.md + why: Will receive final retention tiers after operational verification. + +- file: 3rd_party_policy.md + why: Will be updated after subprocessor review is completed. + +- file: part_2_sud_records_policy.md + why: Will be updated after onboarding/customer classification process is implemented. + +- file: shared_responsibility_matrix.md + why: Shared responsibility matrix may get evidence links after controls are verified. +``` + +### Files Being Changed + +``` +.context/compliance/log-inventory.md ← NEW +.context/compliance/subprocessor-review.md ← NEW +.context/compliance/customer-onboarding-check.md ← NEW +.context/compliance/access-review-template.md ← NEW +.context/compliance/incident-evidence-template.md← NEW +.context/compliance/policy-claim-register.md ← NEW +auditing_policy.md ← MODIFIED +data_retention_policy.md ← MODIFIED +3rd_party_policy.md ← MODIFIED +part_2_sud_records_policy.md ← MODIFIED +systems_access_policy.md ← MODIFIED +policy_management_policy.md ← MODIFIED +subprocessors.md ← MODIFIED +shared_responsibility_matrix.md ← MODIFIED +``` + +### File Classification + +| File | Classification | Unverified facts allowed? | Notes | +| --- | --- | --- | --- | +| `.context/compliance/*.md` | Internal evidence | Yes | May contain `Needs verification`, artifact locations, reviewer notes, and internal gaps. | +| `policy_management_policy.md` | Internal/customer-visible policy | No | Add governance rule before publishing stronger claims. | +| `auditing_policy.md` | Internal/customer-visible policy | No | Only verified log sources, neutral capability statements, and approved limitations. | +| `data_retention_policy.md` | Internal/customer-visible policy | No | Final retention numbers only after operational verification and approval. | +| `subprocessors.md` | Customer-facing summary | Limited | May say `Not approved for PHI/Part 2 pending review`; must not expose contracts, sensitive configs, or unsupported approvals. | +| `shared_responsibility_matrix.md` | Customer-facing shared responsibility matrix | No | High-level customer-safe responsibilities only; no internal evidence paths. | +| `part_2_sud_records_policy.md` | Internal/customer-visible policy | No | Treat Part 2 compliance as current-state requirement as of February 16, 2026. | +| `systems_access_policy.md` | Internal/customer-visible policy | No | Only verified access review and admin logging practices. | + +### Known Gotchas + +```text +CRITICAL: Do not update public/customer-facing policies to say a control exists until the control is actually implemented or verified. + +CRITICAL: PostHog and Sentry may be unacceptable for PHI depending on configuration and agreement status. Treat them as "not approved for PHI" until verified. + +CRITICAL: GCP Cloud Audit Logs are not the same as application/user activity logs. Both may be needed for investigations. + +CRITICAL: A database field containing "last activity" is not a complete login audit trail. + +CRITICAL: Future Security Rule NPRM items are readiness controls unless finalized by HHS with a compliance date. + +CRITICAL: `.context/compliance/*` may contain unverified facts. Customer-facing or mixed policy files may contain only verified controls, approved limitations, or neutral statements. + +CRITICAL: Do not let internal evidence paths, ticket IDs, screenshots, vendor contract details, sensitive log locations, or known gaps leak into customer-facing files. + +CRITICAL: Treat the Part 2 compliance date as current-state. Compliance was required by February 16, 2026; this plan is not future readiness for Part 2. +``` + +## Implementation Blueprint + +### Architecture Overview + +The future implementation builds an evidence layer around the policies. First create internal inventories/templates in `.context/compliance/` so the team can collect facts without prematurely changing customer-facing claims. After each operational control is verified, update the corresponding policy with specific retention, review cadence, owner, and evidence references. + +### Key Pseudocode + +```text +Phase A: Evidence collection + create internal templates + fill in current facts from engineering/compliance + mark each item: Verified / Needs Work / Not Approved for PHI / Not Applicable + Verified requires: source, date verified, verifier, artifact location, next review, and scope + +Phase B: Control implementation + for each Needs Work item: + assign owner + implement operational control or document compensating control + record evidence location and review cadence + +Phase C: Policy update + only after verification: + update public/internal policy with exact control + add retention periods + add owner and cadence + add exception process + Security Officer, Privacy Officer, and counsel/leadership approve customer-facing claims where relevant +``` + +### Data Models and Structure + +Internal inventory files should be markdown tables: + +```markdown +| Control/Source | Owner | Current State | PHI/Part 2 Exposure | Retention | Evidence Location | Status | Next Action | +| --- | --- | --- | --- | --- | --- | --- | --- | +``` + +Subprocessor review should use: + +```markdown +| Vendor | Service | Data Categories | PHI Allowed | Part 2 Allowed | BAA/DPA | Retention | Region | Status | Owner | Next Review | +| --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | +``` + +Customer onboarding classification should use: + +```markdown +| Question | Required? | Owner | Notes | +| --- | --- | --- | --- | +| Will customer use BloomText for PHI? | Yes | Sales/Compliance | Required before BAA | +| Is customer a Part 2 program or lawful holder? | Yes | Sales/Compliance | Required for SUD treatment customers | +| Will SUD counseling notes be stored/transmitted? | Yes | Customer/Compliance | Requires special handling | +``` + +Policy claim register should use: + +```markdown +| Policy Claim | Customer-Facing File | Required Evidence | Evidence Status | Approved By | Published? | Notes | +| --- | --- | --- | --- | --- | --- | --- | +``` + +### Tasks + +```yaml +Task 1: +MODIFY policy_management_policy.md: + - Add a governance rule before other policy updates: + "BloomAPI policies may not claim a security, privacy, retention, logging, vendor, or compliance control is operating unless implementation evidence exists or the policy clearly identifies the statement as a planned or under-review item in an internal-only document." + - Add annual regulatory watch review for HIPAA, Part 2, FTC HBNR, and state breach laws. + - Add approval requirement for customer-facing policy claims: Security Officer, Privacy Officer, and counsel/leadership where appropriate. + +Task 2: +CREATE .context/compliance/log-inventory.md: + - Include Cloud Armor HTTP/WAF logs. + - Include server/machine logs. + - Include login/account access events. + - Include database last-activity records. + - Include Grafana alerts. + - Include Sentry alerts/errors. + - Include GCP Cloud Audit Logs/IAM/admin/config logs as "Needs verification". + - Include deploy/change logs as "Needs verification". + - Include support/admin customer-account access as "Needs verification". + - For each: owner, retention, searchable window, archive/export, PHI/Part 2 exposure, evidence location. + - Each `Verified` row must include source, date verified, verifier, artifact location, next review, and scope. + +Task 3: +CREATE .context/compliance/subprocessor-review.md: + - Add GCP, Sentry, PostHog, Grafana/self-hosted. + - Add fields for BAA/DPA, PHI allowed, Part 2 allowed, data categories, retention, region, security review date. + - Mark Sentry/PostHog PHI/Part 2 as "Not approved until verified" unless evidence exists. + - Require both contract and configuration evidence before approval: BAA/DPA status, scrubbing, event filters, sampling, allowed fields, data residency, retention, and proof PHI/Part 2 data is not routed there unless approved. + +Task 4: +CREATE .context/compliance/customer-onboarding-check.md: + - Add HIPAA/BAA required questions. + - Add Part 2/SUD classification questions. + - Add SUD counseling notes question. + - Add patient consent/NPP/customer workforce responsibilities acknowledgement. + - Add customer admin/user offboarding acknowledgement. + - Separate customer classification evidence from customer legal compliance claims. Capturing that Part 2 applies does not mean BloomAPI has verified the customer's consents, notices, or workforce compliance. + +Task 5: +CREATE .context/compliance/access-review-template.md: + - Include production access. + - Include cloud console/IAM. + - Include source code and deployment systems. + - Include monitoring/logging tools. + - Include support/admin access to customer environments. + - Include quarterly privileged review and annual general access review. + +Task 6: +CREATE .context/compliance/incident-evidence-template.md: + - Include incident timeline. + - Include affected systems. + - Include PHI/Part 2/reproductive health/special records assessment. + - Include breach low-probability assessment factors. + - Include customer notice timeline and supplemental updates. + - Include logs/evidence reviewed. + - Include root cause and corrective actions. + +Task 7: +CREATE .context/compliance/policy-claim-register.md: + - Track each customer-facing policy claim and required evidence. + - Include Policy Claim, Customer-Facing File, Required Evidence, Evidence Status, Approved By, Published?, and Notes. + - Use this register to decide whether a policy statement can be promoted from internal evidence to customer-facing documentation. + +Task 8: +VERIFY operational logging: + - Confirm Cloud Armor retention/export. + - Confirm server log retention. + - Confirm whether machine login logs can reconstruct customer-account login history. + - Confirm database last-activity limitations. + - Confirm Grafana alert retention. + - Confirm Sentry retention and PHI scrubbing. + - Confirm GCP Cloud Audit Logs are enabled for admin/IAM/config changes. + - Confirm production deploy/change logs. + - Confirm support/admin access logs. + +Task 9: +IMPLEMENT or track logging gaps: + - If explicit login history does not exist, create an engineering ticket before policy claims it. + - If GCP Cloud Audit Logs are not exported/retained long enough, create an engineering ticket. + - If support/admin customer-account access is not logged, create an engineering ticket. + - If failed login/MFA events are not retained, create an engineering ticket. + +Task 10: +APPROVE retention tiers: + - Propose: + raw machine logs: 30-90 days searchable + security/auth/admin/customer-access logs: 1 year searchable or archived + incident/breach/risk/access-review/policy records: 6 years + - Review with counsel/leadership. + - Implement operational retention before updating policy. + +Task 11: +IMPLEMENT or create tickets for onboarding workflow changes: + - Update CRM, sales forms, contract workflows, product admin, or other actual onboarding systems to capture HIPAA and Part 2 classification. + - If those systems are outside this repo, create explicit implementation tickets before any policy claims onboarding classification is operating. + - Include customer-owned acknowledgements without implying BloomAPI verified customer legal compliance. + +Task 12: +MODIFY auditing_policy.md after verification: + - Add verified log inventory categories and retention. + - Add owner and review cadence. + - Add evidence retention requirements. + - Promotion criteria: every referenced log source must have source, owner, retention, searchable window, export/archive behavior, PHI/Part 2 exposure, verifier, and review cadence marked Verified in log-inventory.md. + - Use neutral fallback language for unverified controls, such as "BloomAPI maintains audit logging appropriate to the service and reviews log coverage periodically," only if true. + +Task 13: +MODIFY data_retention_policy.md after retention tiers are implemented: + - Replace TODOs with final retention tiers. + - Include backup deletion cycle, legal hold, customer deletion, and Part 2 handling. + - Promotion criteria: retention tier is implemented or enforceable, owner is assigned, exception/legal hold process is documented, and counsel/leadership approval is recorded. + +Task 14: +MODIFY 3rd_party_policy.md and subprocessors.md after vendor review: + - Move vendors from TBD to approved/not approved. + - Add review cadence. + - Add requirement to re-review after material vendor/configuration change. + - Keep `subprocessors.md` as customer-facing summary only. Detailed BAA/DPA terms, configuration proof, security review notes, and PHI/Part 2 routing evidence stay in `.context/compliance/subprocessor-review.md`. + - Apply redaction/minimum-necessary rule before publishing vendor details. + +Task 15: +MODIFY part_2_sud_records_policy.md after onboarding is implemented: + - Reference the onboarding classification process. + - Add owner and retention of Part 2 classification evidence. + - Treat Part 2 as current-state compliance, not future readiness. + - Promotion criteria: onboarding workflow actually captures Part 2/SUD status or an explicit implementation ticket exists and the policy does not claim it is operating. + +Task 16: +MODIFY systems_access_policy.md after access review process is running: + - Reference access-review evidence template. + - Add support/admin customer-account access controls if implemented. + - Promotion criteria: access-review cadence has evidence, privileged population is defined, reviewer is assigned, and exceptions are documented. + +Task 17: +MODIFY shared_responsibility_matrix.md: + - Keep customer-owned items explicit. + - Keep the shared responsibility matrix high-level and customer-safe. + - Do not add internal evidence references; maintain evidence mappings in `.context/compliance/policy-claim-register.md`. +``` + +### Integration Points + +```yaml +INTERNAL_EVIDENCE: + - .context/compliance/ files are gitignored collaboration/evidence planning docs. + - Policy files should only cite stable evidence practices, not transient tickets. + +VENDOR_MANAGEMENT: + - subprocessors.md becomes public/internal policy inventory. + - .context/compliance/subprocessor-review.md captures detailed review evidence. + +CUSTOMER_ONBOARDING: + - Future implementation likely requires changes outside this policy repo if onboarding lives in CRM, sales forms, contract workflow, or product admin. + - Create explicit tickets before policies claim those processes are operating. +``` + +## Validation Loop + +```bash +git diff --check +ruby -e 'Dir["*.md"].each { |f| File.read(f).scan(/\[[^\]]+\]\(([^)]+)\)/).flatten.each { |link| next if link.start_with?("http", "#", "mailto:"); path = link.split(":").first; puts "#{f}: missing #{link}" unless File.exist?(path) } }' +rg -n "TBD|Needs verification|Not approved until verified" .context/compliance *.md +# Customer-facing docs should not contain unapproved placeholders except explicit customer-safe "not approved pending review" vendor statuses: +rg -n "TBD|Needs verification|Not approved until verified" *.md +``` + +If the second command returns matches in customer-facing files, either move details to `.context/compliance/`, replace with approved neutral language, or document why the match is intentionally customer-safe. + +Run no-overclaim scan: + +```bash +rg -n "approved for PHI|HIPAA compliant|Part 2 compliant|inherit|inherits|certified|guarantee|all audit logs|all traffic|maximum retention|readily accessible" *.md *.txt +``` + +## Final Validation Checklist + +- [ ] Future-facing policy claims are backed by operational evidence. +- [ ] Vendors have PHI/Part 2 status labels. +- [ ] Log inventory covers Cloud Armor, machine logs, login/access events, Grafana, Sentry, and GCP audit logs. +- [ ] Retention tiers are approved and implemented before policy claims are finalized. +- [ ] Customer onboarding captures HIPAA and Part 2 status. +- [ ] Access review evidence exists before policies claim quarterly reviews are operating. +- [ ] Policy claim register exists and customer-facing claims are approved. +- [ ] No internal evidence paths or sensitive details leak into customer-facing files. +- [ ] Customer-facing docs use redacted/minimum-necessary compliance descriptions. + +## Anti-Patterns to Avoid + +- Do not put unverified controls into customer-facing docs. +- Do not say "PHI allowed" for Sentry/PostHog without contractual and technical validation. +- Do not treat last-activity timestamps as full audit logs. +- Do not update retention policy with numbers that engineering cannot enforce. +- Do not blur BloomText-owned responsibilities with customer-owned legal/clinical obligations. +- Do not publish sensitive logging architecture, incident evidence, vendor contract terms, or internal control gaps in customer-facing artifacts. +- Do not use "Verified" without source, date verified, verifier, artifact location, next review, and scope. + +## Deprecated Code / Docs To Remove + +- Remove "TBD" and "Needs verification" placeholders from customer-facing files. Keep unverified detail in `.context/compliance/`. +- Remove or revise any claim that customers fully inherit controls that remain customer-owned. +- Remove vendor entries that are no longer used after subprocessor review. + +## Confidence Score + +8/10. This plan is intentionally evidence-first. Implementation success depends on engineering/compliance being able to verify actual log retention, vendor contracts, and onboarding workflows. diff --git a/vulnerability_scanning_policy.md b/vulnerability_scanning_policy.md index 8fbc306..6bcbeeb 100644 --- a/vulnerability_scanning_policy.md +++ b/vulnerability_scanning_policy.md @@ -1,6 +1,6 @@ # Vulnerability Scanning Policy -BloomAPI is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. BloomAPI utilizes Snyk and ScouteSuite to test infrastructure and applications for vulnerabilities. +BloomAPI is proactive about information security and understands that vulnerabilities need to be monitored on an ongoing basis. BloomAPI utilizes automated and manual tools to test infrastructure, applications, dependencies, containers, cloud configuration, and other systems for vulnerabilities. ## Applicable Standards from the HITRUST Common Security Framework @@ -12,6 +12,11 @@ BloomAPI is proactive about information security and understands that vulnerabil ## Vulnerability Scanning Policy -* Snyk automatically scans BloomAPI code and disk images for vulnerabilities. -* ScouteSuite is run against BloomAPI Google Cloud infrastructure periodically. -* Upon notification of a vulnerability (e.g. unpatched machine, out-of-date internal api) the vulnerability will be assessed and mitigated by the dev ops team if warranted within 14 days. +* BloomAPI automatically scans code, dependencies, and deployable artifacts for known vulnerabilities. +* BloomAPI scans cloud infrastructure and configuration for insecure settings and drift from approved baselines. +* Authenticated vulnerability scanning of production systems that create, receive, maintain, or transmit ePHI is performed at least every six months and after material changes. +* Penetration testing of externally exposed production services is performed at least annually by an internal or independent qualified tester. +* Upon notification of a vulnerability (e.g. unpatched machine, out-of-date internal API, vulnerable dependency, exposed service, or misconfigured cloud resource) the vulnerability will be assessed, prioritized by severity, and mitigated by the dev ops team. +* Critical vulnerabilities are remediated or mitigated within 7 calendar days. High vulnerabilities are remediated or mitigated within 14 calendar days. Lower severity vulnerabilities are tracked through risk management and remediated according to documented priority. +* Exceptions to remediation timelines require documented risk acceptance by the Security Officer and senior management. +* Vulnerability scan results, penetration test findings, remediation actions, and risk acceptances are retained for a minimum of six years.