How We Build for HIPAA: The Controls and Processes Behind Sidebench’s Healthcare Application Development

We’ve shipped 60+ healthcare applications over the past 14 years, and every one of them runs on the same HIPAA compliance foundation: 47 controls across five Security Rule categories, built into the application layer from day one. This is a walkthrough of what those controls are, how we implement them, and why application-layer compliance is where most development teams fall short.

Last updated: May 2026
By: Kevin Yamazaki, Partner, CEO at Sidebench

---

Why 47 Controls? The Gap Between Hosting Compliance and Application Compliance

HIPAA compliance at the application layer requires implementing 47 distinct technical controls across five Security Rule categories defined in 45 CFR 164.312. Most development teams stop at 5-10 controls, usually the ones their cloud provider’s Business Associate Agreement (BAA) already covers. That leaves the other 37+ controls unaddressed, and those are the ones OCR investigates after a breach.

Here’s the misconception we run into constantly: teams assume that deploying on AWS with a BAA means they’re HIPAA compliant. They’re not. The cloud provider handles infrastructure-level controls, physical security, network isolation, storage encryption at rest. Your application is responsible for everything else. Access controls, audit logging, data integrity, transmission security, authentication, all of that lives in your code.

We wrote a full breakdown of this distinction in our pillar article on HIPAA application-layer compliance. What follows here is the specific implementation, what we build, how we build it, and why.

---

How We Handle Access Controls (45 CFR 164.312(a))

Access controls determine who can see, modify, or delete Protected Health Information (PHI) within an application. Under 45 CFR 164.312(a), covered entities must implement technical policies and procedures that restrict access to electronic PHI (ePHI) to authorized persons and software programs. We implement 12 controls in this category.

What that looks like in practice for us:

• Unique user identification. Every user gets a unique ID tied to their role. No shared accounts, no generic logins. Sounds basic, but we’ve inherited codebases where three admin accounts shared one email address.
• Role-based access control (RBAC). We define granular permission sets, a nurse sees different data than a billing coordinator, who sees different data than a patient. Permissions aren’t just “read/write”, they’re scoped to specific data types and patient relationships.
• Emergency access procedures. Break-glass protocols that grant temporary elevated access during emergencies, with automatic logging and mandatory post-access review.
• Automatic logoff. Session timeouts configured per risk level. A clinician workstation times out faster than a back-office analytics dashboard.
• Encryption at rest. AES-256 for all ePHI storage. Not just the database, temporary files, caches, logs, and backup systems too.

The mistake we see most often? Teams implement RBAC at the UI level but not at the API level. A user can’t click a button they shouldn’t see, but a curl command to the API returns everything. We enforce access controls at every layer, UI, API, database query, and background job.

---

How We Handle Audit Controls (45 CFR 164.312(b))

Audit controls require mechanisms to record and examine activity in systems containing ePHI. Under 45 CFR 164.312(b), you need hardware, software, and procedural mechanisms that record and examine access. We implement 8 controls here, and they’re the controls that matter most during an OCR investigation.

Our audit implementation:

• Immutable audit logs. Every access to ePHI, read, create, update, delete, gets logged with timestamp, user ID, IP address, data accessed, and action taken. Logs are write-once. Nobody can edit or delete them.
• Automated monitoring. Real-time alerts for suspicious patterns: bulk data exports, access outside business hours, repeated failed authentication attempts, privilege escalation attempts.
• Log retention. HIPAA requires 6 years minimum. We retain audit logs for 7 years in encrypted, geographically redundant storage. You’d be surprised how many teams delete logs after 90 days because their logging service gets expensive.
• Regular review cadence. Audit logs that nobody reads are useless. We build dashboards and scheduled reports so compliance teams can actually review access patterns without drowning in raw log data.

---

How We Handle Integrity Controls (45 CFR 164.312(c))

Integrity controls protect ePHI from improper alteration or destruction. Under 45 CFR 164.312(c), you need policies and procedures to protect electronic health information from unauthorized changes. We implement 7 controls in this category, focused on making sure data stays accurate from creation to archival.

Key implementations:

• Data validation at every input point. Server-side validation on all ePHI fields, type checking, range validation, format enforcement. Client-side validation is for UX. Server-side is for integrity.
• Checksums and hash verification. We use cryptographic hashing to verify data hasn’t been modified in transit or storage. If a record’s hash doesn’t match, the system flags it immediately.
• Version history. For clinical data, we don’t overwrite, we append. Every change creates a new version with the previous state preserved. This gives you a complete audit trail and the ability to restore data if something goes wrong.
• Automated backup verification. Backups that don’t restore are not backups. We run automated restore tests on a regular cadence and verify data integrity post-restore.

---

How We Handle Transmission Security (45 CFR 164.312(e))

Transmission security protects ePHI during electronic transmission over networks. Under 45 CFR 164.312(e), you need technical security measures to guard against unauthorized access to ePHI being transmitted. We implement 10 controls here, this is the area where we see the most gaps in teams we’ve audited.

