The Healthcare & Legal Practice Security Guide

Pillar 1 — Identity: Make Every Login Prove Itself

• ✓Enable Microsoft Entra ID (formerly Azure AD) as your identity provider for all practice applications. Every app — EHR, billing, practice management, email — should authenticate through Entra, not via local passwords.
• ✓Require MFA for every user account without exception. This includes admin accounts, service accounts, and the "temporary" account you created for the summer intern three years ago. Audit your user list and disable inactive accounts.
• ✓Deploy phishing-resistant MFA for high-privilege accounts: Microsoft Authenticator with number-matching (not just push notifications, which are vulnerable to MFA fatigue attacks) or FIDO2 hardware security keys. Avoid SMS-based MFA — SIM-swap attacks are common and low-cost for attackers.
• ✓Block legacy authentication protocols. Go to Entra ID → Security → Conditional Access → New Policy. Block access for client app = "Exchange ActiveSync" and "Other clients." Legacy auth (Basic Auth, NTLM) completely bypasses MFA — attackers specifically target it.
• ✓Create a Conditional Access Policy blocking sign-ins from high-risk countries. Unless your physicians or attorneys regularly travel to Russia, North Korea, or China, there is no reason to accept sign-in attempts from those IP ranges.
• ✓Enable Entra ID Identity Protection and configure risk-based Conditional Access: medium-risk sign-ins require MFA step-up; high-risk sign-ins require password reset before access is restored.
• ✓Activate Privileged Identity Management (PIM). No account should have permanent Global Admin or Exchange Admin rights. Require just-in-time elevation with a business justification and approval. This single control would have stopped the majority of the M365 tenant compromises our team responded to in 2024–2025.
• ✓Audit service accounts and shared credentials. "Front desk login" shared across three staff members is a HIPAA violation (§164.312(a)(2)(i) requires unique user identification) and makes forensics impossible after an incident. Convert shared accounts to individual accounts or managed identities.

Pillar 2 — Devices: Trust Only What You Can See

• ✓Enroll all endpoints in Microsoft Intune — Windows, macOS, iOS, and Android. If a device is not in Intune, it should not have access to practice data.
• ✓Create Intune Compliance Policies requiring: disk encryption (BitLocker/FileVault), OS minimum version (Windows 11 22H2 or newer; macOS 14 or newer), screen lock after 5 minutes of inactivity, and active antivirus.
• ✓Create a Conditional Access Policy blocking access from non-compliant or unmanaged devices. This is the payoff for enrolling in Intune — if a device fails compliance, it gets blocked, not just warned.
• ✓Deploy SentinelOne Singularity or Microsoft Defender for Endpoint Plan 2 on all endpoints with real-time behavioral protection active. Verify coverage — a "deployed" agent that has not checked in for 30 days provides zero protection.
• ✓Enable Intune Application Protection Policies (APP) for mobile: require a PIN to access corporate data, block copy/paste to unmanaged apps, and enable remote wipe of corporate data without wiping the personal device.
• ✓Disable USB mass storage on clinical and legal workstations via Intune Device Configuration. A staff member with a USB drive can copy every patient record in your EHR in minutes. This is a documented insider threat vector.

Pillar 3 — Network: Remove Implicit Trust

• ✓Replace legacy VPN with Microsoft Entra Private Access (ZTNA). Traditional VPNs grant network-level access — once connected, a user can reach any system on the network. ZTNA grants access only to specific applications, and only to verified users on compliant devices.
• ✓Deploy Cisco Umbrella or Entra Internet Access for DNS-layer filtering on all endpoints. These tools block connections to known command-and-control servers, phishing domains, and malware distribution sites before a connection is established.
• ✓Segment your network. Clinical/legal workstations should be on a dedicated VLAN, isolated from the guest Wi-Fi network, IoT devices (smart TVs, connected printers, building access systems), and medical equipment. A compromised guest network should not be able to reach your EHR.
• ✓Disable RDP (port 3389) exposure to the internet. Run a Shodan search for your public IP range to see if RDP is visible. If it is, you are actively being scanned by automated attack tools. If remote access is needed, gate it through your ZTNA solution.
• ✓Review firewall rules annually. Every "temporary" rule that was never removed is a potential attack surface. Remove any allow-any-to-any rules. Document the business justification for every firewall rule that allows inbound internet traffic.

Pillar 4 — Applications & Data

• ✓Enable Microsoft Defender for Cloud Apps (MCAS) for shadow IT discovery. You will be surprised what unsanctioned applications your staff is using with patient and client data. MCAS identifies them and allows you to block or govern them.
• ✓Create DLP policies in Microsoft Purview. Use the built-in HIPAA template as a starting point. Configure to block PHI/PII transmission to personal email addresses, USB drives, and unapproved cloud storage. Alert on policy violations in real time.
• ✓Apply Microsoft Purview Sensitivity Labels to PHI-containing documents. Labels enforce encryption and access controls that travel with the file — even if a document is emailed out, only authorized recipients can open it.
• ✓Review all OAuth application consents in Entra ID. Go to Entra ID → Enterprise Applications → All Applications → filter by "User consent." Revoke any application with permissions like "Read all mail" or "Full access to all files" from an unknown publisher. OAuth consent phishing is a primary attack vector against law firms.

The 12 HIPAA Security Rule Controls Most Practices Fail

• ✗Access Controls (§164.312(a)(1)): Unique usernames and automatic logoff are required. Shared login credentials — even "just for the front desk" or "just for the billing team" — are a direct violation. Every login must be attributable to a specific individual. Audit: pull a user list from your EHR and confirm every account belongs to a current employee with a documented business need.
• ✗Audit Controls (§164.312(b)): Your EHR/EMR must log who accessed which patient record and when. Most practices have audit logging enabled in the software but have never reviewed the logs. OCR will ask for 6 months of access logs during an investigation. If you cannot produce them, the penalty multiplies.
• ✗Transmission Security (§164.312(e)): ePHI transmitted over open networks must be encrypted. Sending a patient's lab results or medication list via standard Gmail or unencrypted Outlook — even to a colleague — is non-compliant. Use Microsoft 365 Message Encryption, Paubox, or equivalent secure messaging.
• ✗Workforce Training (§164.308(a)(5)): Annual security awareness training is required and must be documented. OCR requires training completion records, not just a policy that says training happens. "We covered it in the staff meeting" is not documentation. Require digital completion acknowledgments and retain records for 6 years.
• ✗Risk Analysis (§164.308(a)(1)): A written, comprehensive risk analysis of all ePHI is required — not a vendor-provided checklist, not a generic template. It must identify every system that stores or transmits ePHI, assess threats and vulnerabilities, and document mitigation. This is the #1 deficiency cited by OCR. If you do not have one, stop here and schedule one.
• ✗Sanction Policy (§164.308(a)(1)(ii)(C)): You must have a documented policy for disciplining employees who violate HIPAA, and you must enforce it. Without a sanction policy, you cannot demonstrate workforce accountability to OCR during an investigation.
• ✗Contingency Plan (§164.308(a)(7)): A data backup plan, disaster recovery plan, emergency mode operation plan, and testing/revision procedure are all required. Most practices have backups but no documented recovery procedure. OCR will ask: "How long would it take you to restore your EHR from backup?" If you do not know, you do not have an adequate contingency plan.
• ✗Device & Media Controls (§164.310(d)(1)): Policies for receiving, removing, and disposing of hardware containing ePHI. Old workstations and hard drives must be professionally wiped (NIST 800-88 standard) or physically destroyed before disposal. "We deleted the files" is not sufficient — data recovery from a deleted drive is a standard forensic procedure.
• ✗Workstation Use (§164.310(b)): Documented policies specifying proper workstation functions and physical security requirements. In clinical environments: screen privacy filters to prevent shoulder-surfing, automatic lock after inactivity (5 minutes maximum), and a policy that screens are not visible to patients in waiting areas.
• ✗Business Associate Agreements (§164.308(b)(1)): BAAs must be signed with every vendor who creates, receives, maintains, or transmits ePHI on your behalf. This includes your IT provider, EHR vendor, billing company, cloud backup provider, transcription service, and answering service. A BAA you verbally agreed to is not a BAA.
• ✗Assigned Security Responsibility (§164.308(a)(2)): A named Security Officer is required by name, in writing. This does not need to be a full-time position, but the individual must understand their responsibilities, be empowered to make security decisions, and be documented in your policies.
• ✗Physical Safeguards (§164.310(a)(1)): Facility access controls, workstation security, and server room access must be documented. Unlocked server closets, unattended clinical workstations logged in to the EHR, and patient records visible on a screen facing a waiting room are common OCR findings.

OCR Civil Penalty Tiers — What Non-Compliance Actually Costs

Penalties are per violation category, not per incident. A single breach involving a missing BAA, inadequate training, and no risk analysis can trigger three separate penalty tiers simultaneously.

