Asana HIPAA Compliance: Does Asana Sign a BAA and Can You Use It for PHI?

Product Pricing
Ready to get started? Book a demo with our team
Talk to an expert

Asana HIPAA Compliance: Does Asana Sign a BAA and Can You Use It for PHI?

Kevin Henry

HIPAA

October 05, 2025

6 minutes read
Share this article
Asana HIPAA Compliance: Does Asana Sign a BAA and Can You Use It for PHI?

You can use Asana with Protected Health Information (PHI) when you have the right plan, a signed Business Associate Agreement, and guardrails that minimize data exposure. The key is pairing contractual coverage with disciplined configuration and workflow design so only the minimum necessary PHI is processed.

Asana's HIPAA Compliance for Enterprise Customers

Asana supports regulated healthcare use cases for eligible Enterprise customers that execute a Business Associate Agreement (BAA). Without a BAA in place, you should not store or process PHI in the platform. Even with a BAA, HIPAA compliance is a shared responsibility between your organization and Asana.

Asana is best suited to operational and coordination workflows—think project plans, task assignments, and status tracking—where you can meet the “minimum necessary” standard. It is not designed to be an Electronic Health Record, so avoid using it as the system of record for clinical documentation or patient charts.

Executing and Activating the Business Associate Agreement

To use Asana for PHI, you must first execute a BAA and then enable the appropriate controls. Treat these as two distinct steps: contract, then configuration.

  • Confirm eligibility: ensure your subscription tier supports a BAA for HIPAA-covered work.
  • Request and execute the BAA: work through your procurement and legal teams to review, sign, and retain the agreement.
  • Complete HIPAA Compliance Activation: after the BAA is countersigned, enable HIPAA-specific guardrails and policies in your admin settings.
  • Harden access: require SSO and MFA, enforce strong role-based permissions, and restrict guest access to only covered entities and business associates.
  • Train your users: provide clear guidance on what PHI, if any, may appear in tasks, comments, custom fields, and attachments.

Data Retention and Deletion Policies

A written Data Retention Policy is essential for HIPAA and good data hygiene. Define what PHI can appear in Asana, how long you keep it, and the triggers for deletion or archival. Align retention periods with legal, regulatory, and business requirements.

  • Scope your data: keep PHI out of task titles and use coded identifiers where possible; confine sensitive details to limited fields with stricter access.
  • Automate where you can: schedule regular reviews to archive or delete completed work that contains PHI.
  • Delete thoroughly: remove tasks, comments, and attachments that exceed retention; confirm that exports and admin backups follow the same timelines.
  • Document destruction: maintain logs of deletion events and approvals to demonstrate compliance during audits.
  • Honor legal holds: suspend deletion for items under investigation or litigation until the hold lifts.

Limitations on Storing Protected Health Information

Follow a strict minimum-necessary approach. If you can achieve your workflow goals without PHI, do so. When PHI is unavoidable, reduce the sensitivity and volume you handle.

Ready to simplify HIPAA compliance?

Join thousands of organizations that trust Accountable to manage their compliance needs.

  • Avoid clinical content: do not store patient charts, diagnostic images, lab reports, medication lists, or detailed clinical notes.
  • Prefer codes over names: use de-identified or pseudonymous IDs for patients and encounters, not full names or dates of birth.
  • Keep PHI out of high-visibility areas: never place PHI in task titles, project names, or public descriptions.
  • Use attachments sparingly: only include attachments with PHI when strictly necessary and delete them promptly per your retention rules.
  • Sanitize free text: train users to avoid including diagnoses, SSNs, or financial data in comments or custom fields.

Asana's Role Outside of Electronic Health Records

Asana is not an Electronic Health Record and should not be used for clinical documentation, order entry, or patient charting. Instead, position it as a coordination and program-management layer that references, but does not replace, your EHR.

  • Appropriate uses: care team tasking, referral follow-ups, quality-improvement projects, compliance checklists, and operational workflows.
  • Inappropriate uses: maintaining longitudinal patient records, storing imaging or lab results, or capturing detailed clinical narratives.

When you must reference a patient, rely on coded identifiers and link back to the source system that serves as the official record.

Restrictions on External Communications

HIPAA risk often surfaces at the boundaries—email notifications, guest users, and third‑party integrations. Configure external touchpoints so PHI never leaves covered systems unintentionally.

  • Email and notifications: restrict content in notifications or turn them off for items that may contain PHI; ensure recipients are part of your covered entity or business associate network.
  • Guest access: limit or prohibit external guests unless they are under a BAA; prefer private projects and least‑privilege sharing.
  • Integrations: only connect apps that are necessary and covered by their own BAAs; avoid routing PHI to chat, email, or storage tools that are not HIPAA-ready.
  • Public sharing: disable public links and prevent exporting PHI to uncontrolled destinations.

Privacy and Data Protection Certifications

Vendor attestations strengthen trust but do not, by themselves, create HIPAA compliance. Evaluate Asana’s privacy and security posture in the context of your BAA and controls.

  • Privacy governance: look for programs aligned to ISO/IEC 27701:2019 to evidence structured privacy management.
  • Security baselines: consider broader frameworks such as ISO/IEC 27001 and SOC 2 Type II for control maturity across confidentiality, integrity, and availability.
  • Regulatory alignment: review how the service addresses obligations under laws like the California Consumer Privacy Act and how those commitments intersect with HIPAA safeguards.

Bottom line: a signed BAA, careful HIPAA Compliance Activation, data minimization, strong access controls, and a disciplined Data Retention Policy are what make Asana workable for limited PHI use cases.

FAQs

Does Asana offer a HIPAA-compliant service for PHI?

Yes—Asana can support HIPAA obligations for eligible Enterprise customers when a Business Associate Agreement is in place and HIPAA Compliance Activation settings are enabled. Even then, keep PHI to the minimum necessary and avoid using Asana as an Electronic Health Record.

Can customers sign a BAA with Asana?

Eligible Enterprise customers can request and sign a Business Associate Agreement with Asana. After execution, complete HIPAA Compliance Activation and reinforce governance with SSO, MFA, least‑privilege access, and user training.

What limitations exist for storing PHI in Asana?

Do not store clinical records, diagnostic images, or detailed clinical notes. Keep PHI out of titles, prefer coded identifiers, limit attachments, and restrict external sharing. Use only the minimum necessary PHI to accomplish the task.

How does Asana handle data retention and deletion for HIPAA compliance?

You define and enforce a Data Retention Policy that specifies what PHI can appear, retention periods, and deletion workflows. Regularly review projects for aging PHI, remove tasks and attachments that exceed retention, document destruction, and honor legal holds before purging data.

Share this article

Ready to simplify HIPAA compliance?

Join thousands of organizations that trust Accountable to manage their compliance needs.

Related Articles