HIPAA
- 1 What is HIPAA
- 2 Atlassian FAQ’s
- 3 Atlassian Platform HIPAA support
- 4 Marketplace Apps HIPAA support
- 5 HIPAA certification/compliance
- 6 How We/JEMHC enable HIPAA compliance
- 6.1 Risk management
- 6.2 Workforce security
- 6.3 Information access management
- 6.4 Incident response management
- 6.5 Security responsibility
- 6.6 Privacy responsibility
- 6.7 Security awareness and training
- 6.8 Contingency planning
- 6.9 Business associate contracts
- 6.10 Physical security and endpoint controls
- 6.11 Policies and procedures
- 6.12 Transmission Security
- 6.13 How to use JEMHC/support to minimize HIPAA Impact
- 6.14 Edge Cases
- 6.15 Support
- 6.16 Further Reading
- 7 Business Associate Agreement
- 8 Further Information
What is HIPAA
The Health Insurance Portability and Accountability Act (HIPAA) is a federal regulation developed by the U.S. Department of Health and Human Services, covering ‘health’ related data use.
Its not related to GDPR, but here as a close related topic. See HIPAA | Atlassian for more context.
Atlassian FAQ’s
Customer Facing FAQ answers from Atalssian:https://atlassianpartners.atlassian.net/wiki/spaces/resources/pages/342655180/HIPAA+Compliance+Overview
Question | Response |
---|---|
Why is Atlassian expanding HIPAA availability across all paid plans? | We listened to customer feedback and an overwhelming amount of smaller teams expressed the need for HIPAA compliance. We believe in a cloud-first future for all of our customers and decided to invest in additional automation that would enable us to expand HIPAA compliance beyond the Enterprise plan. We are currently working through the details of implementation and will share once HIPAA is available across all paid plans. Our Enterprise plan continues to be the best choice for enterprise customers and includes a number of features like BYOK, mulitple instances, Atlassian Analytics, and Atlassian Access included for free with every purchase. |
Will Atlassian sign customer BAAs?
| No, Atlassian’s BAA is carefully and specifically drafted and structured to reflect the manner that Atlassian offers its products and services, and Atlassian’s privacy and security program. Due to our company’s emphasis on providing high-quality products to a large customer base under a uniform compliance program, we do not sign customer BAAs. However, we do listen to customer feedback, track and collect it, so if you have some feedback on our BAA, please let us know. |
Are marketplace apps included in this compliance? | No, our BAA only covers Jira Software Cloud, Confluence Cloud, and JSM Cloud products. Marketplace apps integrated with Atlassian products are not covered by a Customer’s BAA with Atlassian. Customers must assess their use of each marketplace app and determine if they need a BAA with the app in order to meet their compliance needs. |
Atlassian Platform HIPAA support
Atlassian provides comprehensive privacy and security protections that enable customers to operate Atlassian products in compliance with HIPAA.
In the Understand HIPAA compliance for Atlassian products | Atlassian Support page. There you will find about how you sign a Atlassian Business Associate Agreement (BAA) with Atlassian and how you would configure the Atlassian Products to safeguard data that Atlassian hold.
Marketplace Apps HIPAA support
Marketplace apps are not in scope for the Atlassian signed BAA. Our cloud app JEMHC has no concept of HIPAA data and categorizations that you make on the Atlassian Product, we don’t extract/store data ourselves, the bare minimum information is stored (i.e. email addresses/personal names) for inbound/outbound auditing purposes. JEMHC is a tool, you can use it to extract data from the ‘source’ email content and store in your Jira instance in those pre-defined HIPAA fields.
The The HIPAA Implementation Guide | Atlassian Support page states that:
All third-party apps integrated with Atlassian products also need to be operated in a HIPAA-compliant way. This means you must have a signed Business Associate Agreement (BAA) with all relevant third-party apps.
As we see it, enabling HIPAA is done at the Atlassian Product (Jira/Confluence) level in order to apply “protection” to specific typed/identified/tagged data holding entities like Jira Custom Fields, limiting search and (I we expect) remote access from apps like JEMHC.
HIPAA certification/compliance
According to How Atlassian enables HIPAA compliance | Atlassian:
At present, there’s no certification in relation to HIPAA. The agencies that certify health technology don’t approve software or empower independent certifying authorities to accredit business associates or covered entities with a HIPAA attestation. Therefore, there is no official certification to say that we comply with HIPAA. However, our cloud products undergo independent verification of the operational effectiveness of their security, privacy, and compliance controls on an annual basis. An independent certifying authority has performed an audit and confirmed that Atlassian has the required controls and practices in place to ensure all HIPAA regulations are being adhered to.
We have passed a SOC2 (type 1) audit and are currently undergoing a SOC2 (type 2) audit.
How We/JEMHC enable HIPAA compliance
Based on the structure used in How Atlassian enables HIPAA compliance | Atlassian:
Risk management
Reduce risks and vulnerabilities, conduct periodic technical, and nontechnical evaluations in response to environmental or operational changes
We perform a risk assessment annually that include the identification, assessment, assignment, acceptance, remediation, and other relevant management activities, to ensure we operate within the agreed upon risk appetite and relevant legal and regulatory requirements. We continuously evaluate the design of controls and mitigation strategies, including recommending changes in the control environment. We maintain a risk and controls matrix within our Governance, Risk, and Compliance (GRC) tool.
Workforce security
Background screening and proper termination procedures
Our employees and contractors that have access to confidential information are bound by their employment contracts and confidentiality deeds to ensure that information security responsibilities and duties remain valid after termination, or change of employment, as well as the end of contractual relationships.
Sanctions against workforce members
Formal sanctions exist and are employed for individuals failing to comply with established information security policies and procedures.
Information access management
Authorization of access for employees who work with ePHI
Privileged access to production environments is restricted to authorized and appropriate users only.
All staff participate in support and all have access to Jira/data you supply for that purpose.
Appropriate granting of access (least privileged basis)
We employ policy based permission schemes for cloud infrastructure.
Only office based staff have access to our internal network.
Terminate a session after predetermined time of inactivity
Office powers down nightly, so 8hrs is the max office session life.
OS lock after 5m of inactivity. A screensaver is enforced with a requirement to enter a password to unlock it.
Incident response management
Audit logging/detection (including monitoring of login attempts)
AWS logs are retained for 12 months. We have very limited data logged.
Identify and respond to suspected or known security incidents. Mitigate and document the incidents and their outcomes
We have implemented an incident management process comprising:
recording every action, when managing an incident, into the Incident Management System under an incident ticket. Records must include:
incident start time
incident description
severity
services affected
impact
number of affected customers
root cause
actions taken
affected SLOs (capabilities impacted)
associating problems, where possible, with the underlying cause and/or grouping them together into parent incidents
completing a Post Incident Review (PIR) after Major and Critical Incidents
Security responsibility
Identify an individual responsible for the development and implementation of the HIPAA security compliance program
Andy Brook, CEO
Privacy responsibility
Identify an individual responsible for the development and implementation of the HIPAA privacy compliance program
Andy Brook, CEO.
Our GDPR contact addresses are as follows:
UK: privacy@thepluginpeople.com to talk to us about any privacy issues.
Security awareness and training
User awareness training
To do.
Contingency planning
Procedures to enable continuation of critical business processes
We have defined, reviewed, and tested procedures for Disaster Recovery execution. The policy describes, at a high level, the purpose, objectives, scope, recovery time objective, recovery point objective, and roles/responsibilities.
DR planning is ongoing. Our JEMHC app has been designed for high availability and will automatically recover from any individual node failures.
In support of contingency plan components, we assess services and systems for their criticality annually.
Business associate contracts
Business Associate Agreements contain satisfactory assurances that your data will be appropriately safeguarded by Atlassian and third party suppliers
We have Data Processing Agreements in place with all our sub-processors. BAA’s have not yet been progressed.
Physical security and endpoint controls
Safeguard physical facilities and equipment from tampering or theft
An access dongle is required for physical building and security door access. Terminated staff have dongle physically taken/revoked. Terminated staff development machines are rebuilt.
Implement physical safeguards for all workstations that access ePHI
We implement full disk encryption on all workstations and laptops, use password lock, and apply security patching.
In the rare event Removable media is required, such USB sticks are also fully encrypted.
Procedures to address the final disposition of ePHI and the hardware on which it is stored
We wipe any laptop returned before it is redeployed or disposed. A lost/stolen laptop procedure is also in place to ensure data is not stolen.
Policies and procedures
Retain documentation for 6 years from the date of its creation, or the date when it was last in effect
Our Policies are being updated as part of SOC2 compliance, will be made available when complete.
Our Privacy Policy can be found here.
Transmission Security
Security measures to ensure that ePHI is not improperly modified
All stored email data (inbound/outbound) is encrypted at rest.
All external (public) network transfer are made using SSL for a secure transfer (first hop only).
Any/all support data provided that is downloaded by support staff is stored only only full disk encrypted company hardware.
Mechanisms to encrypt ePHI whenever it is deemed appropriate
JEMHC interactions with your mailbox can only be made using SSL protocol (only first hop transport security guarantee)
JEMHC interactions with your Jira can only made using SSL protocol.
User interactions with JEMHC app can only be made using SSL protocol.
User interactions with our support system can only be made using SSL protocol.
JEMHC (user) and JEMHC (system) IM notifications are only made using SSL protocol.
How to use JEMHC/support to minimize HIPAA Impact
Being HIPAA certified has challenges for us as an Email processor /sender, we need PHI (Email Addresses) for core functionality. We don’t specifically ‘know’ what data you store, so can’t specifically ‘redact’. We are not HIPAA compliant at this point. The following would be seen as the ‘technical measures’ our app has that could be applied for HIPAA compliance.
The JSM notification templates we use include a limited subset of fields that notifications include, so overall JEMHC measures in place that support HIPAA could be viewed as:
We limit what field we send in notifications (not all changed fields would be sent), you can add more fields specifically.
You can enable/disable inline images and attachments to be sent (at all)
You can enable/disable email-user support (that stores email addresses in custom fields where no portal user / Jira user is desired), Email Addresses are PHI, are a HIPAA data category, for HIPAA compliance, you’d probably have to not use this feature
You can enable/disable attachment of the raw Email to the issue, again for HIPAA compliance you’d probably have to not use this feature.
If an inbound mail is not processed, a ‘fwd’ mail is sent to the Profile > Forward Users, linking to the Audit record involved. If you have disabled auditing the full mail is attached to avoid data loss. The full mail obviously contains IP addresses, recipient addresses, full content etc.
If you flag a mail for support in auditing, an issue is created in our support system referring the audit record. Only such flagged mails (its processing Report, your Profile) are available to all our support staff via a back-office app, through which data downloads can occur, such data is burned when support tickets are closed out.
Edge Cases
Webhook containing data about issue events (that drive JEMHC notifications) are kept for a short time, but still are available to System administrators, can be ‘saved’ as Preview Contexts for Template Set previews.
Auditing retains copies of Inbound and Outbound mail for 30days, this is available to System administrators. You can opt-out of auditing but make it hard for you to diagnose processing problems, and will prevent you from performing simple recovery actions (e.g. Jira user not allowed to comment) and will impact our ability to help with problems you may encounter.
Support
For HIPAA compliance, for support purposes, you would need to ensure we don’t get PHI data. It means the onus is on you to re-create emails to demonstrate problems. The impact of the following will be that our ability to deliver great support will be hindered, a cost of HIPAA compliance.
NOT send us an email containing PHI
NOT attach an email containing PHI to a support case
NOT use the “Flag for support” feature at all, to prevent any all PHI data from being exposed to use in support.
NOT send/attach the REPORT from processing a real email, as this may contain PHI.
Further Reading
Business Associate Agreement
We are currently undergoing SOC2 Audit (type 1 passed, type 2 currently underway). As a Business Associate of customers processing Protected Health Information (PHI).
Atlassian have a BAA (Atlassian Business Associate Agreement | Atlassian ), for their host environments, it doesn’t include apps.
What is a Business Associate Agreement (BAA)
As perBusiness Associate Contracts
The HIPAA Rules generally require that covered entities and business associates enter into contracts with their business associates to ensure that the business associates will appropriately safeguard protected health information. The business associate contract also serves to clarify and limit, as appropriate, the permissible uses and disclosures of protected health information by the business associate, based on the relationship between the parties and the activities or services being performed by the business associate. A business associate may use or disclose protected health information only as permitted or required by its business associate contract or as required by law. A business associate is directly liable under the HIPAA Rules and subject to civil and, in some cases, criminal penalties for making uses and disclosures of protected health information that are not authorized by its contract or required by law. A business associate also is directly liable and subject to civil penalties for failing to safeguard electronic protected health information in accordance with the HIPAA Security Rule.
JEMHC BAA
As per Business Associate Contracts :
(1) establish the permitted and required uses and disclosures of protected health information by the Business Associate;
(2) provide that the Business Associate will not use or further disclose the information other than as permitted or required by the contract or as required by law;
(3) require the Business Associate to implement appropriate safeguards to prevent unauthorized use or disclosure of the information, including implementing requirements of the HIPAA Security Rule with regard to electronic protected health information;
(4) require the Business Associate to report to the Covered Entity any use or disclosure of the information not provided for by its contract, including incidents that constitute breaches of unsecured protected health information;
(5) require the Business Associate to disclose protected health information as specified in its contract to satisfy a Covered Entity’s obligation with respect to individuals' requests for copies of their protected health information, as well as make available protected health information for amendments (and incorporate any amendments, if required) and accountings;
(6) to the extent the Business Associate is to carry out a Covered Entity’s obligation under the Privacy Rule, require the Business Associate to comply with the requirements applicable to the obligation;
(7) require the Business Associate to make available to HHS its internal practices, books, and records relating to the use and disclosure of protected health information received from, or created or received by the Business Associate on behalf of, the Covered Entity for purposes of HHS determining the Covered Entity’s compliance with the HIPAA Privacy Rule;
(8) at termination of the contract, if feasible, require the Business Associate to return or destroy all protected health information received from, or created or received by the Business Associate on behalf of, the Covered Entity;
(9) require the Business Associate to ensure that any subcontractors it may engage on its behalf that will have access to protected health information agree to the same restrictions and conditions that apply to the Business Associate with respect to such information; and
(10) authorize termination of the contract by the Covered Entity if the Business Associate violates a material term of the contract. Contracts between Business Associates and Business Associates that are subcontractors are subject to these same requirements
A draft Business Associate Agreement for JEMHC is now available for review/comment.
Further Information
If you need more, feel free to log a support ticket with us: