HIPAA compliance is not a feature that can be added at the end of a healthcare software project. It is a chain of decisions about data, access, infrastructure, vendors, operations, and evidence. If one link is undefined, the product may look secure while leaving a material risk unowned.
This HIPAA compliance checklist is for product and engineering teams that create, receive, maintain, or transmit electronic protected health information (ePHI). It translates regulatory expectations into assignable, testable work.
Disclaimer: This checklist is not legal advice. Confirm HIPAA applicability, permitted uses and disclosures, contracts, and other legal obligations with qualified counsel and privacy or compliance leadership.
TL;DR
- Begin with data and the relationships around it.
- Then select safeguards.
- Preserve evidence.
- Make ownership explicit.
Does HIPAA apply to your product?
HIPAA applies to covered entities and business associates, including health plans, healthcare clearinghouses, and certain healthcare providers, and to business associates that perform functions or services involving protected health information on their behalf. A software company can therefore become a business associate because of what it does with data, not because its product is labeled “healthcare.” Subcontractors that handle PHI for a business associate may also have HIPAA obligations.
A useful scope review starts with four questions:
1. Who provides or sponsors the service? Identify the legal entities, not only the product brand.
2. Whose data enters the system? Determine whether information relates to an identifiable patient and comes from, or is handled for, a regulated entity.
3. What role does each party perform? Document covered entity, business associate, subcontractor, data controller, and service-provider relationships as applicable.
4. What other rules apply? Consumer health apps may fall outside HIPAA and still be subject to the FTC Act, the FTC Health Breach Notification Rule, state privacy laws, contractual restrictions, or 42 CFR Part 2.
“Not covered by HIPAA” does not mean “unregulated.” The HHS guidance on consumer health information is important for products near the HIPAA boundary.
Map PHI before selecting controls
A HIPAA compliance checklist for software development should begin with a data-flow map that the engineering team can validate against the actual system. Policy documents often describe the intended architecture. Logs, SDK configurations, support workflows, and backups reveal the real one.
For every PHI category, record this path: Source → processor → storage → integration → logs and analytics → backup → vendor → deletion.
Add the purpose, data elements, environment, protection method, retention period, access roles, and owner at each stage. Include exports, queues, caches, search indexes, observability platforms, temporary files, and disaster-recovery copies. A complete map should show where a patient record can appear and who can act on it.
Figure 1. PHI data-flow map: nine stages, each with PHI elements, access role, retention, and evidence, plus the accidental-disclosure path through errors, crash reporting, and support tickets. Example values. Custom visual by Intelisoft.
Translate safeguards into engineering work
The current HIPAA Security Rule requires administrative, physical, and technical safeguards for ePHI. It is intentionally flexible and technology-neutral. That flexibility does not remove the need for concrete decisions; it requires the organization to connect its risk analysis to reasonable and appropriate measures. This safeguard overview can serve as the first layer of a HIPAA compliance requirements checklist:
| Safeguard area | What the organization must verify | Engineering implementation | Evidence to retain | Primary owner |
|---|---|---|---|---|
| Administrative | Risks are assessed and managed; responsibilities and procedures are assigned | Risk register, access lifecycle, security review gates, incident runbooks, contingency planning | Approved risk analysis, treatment decisions, review records, training records | Security or compliance lead |
| Physical | Facilities, workstations, and devices that access ePHI are appropriately protected | Device management, secure workstation rules, media handling, remote-work controls | Device inventory, MDM status, disposal records, facility procedures | IT and operations |
| Technical | Access, audit, integrity, authentication, and transmission protections address identified risks | Identity controls, audit events, encryption, integrity checks, secure protocols, session controls | Configurations, test results, logs, access reviews, key-management records | Engineering and security |
Secure SDLC checklist
A HIPAA compliance checklist for software should be visible in delivery work, not kept only in a compliance folder.
01
Plan and design
Classify data, update the PHI flow, identify legal and contractual constraints, define abuse cases, and complete a threat model. Architecture review should cover:
- Tenant isolation
- Trust boundaries
- Privileged paths
- Third parties
- Failure modes
- Deletion
Every significant risk needs an owner and a decision.
Build and review
Apply peer review, branch protection, dependency controls, secret scanning, static analysis, secure defaults, and infrastructure-as-code review. Test authorization at the resource level.
Keep PHI out of
Source repositories, build logs, test fixtures, and developer tools
Use outside production
Synthetic or properly de-identified data, whenever possible
03
Verify and release
Run security tests proportionate to risk, including API authorization, tenant isolation, session management, input handling, sensitive-data exposure, dependency risk, and resilience. Resolve high-impact findings or document an approved treatment before launch.
Confirm that audit events, alerts, backups, restore procedures, and incident contacts work in the production configuration.
Operate and change
Revisit risk when architecture or data use changes. Monitor:
Security events and vulnerabilities
Vendor changes and access
Control health
A HIPAA compliance technology checklist should be part of release governance.
What shows the system still works
Recurring evidence collection is what shows the system continues to operate as designed.
Technical safeguards checklist
The following HIPAA compliance software checklist focuses on controls that product and platform teams can implement and verify. Use the same HIPAA compliance software checklist to record evidence; the final control set must follow the organization’s risk analysis.
Figure 2. Safeguard-to-evidence matrix: each obligation links to an implemented control, a retained artifact, and an accountable role. Custom visual by Intelisoft.
Technical safeguards
1. Identity and Access Control
Area 1 of 5
Obligation to verify
ePHI is available only to authorized people and systems, with unique user identification and appropriate access management.
Engineering implementation
Use unique identities; role- or attribute-based permissions; least privilege; separate privileged accounts; strong authentication; time-limited service credentials; session timeout and revocation; controlled emergency access; and prompt joiner, mover, and leaver workflows. Keep authorization enforcement on the server. Test cross-tenant and object-level access, not only page visibility.
Evidence
Access matrix, identity-provider settings, privileged-role inventory, access-review records, termination test, authorization test cases, and emergency-access procedure.
Owner
Identity platform owner with application engineering and security.
2. Audit Controls and Activity Review
Area 2 of 5
Obligation to verify
Systems can record and examine activity involving ePHI, and the organization regularly reviews relevant system activity.
Engineering implementation
Define auditable events before release. Record authentication, access to patient records, creation, update, export, deletion, permission changes, administrative actions, and security-relevant failures. Capture actor, action, subject, timestamp, source, result, and correlation ID without placing unnecessary PHI in the event. Protect logs from alteration and apply a documented retention policy.
Evidence
Event catalog, sample audit records, integrity and retention settings, alert rules, review schedule, completed review records, and tests showing that critical events are generated.
Owner
Application engineering for event quality; security operations for monitoring and review.
3. Integrity Protection
Area 3 of 5
Obligation to verify
ePHI is protected from improper alteration or destruction.
Engineering implementation
Validate inputs and state transitions; use database constraints and controlled migrations; protect messages against replay or silent loss; reconcile critical interfaces; version important clinical records; and make destructive actions deliberate and traceable. Where risk warrants it, use checksums, signatures, immutable storage, or append-only records.
Evidence
Integrity threat model, validation tests, reconciliation reports, migration approvals, recovery tests, and audit samples for record changes.
Owner
Data and application engineering.
4. Person or Entity Authentication
Area 4 of 5
Obligation to verify
The system can establish that a person or service is who it claims to be.
Engineering implementation
Use an approved identity provider, phishing-resistant authentication for privileged access where feasible, managed machine identities, certificate or workload identity for service-to-service calls, protected recovery flows, and rate limiting. Avoid shared users and long-lived secrets embedded in code or deployment files.
Evidence
Authentication architecture, MFA policy, recovery-flow tests, service-account inventory, secret rotation records, and penetration-test findings with remediation.
Owner
Identity and platform engineering.
5. Transmission and Storage Protection
Area 5 of 5
Obligation to verify
Safeguards address unauthorized access to ePHI transmitted over electronic networks and risks to stored data.
Engineering implementation
Encrypt data in transit with current protocols; encrypt storage, backups, and portable media where reasonable and appropriate; manage keys separately from protected data; restrict network paths; rotate certificates and secrets; and prevent sensitive payloads from appearing in URLs. Document any decision not to use an addressable implementation specification and the equivalent measure, where required.
Evidence
Data-flow diagram, transport scans, cloud encryption settings, key policies, rotation logs, exception decisions, and restore results.
Owner
Platform engineering and security architecture.
Administrative safeguards for engineering teams
Administrative safeguards turn technical controls into a managed program. The core is an accurate and thorough risk analysis followed by risk management. A scanner report alone rarely covers people, vendors, workflows, facilities, data movement, and operational dependencies. Use this software HIPAA compliance checklist during planning and recurring reviews. It also supplies the operational layer of the HIPAA compliance requirements checklist:
Maintain a system and data inventory that matches deployed environments.
Assign security responsibility and decision authority.
Record threats, vulnerabilities, likelihood, impact, existing controls, residual risk, treatment, owner, and due date.
Define workforce access approval, review, and termination procedures.
Train personnel for their roles, including engineers who can access production data.
Establish incident identification, escalation, containment, evidence preservation, and communication procedures.
Maintain contingency plans for backup, disaster recovery, emergency operation, and restoration priorities.
Evaluate safeguards periodically and after material product, infrastructure, vendor, or threat changes.
Keep policies, decisions, tests, and review records available for the required retention period determined by the organization.
Product changes should feed this process. A new analytics SDK, generative AI feature, overseas support team, or data export can alter HIPAA scope even when the release adds no clinical functionality.
Physical, endpoint, and remote-work controls
Cloud architecture does not eliminate physical safeguards. People still reach ePHI through workstations, phones, home networks, support consoles, and removable media.
Endpoint and device controls
The HIPAA compliance checklist for information technology should cover managed-device enrollment, full-disk encryption, screen locking, patching, endpoint detection, local administrator restrictions, remote wipe, removable-media policy, secure disposal, and inventory reconciliation.
01
Production access and facilities
Define where production access is permitted and how exceptional access from an unmanaged device is blocked or contained. For offices and data centers under the organization’s control, align facility access and visitor procedures with risk.
02
Evidence and ownership
Evidence can include endpoint compliance reports, device and media inventories, disposal certificates, access records, and a tested response for a lost device. The IT owner should work with security and workforce managers because the control fails when an approved device remains active after a role change.
03
Building software that handles PHI?
Tell us how data moves through your product. We will help turn safeguards into testable engineering work and evidence.
BAAs and third-party risk
A business associate agreement is necessary in many vendor relationships involving PHI.
Who handles the PHI?
Business associates
What HHS says
HHS permits disclosure to a business associate with satisfactory written assurances, and business associates have direct obligations under parts of the HIPAA Rules.
Main caution
A signed BAA does not prove that the service is configured or operated safely.
Cloud service providers
What HHS says
Main caution
Encryption does not remove the need to evaluate the relationship and execute the required agreement.
Mobile access to ePHI
What HHS says
Main caution
Mobile products add risks that a web-only review may miss.
For every vendor that handles PHI, verify:
| # | What to verify |
|---|---|
| 01 | The legal role and whether a BAA or subcontractor agreement is required. |
| 02 | The exact service, account, region, feature, and support model covered by the agreement. |
| 03 | Permitted uses, disclosure limits, incident reporting, return or destruction, and subcontractor terms. |
| 04 | Access paths available to vendor personnel and the customer’s ability to restrict them. |
| 05 | Encryption, authentication, logging, resilience, retention, and deletion settings. |
| 06 | Evidence supplied by the vendor and gaps that the customer must address. |
| 07 | An exit plan for data export, deletion, access revocation, and continuity. |
The owner is usually procurement or legal for the contract and security or engineering for technical due diligence. Retain the executed agreement, assessment, architecture decision, configuration evidence, exception record, and offboarding plan.
Hidden PHI leak review
Some of the most consequential exposures happen outside the primary database. For each surface, either prevent PHI from entering it or treat the system as part of the regulated data environment.
Redaction should be tested with representative edge cases, not assumed from a configuration flag.
| Surface | What to review |
|---|---|
| Application and infrastructure logs | Request bodies, query strings, authorization headers, identifiers, stack traces, and database error messages. |
| Crash and error reporting | Screenshots, session replay, breadcrumbs, device metadata, and user-entered text. |
| Analytics and marketing tools | Page URLs, form fields, device IDs, IP addresses, event properties, and user profiles. |
| Notifications | Lock-screen previews, email subject lines, SMS content, and push payloads. |
| Test environments | Production copies, synthetic data quality, developer laptops, fixtures, and screenshots in tickets. |
| Support and collaboration tools | Attachments, screen recordings, chat transcripts, issue trackers, and copied SQL results. |
| Exports and integrations | Spreadsheets, SFTP folders, webhook retries, dead-letter queues, and vendor dashboards. |
Mobile application checklist
Review local storage, offline mode, cached images and documents, screenshots, clipboard use, notification previews, deep links, biometric fallback, session handling, rooted or jailbroken devices, application logs, analytics SDKs, backups, and remote revocation. Decide what happens when a device is lost, a user leaves, connectivity fails during a clinical action, or an app version is no longer supported.
Evidence should include a mobile threat model, data-storage inventory, SDK review, platform security settings, device test matrix, API authorization results, and lost-device exercise. Mobile and backend owners share responsibility: local controls cannot compensate for an API that returns another patient’s record.
Current rule and proposed Security Rule changes
“Teams may use proposed requirements to improve readiness, but should label them accurately and track the rulemaking process.”
Intelisoft engineering team
As of October 13, 2026, the December 2024 HHS proposal to strengthen the HIPAA Security Rule has not been finalized. HHS states that the current Security Rule remains in effect. The HHS NPRM fact sheet lists the proposed technical changes summarized below.
Teams can prepare without claiming a legal deadline: inventory assets, improve network maps, expand MFA, validate encryption, exercise recovery, and formalize recurring testing.
“Legal and compliance owners should decide which proposal-driven measures enter the control baseline.”
Intelisoft engineering team
Figure 3. Current Security Rule (in effect) versus the December 2024 proposal (not final). No effective date is implied. Custom visual by Intelisoft.
| Topic | Current Security Rule | December 2024 proposal (not final) |
|---|---|---|
| Risk analysis | Accurate and thorough assessment of risks and vulnerabilities to ePHI | More prescriptive written analysis, including technology asset inventory and network map |
| Encryption | Addressable specifications evaluated through risk-based decisions | Encryption of ePHI at rest and in transit, with limited exceptions |
| Authentication | Person or entity authentication required; implementation follows risk | Multi-factor authentication, with limited exceptions |
| Network architecture | Safeguards selected through risk analysis and management | Network segmentation; review and testing of certain security measures at least once every 12 months |
| Testing | Periodic technical and nontechnical evaluation | Annual compliance audit, annual penetration testing, and vulnerability scanning at least every six months |
| Recovery | Contingency planning, backup, disaster recovery, and emergency-mode operations | More specific recovery procedures and restoration timeframes, with separate backup controls |
| Business associates | Contracts and applicable direct Security Rule duties | Annual verification from business associates that required technical safeguards are deployed |
Intelisoft experience
At Intelisoft, healthcare delivery work begins with workflows, data movement, and operating constraints.
Ambient clinical documentation
Source: Intelisoft project data.
That experience informs how Intelisoft uses a HIPAA compliance checklist for software development: trace data through the real workflow, assign controls to system boundaries, test operational failure paths, and collect evidence during delivery. The same method applies to patient portals, remote monitoring, telemedicine, clinical workflow tools, and interoperability platforms.
Trace data
Through the real workflow
Assign and test controls
Boundaries and failure paths
Collect evidence
During delivery
What it is
What it is not
Project outcomes
A demonstration of engineering capability
A certification or legal conclusion about another environment
Intelisoft’s role
Making approved privacy and security requirements concrete in software, infrastructure, tests, and operating procedures
A replacement for legal counsel or the covered entity’s compliance function
Case example: ambient clinical documentation
Healthcare
Ambient clinical documentation
Epic and Cerner
A technically strong control can still obstruct care or encourage an unsafe workaround.
Build the evidence pack before production
Compliance cannot be assessed from intended behavior alone. Evidence should show what was decided, what is deployed, what was tested, and who reviewed the result. The following pre-production pack makes the HIPAA software compliance checklist usable during an approval meeting:
01
Applicability and data scope
Role analysis, PHI inventory, approved data-flow map, retention and deletion rules.
02
Risk analysis and treatment
Current risk register, control decisions, accepted residual risks, owners, and dates.
03
Access package
Role matrix, privileged identities, approval flow, access review, termination test, emergency access.
04
Vendor package
Vendor register, BAAs, technical assessments, approved services, subprocessors, and exit plans.
05
Audit package
Event catalog, sample records, retention and integrity settings, alerts, and completed activity review.
06
Resilience package
Backup configuration, restore test, recovery responsibilities, dependency plan, and exercise results.
07
Incident package
Severity model, contacts, escalation path, evidence handling, communication decision process, and exercise record.
08
Security test package
Threat model, code and dependency results, penetration or application security tests, remediation evidence, and accepted exceptions.
09
Operations package
Monitoring, vulnerability management, patching expectations, endpoint status, training, and recurring review calendar.
Figure 4. Pre-production readiness pack: nine evidence groups around the release decision, each with an owner, evidence date, and status. Example statuses. Custom visual by Intelisoft.
The HHS risk-analysis guidance and NIST SP 800-66 Rev. 2 provide useful reference points. NIST’s publication maps Security Rule requirements to cybersecurity resources, but it does not replace the regulation or organization-specific analysis.
Cloud HIPAA checklist
HHS allows regulated entities to use cloud services when appropriate safeguards and business associate arrangements are in place. Shared responsibility remains central: the provider secures its service; the customer still owns identity, configuration, data use, and much of application behavior. Use this HIPAA compliance IT checklist for each production account and connected service:
Review item
Implementation question
Evidence · owner
Contract and scope
Is the service that handles ePHI covered by the correct BAA and account terms?
Identity
Are workforce and workload identities unique, least-privileged, and reviewed?
Data protection
Are databases, object stores, queues, backups, and transfers protected according to risk?
Network boundaries
Are public exposure, administrative paths, segmentation, and egress controlled?
Logging
Do control-plane and data-plane events reach protected monitoring with useful retention?
Resilience
Can the team restore critical services and data within approved objectives?
Deletion
Can ePHI be removed from active stores, caches, exports, and vendor systems under policy?
What clients say about Intelisoft
Frequently asked questions
Determine whether HIPAA applies to the organization, product, and data relationship, then map PHI and ePHI. Control selection comes after scope. Without a reliable map, teams can secure the primary database while missing data in logs, analytics, integrations, backups, or support systems.
No. A BAA defines responsibilities and permitted handling of PHI, but the parties still need appropriate administrative, physical, and technical safeguards. The customer must also configure and use the service correctly. Review the agreement, the exact service scope, technical controls, incident terms, subprocessors, and exit plan together.
Under the current Security Rule, encryption-related implementation specifications are addressable, which means the regulated entity evaluates whether they are reasonable and appropriate and documents its decision and any equivalent measure. This does not make encryption optional by default. The risk analysis, data paths, threats, and consequences should drive the decision. The 2024 proposal would make encryption at rest and in transit more explicit, with limited exceptions, but that proposal is not final as of October 13, 2026.
Start with authentication, access to patient information, record creation and changes, exports, deletion, permission changes, administrative actions, consent-related events where relevant, and security failures. An event should identify the actor, action, subject, time, source, result, and correlation context while avoiding unnecessary PHI in the log itself. Teams should also prove that events are reviewed, not merely stored.
Production PHI should not become the default test dataset. Use synthetic or properly de-identified data where it can meet the testing purpose. When a production issue genuinely requires restricted data access, apply an approved procedure with minimum necessary access, time limits, auditing, secure tools, and prompt cleanup. The organization’s privacy, security, and legal owners should define the governing rules.
The current rule requires an accurate and thorough assessment and periodic evaluation; it does not create one universal calendar interval for every organization. Update the analysis when material changes occur and review it on a defined recurring schedule. New vendors, architecture changes, acquisitions, AI features, expanded data use, and serious incidents are clear triggers.
No. A cloud provider can supply eligible services, contractual terms, and security capabilities, but the customer remains responsible for its architecture, identity model, configuration, application code, data use, monitoring, and operating procedures. Verify that the specific service is covered by the agreement and collect evidence from the deployed account.
At minimum, the release decision should have an approved PHI flow, current risk analysis, access matrix, vendor and BAA register, audit-event evidence, restore test, incident procedure, security test results, and named owners for unresolved risks. A production checklist should reference actual artifacts and dates rather than rely on a general statement that the system was built with HIPAA in mind.
Track the HHS rulemaking and keep current obligations separate from proposal-driven readiness work. Asset inventory, network mapping, MFA, encryption, segmentation, security testing, recovery exercises, and vendor verification are sensible areas to mature. Legal and compliance teams should determine when these measures become internal requirements and update the control baseline accordingly.
How Intelisoft can help
For an existing product, Intelisoft can assess technical gaps and prioritize remediation. For a new product, the team can incorporate safeguards and evidence into the delivery plan from the first architecture decisions.
Sources
- HHS, Covered Entities and Business Associates
- HHS, HIPAA and the FTC Act
- FTC, Health Breach Notification Rule
- HHS, 42 CFR Part 2
- HHS, Online Tracking Technologies
- HHS, HIPAA Security Rule
- HHS, Sample BAA Provisions
- HHS, Cloud Computing Guidance
- HHS, Mobile Devices and ePHI in the Cloud
- HHS, Security Rule NPRM
- HHS, NPRM Fact Sheet
- HHS, Risk Analysis Guidance
- HHS, Is Encryption Mandatory?
- NIST SP 800-66 Rev. 2
HHS/OCR and NIST sources checked October 13, 2026. The December 2024 Security Rule proposal was not final at that date. This article is not legal advice.
