How healthcare organizations manage HIPAA AppSec requirements with automated scanning

Key takeaways

• The current HIPAA Security Rule requires covered entities and business associates to assess risks to ePHI and reduce them to a reasonable and appropriate level. It does not prescribe a scanning product or fixed scan frequency.
• A proposed update would require vulnerability scanning at least every six months and penetration testing at least annually if finalized as written. As of July 2026, the proposal is not final.
• Network scanners find host, service, and configuration weaknesses. They generally cannot test application behavior such as cross-patient access, broken sessions, or vulnerable API input handling.
• Healthcare application security testing should include patient portals, FHIR APIs, EHR integrations, payment applications, and business associate systems that handle ePHI.
• Automated DAST can support recurring assessment, authenticated coverage, remediation workflows, retesting, and technical evidence. It does not establish HIPAA compliance by itself.

What HIPAA currently requires

The current HIPAA Security Rule does not require a specific scanning product or define a universal scanning frequency. Its security management process under 45 CFR §164.308(a)(1) requires covered entities and business associates to:

• Conduct an accurate and thorough assessment of risks and vulnerabilities to the confidentiality, integrity, and availability of ePHI
• Implement security measures sufficient to reduce identified risks and vulnerabilities to a reasonable and appropriate level
• Apply sanctions for workforce noncompliance
• Regularly review information system activity

The periodic evaluation standard under §164.308(a)(8) also requires technical and non-technical evaluations in response to environmental or operational changes that affect ePHI security.

HHS describes risk analysis as the first step in identifying and implementing safeguards under the Security Rule. The rule applies to ePHI created, received, maintained, or transmitted by covered entities and business associates.

For application security, this means understanding the risks introduced by the systems that process ePHI, not only the infrastructure hosting them. Relevant questions include:

• Does the application enforce authentication across every protected function?
• Can one user access another user’s records?
• Can an API token retrieve resources outside its intended scope?
• Does untrusted input reach a database, interpreter, or operating system command?
• Do URLs, error messages, logs, or third-party scripts expose sensitive information?
• Do security controls remain effective after a release, integration change, or identity-provider migration?

DAST can provide evidence about many observable application behaviors. It does not evaluate every administrative, physical, or technical safeguard required by HIPAA.

Why the OCR Risk Analysis Initiative matters now

The proposed HIPAA update attracts attention because it would introduce explicit scanning and testing requirements. Current enforcement provides the more immediate reason to improve application security.

The Office for Civil Rights (OCR) has repeatedly used its Risk Analysis Initiative to address failures to conduct accurate and thorough risk analysis. In April 2026, OCR announced four ransomware settlements that brought the initiative to 13 completed investigations. A June 2026 settlement with an employer-sponsored health plan marked its 14th enforcement action under the initiative.

These actions reinforce the need to show that an organization:

• Identified systems that store, process, or transmit ePHI
• Assessed risks affecting those systems
• Implemented safeguards in response
• Documented remediation or accepted-risk decisions
• Reassessed controls after incidents and material changes

An inventory limited to servers, operating systems, and network devices may overlook applications and APIs that expose ePHI to users and partner systems. A scan report with no assigned owner, remediation record, or retest result also provides little evidence that the organization managed the identified risk.

For security leaders, the goal is broader than scheduling scans. It is establishing a traceable process from asset identification through testing, remediation, verification, and reporting.

What the proposed HIPAA Security Rule could change

HHS announced a proposed update to the HIPAA Security Rule on December 27, 2024. The Notice of Proposed Rulemaking was published in the Federal Register on January 6, 2025. As of July 2026, the proposal is not final and its provisions are not enforceable as current law.

If finalized as written, it would introduce requirements including:

• Vulnerability scanning at least once every six months
• Penetration testing at least once every 12 months
• Additional technical assessment after relevant environmental or operational changes
• Broader encryption requirements
• Multi-factor authentication, subject to limited exceptions
• More detailed documentation and verification requirements

HHS lists the scanning and penetration-testing requirements in its NPRM fact sheet.

The OMB Unified Agenda entry for RIN 0945-AA22 places the rule under long-term actions and lists July 2027 as the projected date for final action. That is a planning estimate, not a binding deadline. The proposal could change, be delayed further, or be withdrawn.

Healthcare organizations should prepare for more prescriptive requirements without describing them as current obligations.

Why network scanning alone does not cover HIPAA application security

Infrastructure vulnerability scanners examine operating systems, network services, installed packages, protocols, and configurations. They help find missing patches, known software vulnerabilities, exposed ports, and weak network settings.

DAST interacts with a running web application or API. It examines requests, responses, sessions, parameters, authentication flows, and application behavior. The two forms of testing are complementary:

A healthcare security program generally needs both infrastructure and application-layer visibility. Running one does not substitute for the other.

Which healthcare applications and APIs need security testing?

Start with an inventory of applications and APIs that store, process, transmit, or provide access to ePHI.

Patient portals

Patient portals expose lab results, medications, clinical notes, appointments, messages, billing information, and uploaded documents. Testing should cover:

• Authentication and account recovery
• Session expiration and invalidation
• Horizontal authorization between patient accounts
• Vertical authorization between patient, workforce, and administrative roles
• Input handling in search, messaging, scheduling, and upload functions
• Data exposure through URLs, errors, logs, and client-side code
• Third-party scripts and analytics technologies

Third-party tracking is a useful example of an application-layer data-flow problem. In April 2025, Blue Shield of California disclosed that Google Analytics had been configured in a way that allowed certain member data to be shared with Google Ads. The potentially affected data included insurance information, claim details, patient financial responsibility, and provider-search criteria.

That type of exposure is not caused by a missing operating system patch. It arises from how an application, its pages, and third-party components process and transmit information.

FHIR APIs

Fast Healthcare Interoperability Resources (FHIR) APIs are a mainstream part of healthcare interoperability. The ONC Health IT Certification Program’s standardized API criterion references FHIR, SMART App Launch, US Core, OpenID Connect, and bulk-data standards.

FHIR APIs can expose resources containing:

• Patient demographics
• Observations
• Diagnostic reports
• Medications
• Claims
• Appointments
• Clinical documents

Testing should examine authentication, scope enforcement, object-level authorization, input handling, data minimization, and bulk access.

A common risk is broken object level authorization (BOLA). An API may confirm that a requester is authenticated but fail to verify access to a specific resource. As an example, take a request based only on a resource ID:

GET /Observation/123

If a patient can change the resource identifier and retrieve another patient’s result, the API has crossed an authorization boundary and possibly has a BOLA vulnerability.

Testing this scenario requires controlled accounts, known test data, and separate authenticated contexts. The tester needs to compare what Patient A can access against what Patient B can access. The same principle applies to clinicians, administrators, and partner applications.

EHR and clinical integration APIs

Electronic health record environments connect to laboratories, pharmacies, billing platforms, imaging systems, decision-support tools, and other services. These integrations may include:

• REST APIs
• SOAP services
• Legacy web interfaces
• Service accounts
• Shared credentials
• Deprecated endpoints
• Undocumented or shadow APIs

Testing should verify authentication, authorization, input handling, data minimization, and exposed legacy functionality. Discovery matters because deployed endpoints do not always match current documentation.

Payment and billing applications

Healthcare payment applications may handle both ePHI and payment card information. Security teams should define which components fall within HIPAA and Payment Card Industry Data Security Standard (PCI DSS) scope, then test the application and API paths that cross those boundaries.

Business associate systems

Business associate portals and integrations can expose claims, billing records, clinical data, or patient communications. Covered entities should distinguish between:

• Vendor-operated systems they cannot test without authorization
• Customer-managed configurations and integrations they can test
• Security evidence they need from the business associate
• Responsibilities documented in the business associate agreement

The goal is to establish responsibility, evidence, and coverage across the full ePHI data flow – not to test a third party without permission.

How to build a risk-based HIPAA application security program

A useful program connects five activities: inventory, testing, prioritization, remediation, and evidence.

1. Inventory applications and APIs

For each asset, record:

• Business and technical owner
• Internet exposure
• Authentication method and user roles
• Types of ePHI handled
• Integrations and data flows
• Business criticality
• Last security assessment
• Testing restrictions

Automated discovery can help identify unknown websites, APIs, and services. Results still require validation and ownership assignment.

2. Define risk-based testing coverage

Testing depth and frequency should reflect:

• Exposure
• ePHI sensitivity
• Clinical and business impact
• Release frequency
• Architecture changes
• Previous findings
• Operational constraints

These are program-design examples, not HIPAA requirements. Each organization should document why its cadence is reasonable for the asset and risk.

3. Configure authenticated and role-based testing

Public scans cover only the unauthenticated surface. Most ePHI functionality sits behind login, OAuth tokens, identity providers, and role-specific permissions. Authenticated testing may require:

• Controlled test accounts
• Recorded login sequences
• OAuth or OpenID Connect tokens
• API keys or client credentials
• Session renewal
• Multi-factor authentication handling
• API specifications
• Role-specific workflows
• Safe test data

Authorization testing should include multiple controlled identities where practical. A single authenticated session cannot show whether an application correctly separates two patients or two provider roles.

4. Route findings into remediation

A useful finding should identify:

• The affected application and function
• The request and response involved
• Severity and likely impact
• Whether exploitation was verified
• The owning team
• The remediation deadline
• The retest result

Prioritization should account for reachability, exploitability, ePHI exposure, business criticality, and compensating controls rather than relying on severity scores alone.

5. Retest and retain evidence

Closing a ticket does not verify that the deployed application is fixed. A defensible record connects:

1. The original finding
2. The assigned owner
3. The remediation decision
4. The corrected deployment
5. The retest result
6. Any residual risk
7. The closure date

Application security documentation may include policies, risk-analysis inputs, scan reports, remediation records, exceptions, and evaluation evidence.

What security leaders should be able to show

A useful application security evidence package should answer four questions.

What was in scope?

Record the applications and APIs tested, their ePHI classification, the environment, authentication status, roles covered, exclusions, and testing limitations.

What was found?

Retain the scan date and policy, affected assets, vulnerability details, application context, available verification evidence, and any duplicate or false-positive decisions.

What happened next?

Show ownership, remediation deadlines, corrective actions, accepted-risk decisions, compensating controls, retest results, and closure dates.

How is the program governed?

Useful operational measures include:

• Percentage of ePHI applications with an owner
• Percentage covered by authenticated testing
• Time to triage high-impact findings
• Mean time to remediate confirmed vulnerabilities
• Percentage of fixes successfully retested
• Applications with overdue testing or remediation

The total number of findings is not a reliable security metric by itself. More findings may reflect better coverage rather than a worsening security posture.

Automated scanning and penetration testing serve different purposes for HIPAA

DAST provides repeatable coverage across applications and releases. Penetration testers apply human reasoning to complex business logic, chained attack paths, architectural weaknesses, and unusual abuse cases.

DAST is well suited to recurring vulnerability testing, broad web and API coverage, regression testing, workflow integration, structured reporting, and retesting. Penetration testing adds depth for business logic, chained exploits, trust boundaries, and complex authorization models.

A mature program uses both. The proposed HIPAA update reflects this distinction by listing vulnerability scanning and penetration testing as separate activities.

How Invicti supports HIPAA application security

The Invicti Application Security Platform helps healthcare organizations discover, test, prioritize, manage, and remediate vulnerabilities across web applications and APIs.

Its DAST-first approach starts with the behavior of running applications. This gives security leaders an outside-in view of vulnerabilities exposed through deployed functionality, independent of the languages and frameworks used to build the application.

Effective coverage depends on appropriate scope, authentication, roles, and test data. Complex clinical permissions and business logic may still require manual assessment.

Discover and test applications and APIs

Invicti combines web application and API discovery with automated security testing. Teams can use discovery to identify known and previously untracked assets, validate ownership, and bring more of the application attack surface into a consistent testing process.

Authenticated scanning extends testing beyond public pages to protected portal functions and API endpoints. Relevant healthcare targets can include:

• Patient and member portals
• FHIR and other REST APIs
• SOAP services
• GraphQL APIs
• EHR integration points
• Business associate applications
• Billing and payment applications

For authorization testing, teams can configure controlled patient, provider, or administrative identities and use authenticated workflows to assess whether protected functions and API resources remain separated between roles. This provides the application context needed to investigate object-level authorization weaknesses that infrastructure scanners cannot evaluate. 

Focus on actionable risk with proof-based scanning

Automated scanners can create significant manual work when findings lack reliable verification. For supported vulnerability classes, Invicti’s proof-based scanning can safely confirm exploitability and attach evidence to the finding. For a supported injection vulnerability, for example, the result can include the request, test payload, and application response that confirmed the issue.

This gives developers a reproducible starting point for remediation and helps security teams separate confirmed application risk from findings that still need investigation.

Not every vulnerability can or should be automatically exploited – but where verification is available, it reduces reproduction work and improves remediation confidence.

Connect findings to development workflows

Invicti integrates application testing with CI/CD systems, issue trackers, and development workflows. Teams can use these integrations to trigger appropriate scans, route findings, track remediation, and retest fixes.

This helps turn application security from an isolated assessment activity into a repeatable operating process.

Centralize risk with Invicti ASPM

Invicti ASPM centralizes findings across application security tools, correlates and deduplicates results, applies risk-based prioritization, and provides consolidated visibility. For healthcare security leaders, that helps answer practical questions:

• Which ePHI applications have unresolved high-impact findings?
• Which assets lack recent authenticated testing?
• Which teams are missing remediation targets?
• Which vulnerabilities recur across applications?
• Where does application risk concentrate across business units?

Support HIPAA reporting

Invicti provides built-in HIPAA compliance reporting that organizes relevant technical findings against HIPAA-related requirements. These reports can help teams:

• Present application scan results in a consistent format
• Connect technical findings to compliance-oriented categories
• Support risk-analysis and periodic-evaluation workflows
• Track relevant findings over time
• Prepare technical evidence for internal reviewers, auditors, or assessors

A HIPAA report does not certify compliance. It supplies structured technical evidence that the organization can combine with policies, risk decisions, access reviews, incident records, workforce controls, and other required documentation.

Improve application security before requirements become more prescriptive

Patient portals and FHIR APIs expose application behaviors that infrastructure scanners cannot evaluate. Healthcare security leaders need a repeatable way to test those systems, prioritize meaningful risk, verify fixes, and preserve evidence.

The current HIPAA Security Rule already requires risk analysis, reasonable and appropriate safeguards, periodic evaluation, and documentation. OCR enforcement already focuses on whether organizations identify and manage risks to ePHI.

Invicti brings together application and API discovery, DAST, remediation workflows, ASPM, and HIPAA-oriented reporting to help healthcare teams make application risk visible and manageable.

Next steps

• Get the HIPAA AppSec compliance checklist.
• Explore the Invicti Application Security Platform to see how it combines application and API discovery, automated testing, remediation workflows, and centralized risk visibility.
• Talk to an Invicti specialist to discuss your application inventory, authenticated testing needs, API coverage, remediation workflows, and reporting requirements.