• TLS 1.3 everywhere. All data in transit is encrypted with TLS 1.3. No exceptions, no fallback to older protocols.
• Certificate management. Automated certificate rotation, monitoring for expiration, and pinning for mobile applications.
• API security. Every API endpoint that touches ePHI requires authentication, is rate-limited, and validates request signatures. We use OAuth 2.0 with short-lived tokens for service-to-service communication.
• Internal service encryption. Microservice-to-microservice communication uses mTLS (mutual TLS). Even internal traffic is encrypted, because “internal” isn’t a security boundary.
• Secure file transfer. When integrating with EHR systems or health information exchanges, we use SFTP or HTTPS with client certificates. No unencrypted FTP. Ever.

The gap we see most frequently: teams encrypt the connection between browser and server but send ePHI in plaintext between internal services. If an attacker gets inside your network perimeter, that plaintext data is exposed. We treat every network boundary as untrusted.

---

How We Handle Authentication (45 CFR 164.312(d))

Person or entity authentication requires verifying that a person or entity seeking access to ePHI is who they claim to be. Under 45 CFR 164.312(d), you need procedures to verify identity before granting access. We implement 10 controls, and this category has changed the most in recent years with the rise of passwordless and biometric authentication.

• Multi-factor authentication (MFA). Required for all users who access ePHI. Not optional. Not “recommended.” Required. We support hardware tokens, authenticator apps, and biometric verification.
• Session management. Configurable session lengths based on risk context. Tokens are rotated on sensitive operations. Concurrent session limits prevent credential sharing.
• Password policies. Minimum 12 characters, breached password checking against known compromised credentials (we use the HaveIBeenPwned API), and forced rotation only on evidence of compromise, not arbitrary 90-day cycles, which actually reduce security.
• Biometric support for mobile. Face ID, Touch ID, and Android biometrics for native mobile apps. But biometric is always paired with a fallback that meets the same security standard.

---

Implementation Priority: What to Build First

Not all 47 controls carry equal weight. When we start a new HIPAA project, we prioritize based on breach risk and regulatory exposure. Here’s how we rank them.

Priority	Controls	Why	Timeline
Critical	Access controls, encryption (rest + transit), MFA, audit logging	OCR investigates these first after a breach. Missing any one is a finding.	Sprint 1-2
High	Integrity verification, session management, emergency access, backup validation	Required by the Security Rule. Protects against data loss and unauthorized modification.	Sprint 2-4
Important	Monitoring dashboards, log retention, certificate management, automated testing	Supports ongoing compliance and reduces long-term operational risk.	Sprint 3-6
Best Practice	Biometric auth, passwordless login, zero-trust internal networking, AI-powered anomaly detection	Exceeds minimum requirements. Differentiates organizations that take security seriously.	Sprint 4-8+

If you’re building a healthcare application that handles PHI, HIPAA compliance isn’t something you bolt on after launch. Companies come to us all the time asking to retrofit HIPAA compliance into products that weren’t designed for it, and it typically costs 3-5x more than building it in from day one. That’s before factoring in the risk: if you have a breach before you retrofit, the OCR doesn’t care about your product roadmap. It’s why we won’t ship an MVP without the Critical tier in place.

---

Case Study: PCIHIPAA’s 89% Reduction in Manual Work

PCIHIPAA (acquired by Rectangle Health) provides compliance management services for healthcare organizations. When they came to us, their compliance workflows were largely manual, staff spent hours on tasks that should’ve been automated. The application needed to handle sensitive compliance data (which falls under HIPAA) while dramatically improving operational efficiency.

We built a platform that automated the core compliance workflows, applying every control described in this article. The result? An 89% reduction in manual compliance work. But the part worth highlighting is that the security architecture didn’t slow down development. It accelerated it. Because when you build the controls into your framework from the beginning, every new feature inherits them automatically. You’re not negotiating compliance on every pull request.

Metric	Before	After
Manual compliance tasks	Hours per workflow	89% reduction
HIPAA controls implemented	Partial coverage	Full 47-control framework
Audit readiness	Multi-day preparation	Always audit-ready with immutable logs
Security architecture	Bolt-on, reactive	Built-in, proactive

---

When Should You Bring in a Specialist?

Internal teams can handle HIPAA compliance for straightforward applications, basic patient portals, simple scheduling tools, low-complexity data flows. But there are clear signs you need a partner with deep healthcare experience.

You probably need a specialist if:

• You’re integrating with an EHR system. Epic, Cerner, and athenahealth each have different integration models, certification requirements, and compliance considerations. If your team hasn’t done this before, the learning curve will blow your timeline.
• Your application handles PHI across multiple organizations. Multi-tenant healthcare applications face a different set of compliance challenges than single-organization tools. Data isolation, consent management, and access controls get significantly more complex.
• You’re building for behavioral health. Behavioral health applications must comply with both HIPAA and 42 CFR Part 2, which adds strict consent and disclosure requirements that most development teams haven’t encountered.
• You’re under a regulatory deadline. CMS, ONC, and state regulators all set compliance deadlines. If you’re racing the clock, you can’t afford a team that’s learning HIPAA on your project.
• Your last security audit found application-layer gaps. If your pentest report flagged issues in authentication, authorization, or data handling, not infrastructure, those are application problems that need application expertise.

If you’re at the point of evaluating partners, we’ve published a 15-criteria evaluation framework for healthcare technology partners that covers compliance depth, domain expertise, team structure, and outcome evidence.

---

FAQ

What does HIPAA compliant app development actually require?

HIPAA compliant app development requires implementing technical safeguards defined in 45 CFR 164.312 across five categories: access controls, audit controls, integrity controls, transmission security, and person/entity authentication. At Sidebench, we implement 47 specific controls across these categories, built into the application layer from the first sprint.

How many HIPAA controls should an application have?

The Security Rule doesn’t specify an exact number, it defines categories and required standards. We’ve mapped those requirements to 47 specific application-layer controls. Most development teams implement 5-10 and assume their cloud provider covers the rest. That assumption is wrong and creates liability.

What’s the difference between cloud compliance and application compliance?

Cloud compliance (via your provider’s BAA) covers infrastructure: physical security, network isolation, storage encryption. Application compliance covers everything your code does with ePHI: access controls, audit logging, data integrity, authentication, and transmission security. We’ve written extensively about this gap.

How much does HIPAA compliant development cost compared to non-compliant?

Building HIPAA compliance in from the start adds roughly 15-25% to development costs. Retrofitting compliance into an existing application costs 3-5x more because you’re rearchitecting data flows, rewriting authentication, and adding audit logging to code that wasn’t designed for it. For context, the average healthcare data breach costs $9.77 million (IBM/Ponemon 2024).

Does Sidebench sign Business Associate Agreements?

Yes. We operate as a Business Associate under formal BAAs with all healthcare clients. This means we’re legally bound to the same HIPAA requirements as covered entities for any ePHI we access during development, testing, and support.

What EHR systems has Sidebench integrated with?

We’ve built integrations with Epic, Cerner, athenahealth, CentralReach, CharmEHR, and several specialty EHR platforms. Each has different data structures and technical constraints.

How do you handle PHI in development and testing environments?

We never use real PHI in development or testing. We use synthetic data that mimics production data patterns without containing actual patient information. When debugging production issues, we use de-identified data extracts with all PHI stripped. Our development environments run the same security controls as production, because security habits built in development carry through to production code.

What happens if there’s a breach in an application Sidebench built?

Our applications are built with breach detection and response as core capabilities. Immutable audit logs mean we can determine exactly what data was accessed, by whom, and when. We support clients through the 60-day HIPAA breach notification process and work with their legal and compliance teams on remediation. Our architecture minimizes blast radius, if one component is compromised, data isolation prevents lateral movement to other patient records.

How long does it take to build a HIPAA-compliant application?

A focused healthcare application typically takes 4-8 months from discovery to launch. The HIPAA controls are built in parallel with product features, they don’t add months to the timeline when they’re part of the architecture from day one. Complex multi-system integrations (EHR, claims, eligibility) can extend timelines to 8-12 months.

Do you handle 42 CFR Part 2 compliance for behavioral health?

Yes. Behavioral health applications require compliance with both HIPAA and 42 CFR Part 2, which governs substance use disorder treatment records with stricter consent requirements than standard HIPAA. We’ve built this into platforms for organizations like Cortica and NOCD.

What security testing do you perform?

We run automated security scanning in our CI/CD pipeline (SAST and DAST), conduct regular penetration testing through third-party firms, and perform manual code review for all ePHI-handling components. We also run dependency vulnerability scanning and maintain a documented remediation SLA for critical findings.

Can you audit our existing application for HIPAA gaps?

Yes. We perform application-layer HIPAA assessments that map your current implementation against the 47-control framework. The output is a gap analysis with prioritized remediation recommendations. This is often the first step for organizations that built their MVP without dedicated HIPAA expertise and now need to close gaps before a compliance audit or customer security review.

---

Sidebench Perspective

Need Help Building HIPAA-Compliant Applications?

Whether you’re starting a new healthcare application or closing compliance gaps in an existing one, we’ve done this 50+ times. Bring us the hard questions.

Run a HIPAA application-layer audit using the 47-control framework →

---

Cited Data Sources

1. HIPAA Security Rule (45 CFR 164.312), Technical Safeguards Requirements
2. IBM/Ponemon Institute 2024, Cost of a Data Breach Report 2024
3. HHS Office for Civil Rights, Breach Notification Rule
4. ONC/ASTP 2024, Hospital EHR Adoption Quick Stats