ABA Formal Opinion 477R — The 5 Cybersecurity Obligations for Law Firms

• ✓Competency (Model Rule 1.1): Attorneys must understand the benefits and risks of technology they use in client representation. This obligation extends to AI research tools, cloud storage platforms, and remote access systems. Ignorance of a tool's security properties is not a defense in a disciplinary proceeding — it is evidence of incompetency.
• ✓Confidentiality (Model Rule 1.6): Reasonable measures must be taken to prevent unauthorized disclosure of client information. The "reasonableness" standard is contextual — it considers the sensitivity of the client information, the cost of the safeguard, and the probability of a breach. A "reasonable" safeguard for routine correspondence is insufficient for M&A strategy documents or criminal defense strategy.
• ✓Factor Analysis for Communication Methods: The Opinion requires attorneys to evaluate the security of each communication method based on the specific matter. Email without encryption may be reasonable for scheduling — it is not reasonable for transmitting litigation strategy, settlement terms, or protected client information.
• ✓Supervision (Model Rules 5.1 and 5.3): Partners are responsible for supervising associates' and staff's use of technology — including AI drafting tools, legal research platforms, and cloud storage. Unsupervised AI-generated work product used in client matters, without attorney review and verification, is a supervision failure. The duty extends to contract staff and vendors with access to client files.
• ✓Due Diligence on Technology Vendors: Before using any cloud-based platform, collaboration tool, or legal technology product with client data, the firm must conduct reasonable due diligence on the vendor's security practices. The firm bears responsibility for client data security failures where due diligence was not performed.

Before an Incident: Build Your Emergency Contact Sheet Today

Print this and store it physically — your email and files may be inaccessible during an incident.

• •IT provider emergency line: Business IT Support — (602) 935-5505 — available 24/7 for active incidents
• •Cyber insurance carrier claims line: [Find your carrier's claims number now and write it here] — most policies require notification within 24 hours
• •FBI Phoenix Field Office Cyber Division: (623) 466-1999 — report ransomware; they can identify the attacker group and advise on OFAC sanction implications before any payment
• •Your healthcare attorney / outside general counsel: [Document now] — you need privilege protection over your breach investigation immediately
• •HHS OCR Breach Hotline: 1-800-368-1019 — healthcare only; 60-day notification clock starts at discovery, not at containment
• •Your EHR/EMR vendor emergency line: [Find in your contract; most have 24/7 support for active incidents] — they may have a clean backup of your database
• •Arizona State Bar (law firms): (602) 252-4804 — consult on client notification obligations before contacting clients
• •Your local FBI InfraGard contact: [If enrolled] — provides intelligence sharing during active incidents

Hour 0–1: Immediate Isolation (Do This First — Do Not Wait)

• ✓Disconnect affected computers from the network immediately. Unplug ethernet cables and disable Wi-Fi on any machine showing ransomware symptoms (encrypted files, ransom note, slow performance). Do NOT power off the machine — memory forensics may be needed to identify the attacker and attack vector.
• ✓Do not pay the ransom before consulting your cyber insurance carrier and legal counsel. Certain ransomware groups are on the U.S. Treasury OFAC sanctions list. Paying them — even unknowingly — can result in additional federal penalties on top of the ransomware loss. Your insurer will advise on whether payment is permitted.
• ✓Call your IT provider immediately to begin environment isolation and forensic evidence preservation. If you wait until morning, you are allowing active malware to continue spreading for hours.
• ✓Document the time of discovery, who discovered it, what systems appear affected, and the ransom note text. Photograph the ransom note if it is displayed on screen. This documentation becomes your evidence of "reasonable response" for OCR.
• ✓Identify your clean systems. What is definitely not infected? Protect those machines first by isolating them from the network before they are reached by the malware.
• ✓Notify your cyber insurance carrier within 24 hours. Late notification can void your claim. Most carriers have an incident response team they will dispatch. Use them — their IR resources are covered by your policy.

Hour 1–4: Assessment and Investigation

• •Determine the attack vector with your IT provider: phishing email (check mail logs for suspicious inbound links clicked in the 48–72 hours before the incident), RDP brute force (check firewall logs for failed login attempts from foreign IPs), compromised credentials (check if any accounts logged in from unusual locations), or supply chain compromise (check if a vendor had remote access).
• •Map the blast radius. Which systems are encrypted? Which are intact? Does the ransomware have a data exfiltration component (most modern ransomware includes "double extortion" — data theft before encryption)? Check firewall logs for unusual large outbound data transfers in the 48–72 hours before encryption began.
• •Determine whether ePHI or attorney-client privileged data was on affected systems. This determination drives your breach notification obligations. If PHI was on an encrypted system, assume it was exfiltrated until forensics confirm otherwise — that triggers the OCR 60-day clock.
• •Verify your backup integrity. Locate your most recent clean backup. Confirm it predates the infection. Confirm it is accessible and not encrypted. Confirm you know how long restoration will take.
• •Engage your cyber insurance carrier's IR team. Most policies include forensics, legal counsel, PR support, and sometimes a negotiation service if payment is being considered. These resources are paid for — use them.

Hour 4–24: Communication Decisions

• •Prepare internal staff communication: what happened, what staff should and should not say (do not discuss with patients, do not post on social media), and what operational changes are in effect (no access to EHR, use paper records).
• •If patient appointments are affected, communicate operational disruptions without disclosing the nature of the incident until forensics are complete. "We are experiencing a system outage" is accurate and non-disclosing.
• •Document every decision with a timestamp and rationale. "At 3:47 PM on [date], we decided not to notify patients based on the advice of our healthcare attorney and pending forensic determination" is the kind of documentation that demonstrates reasonable response to OCR.
• •Brief your physicians, partners, or managing attorney on what happened and what the liability exposure is. They will be fielding questions from staff, patients, and potentially media.

Hour 24–72: Recovery Sequencing

• ✓Restore from the most recent verified clean backup — never from a backup taken after the infection date. Ransomware can be dormant for weeks before encrypting.
• ✓Reset all passwords organization-wide before reconnecting any system to the network. Assume all credentials on the network are compromised.
• ✓Rebuild compromised systems from scratch rather than attempting to clean them. Malware persistence mechanisms (registry modifications, scheduled tasks, kernel-level rootkits) are routinely missed by cleanup attempts. If budget allows, reimage every affected machine.
• ✓Re-enable systems in priority order: patient scheduling and case management first, billing and claims second, administrative functions last.
• ✓Conduct a post-incident review within 30 days to document the full incident timeline, forensic findings, attack vector, recovery actions, and control improvements. This document is required for an OCR investigation if one is opened.

Authentication & Identity (Highest Priority — Start Here)

• ✓Block Legacy Authentication: Entra ID → Security → Conditional Access → New Policy. Condition: Cloud apps = All apps; Client apps = Exchange ActiveSync + Other clients. Grant: Block access. Legacy protocols (Basic Auth, IMAP auth, SMTP auth) bypass MFA entirely. This is the single highest-value security change you can make in M365.
• ✓Enable Security Defaults or Conditional Access MFA: Entra ID → Properties → Manage Security Defaults. If on a Business Basic or Standard plan without Entra P1/P2, Security Defaults is your only option — enable it. If you have Entra P1/P2 (included in M365 Business Premium), disable Security Defaults and implement Conditional Access policies instead for more granular control.
• ✓Require MFA for All Admin Roles: Create a CA policy targeting the directory roles group containing all admin roles. Set Grant: Require MFA. Test with a non-production admin account before enforcing. Global Admin accounts should use FIDO2 hardware keys — a stolen Global Admin password without a physical key is useless to an attacker.
• ✓Disable Auto-Forwarding to External Addresses: Exchange Admin Center → Mail Flow → Remote Domains → Default → Edit → Set "Allow Automatic Forwarding" to Off. Business Email Compromise (BEC) attackers routinely configure inbox rules to silently forward every email to an external account. This setting blocks that exfiltration channel.
• ✓Enable the Unified Audit Log: Compliance portal → Audit → Start recording user and admin activity. Required for HIPAA audit controls (§164.312(b)). Default retention is 90 days — upgrade to 1 year with a Microsoft 365 E3 license or the Audit (Standard) add-on. Without this enabled, you have no evidence during an investigation.

Email Security

• ✓Enable Anti-Phishing Policy with Impersonation Protection: Security portal → Email & Collaboration → Policies & Rules → Threat Policies → Anti-phishing. Enable impersonation protection for your top-level domain, for your managing physician / managing partner, and for your billing staff. Enable mailbox intelligence. Set action to "Quarantine" rather than "Move to Junk."
• ✓Enable Safe Links with Block-Through Protection: Security portal → Policies & Rules → Threat Policies → Safe Links. Create a policy for all users. Enable "Do not allow users to click through to the original URL" for users in clinical and billing roles. Enable URL scanning within Office documents. This rewrites URLs in real time and blocks known malicious destinations.
• ✓Enable Safe Attachments with Dynamic Delivery: Security portal → Policies & Rules → Threat Policies → Safe Attachments. Create a policy for all users with action = "Dynamic Delivery." Dynamic delivery sends the email body immediately and holds only the attachment for detonation — users are not delayed, but malicious attachments are blocked before delivery.
• ✓Configure DMARC, DKIM, and SPF for your domain: In your DNS provider, verify your SPF record includes all legitimate sending sources (M365, your EHR system, your billing platform). Enable DKIM signing in the Security portal under Email Authentication. Add a DMARC TXT record with p=quarantine at minimum (p=reject preferred once you've verified all legitimate sources are covered).
• ✓Enable Quarantine Notifications: Security portal → Policies & Rules → Threat Policies → Quarantine Policies. Configure users to receive daily digest emails of quarantined messages. Without this, legitimate emails quarantined by Safe Attachments or Anti-Phishing are silently discarded — users never know they missed them.

Collaboration & Data Governance

• ✓Restrict External Sharing in SharePoint: SharePoint Admin Center → Policies → Sharing. Set organization-level sharing to "Existing guests only" or "Only people in your organization" for any document library containing PHI or client files. Most practices do not need anonymous sharing links for their internal document systems.
• ✓Disable Guest Access in Teams by Default: Teams Admin Center → Org-wide settings → Guest access. Disable globally. Re-enable on a per-team basis only where there is a documented business need (e.g., a shared matter portal with a specific client). Unmanaged guest access creates persistent access that is difficult to audit.
• ✓Create a DLP Policy for PHI and PII: Compliance portal → Data Loss Prevention → Policies → Create Policy. Start with the HIPAA U.S. template. Configure to block external sharing and alert on email transmission of Social Security Numbers, credit card numbers, and health information (diagnosis codes, medication names, medical record numbers).
• ✓Enable Microsoft Purview Sensitivity Labels: Compliance portal → Information Protection → Labels. Create a 4-tier label hierarchy: Public, Internal, Confidential (PHI/Client), Highly Confidential. Apply encryption and access restrictions to Confidential and above. Train staff on labeling — this is a workflow change that requires communication, not just IT configuration.
• ✓Disable Personal Microsoft Account Connections: Entra ID → External Identities → External collaboration settings. Block invitations from personal Microsoft accounts. Staff should not be using their personal OneDrive or personal Outlook account to collaborate on patient or client matters.

Admin Account Hardening

• ✓Create Dedicated Admin Accounts: Admin tasks should be performed using a separate account from the user's daily email account. Admin accounts should not have Exchange mailboxes — attackers who compromise an admin account via phishing cannot pivot to email if there is no mailbox to read.
• ✓Create a Break-Glass Emergency Account: One Global Admin account with a strong random password, not subject to Conditional Access MFA policies, stored physically in a sealed envelope in a secure location. Used only if a misconfigured CA policy locks all admins out. Review access quarterly and rotate the password annually.
• ✓Enable PIM for All Admin Roles: Entra ID → Identity Governance → Privileged Identity Management. Convert all permanent admin role assignments to "eligible" — users must activate the role with a justification, and activation can be configured to require approval from a second admin and generate an alert.
• ✓Review and Revoke Unauthorized Admin Consent: Entra ID → Enterprise Applications → All Applications → filter by "Admin consent." Look for applications with permissions like "Read all users' mail," "Read and write all files," or "Full access to all mailboxes." Revoke any application you did not explicitly authorize.
• ✓Configure Risky User and Sign-In Alerts: Entra ID → Security → Identity Protection → Risky Users and Risky Sign-Ins. Configure email notifications to the Security Officer when a user is flagged as high risk. Set a Conditional Access policy to require password reset for high-risk users before they can access resources.

12-Question Vendor Security Questionnaire

Use this questionnaire for every new vendor — EHR, billing software, cloud backup, IT provider, marketing agency, transcription service, answering service — before signing a contract.

• •Do you sign a HIPAA Business Associate Agreement? If a vendor says a BAA is not necessary for their type of service, terminate the evaluation immediately. This response signals either HIPAA ignorance or a deliberate attempt to avoid legal accountability for your data.
• •Where is our data stored, and in which country? HIPAA does not explicitly prohibit offshore storage, but it creates complex questions about OCR jurisdiction, foreign law enforcement access, and breach notification. U.S.-hosted data is strongly preferred for healthcare and legal data.
• •How do you encrypt data at rest and in transit? Acceptable answer: AES-256 at rest, TLS 1.2+ in transit. Unacceptable answer: "Yes, we take security seriously" or "we use industry-standard encryption" without specifics.
• •What is your SOC 2 Type II audit status? A SOC 2 Type II report from a qualified CPA firm is the industry standard for cloud service providers handling sensitive data. Ask for the executive summary of the most recent report. A vendor who cannot produce one within the past 18 months has not been independently audited.
• •How do you manage subprocessors? Does the vendor use sub-vendors who also access your data? Are those subprocessors contractually bound by the same security obligations as the primary vendor? The Change Healthcare incident involved a subprocessor that was not adequately secured.
• •What is your breach notification commitment? Your BAA must specify a breach notification timeline — typically 24–72 hours to notify your practice, so you can meet your own OCR 60-day and Arizona 45-day notification deadlines. A BAA without a specific notification timeframe is a deficient BAA.
• •Do you conduct annual penetration testing? Ask for the executive summary of the most recent test and the remediation status of findings. Vendors who cannot produce this have not been tested. Vendors who can produce the test but not the remediation status have known vulnerabilities they have not fixed.
• •What access do your employees have to our data, and how is it controlled? Vendors should have role-based access controls, require MFA for all employees who can access customer data, and use least-privilege principles. Ask specifically: "Can a single vendor employee access all your customers' data, or only their assigned accounts?"
• •How do you handle data deletion at contract termination? You have a right to receive all your data and have it deleted from the vendor's systems. Get the specific process, timeline, and written confirmation in your contract.
• •Have you experienced a data breach in the past 3 years? A past breach does not disqualify a vendor — a poor response to a past breach does. Ask specifically: "What did you change after the breach? Can you walk me through what happened and how it was contained?"
• •What are your RTO and RPO commitments? Recovery Time Objective (how long before service is restored after an outage) and Recovery Point Objective (how much data can be lost) should be in the contract as service level commitments — not just marketing language about "high availability."
• •Do you maintain a software bill of materials (SBOM) for your platform? The Change Healthcare breach exploited a vulnerable third-party library. Vendors who cannot identify their software dependencies cannot tell you whether a newly disclosed vulnerability in an open-source library affects their platform.

BAA Required Elements Checklist (45 CFR §164.504(e))

Before signing, verify your BAA contains all of these elements. A template BAA missing any of these is legally insufficient.

• ✓Specifies the permitted uses and disclosures of ePHI — the BAA must enumerate exactly what the vendor is allowed to do with your data
• ✓Vendor agrees to use appropriate safeguards and comply with the applicable HIPAA Security Rule requirements
• ✓Vendor agrees not to use or disclose ePHI except as permitted or required by law
• ✓Vendor agrees to report breaches, security incidents, and unauthorized disclosures to your practice within the timeframe specified in the BAA
• ✓Vendor agrees to make ePHI available to support individual patient access rights upon your request
• ✓Vendor agrees to return or destroy all ePHI upon contract termination — and specifies the method and timeline
• ✓Vendor agrees to make its internal practices, books, and records available to HHS upon request
• ✓Vendor agrees to ensure that any subprocessors who receive ePHI are bound by equivalent BAA obligations
• ✓The BAA identifies your organization and the vendor by legal entity name — not "customer" or "client"
• ✓The BAA is signed by an authorized representative of the vendor with the authority to bind the organization legally

Red Flags — Walk Away Immediately

• ✗"A BAA is not necessary for our type of service" — this statement is factually incorrect for any vendor who accesses, stores, or transmits ePHI. It signals either HIPAA ignorance or deliberate evasion of legal accountability.
• ✗A template BAA that does not specify a breach notification timeframe — without a timeline, your vendor can discover a breach today and notify you 60 days later, leaving you unable to meet your own notification obligations.
• ✗Data stored in a third country without a clear explanation of the legal framework governing law enforcement access to that data, and without adequate contractual protections for your patients' rights.
• ✗Inability to produce a SOC 2 Type II report or equivalent third-party security audit from the past 18 months — absence of audit evidence is evidence of absence of security controls.
• ✗Security questionnaire responses that are vague, unverifiable, or consist primarily of marketing language — "We use industry-leading security" and "We take security seriously" are not answers to specific security questions.
• ✗Requests for admin-level access to your M365 tenant, EHR system, or network with no ability to scope or limit those permissions — legitimate IT vendors do not need permanent Global Admin access to manage your environment.