Meeting the Health Care Cybersecurity and Resiliency Act (S. 3315) Requirements With Picus
| October 26, 2026
What is the Health Care Cybersecurity and Resiliency Act?
The Health Care Cybersecurity Act, formally the Health Care Cybersecurity and Resiliency Act of 2026 (S. 3315), is a U.S. Senate bill that directs the Secretary of Health and Human Services (HHS) to update the HIPAA Security Rule around minimum, risk-based cybersecurity practices, and directs HHS and the Cybersecurity and Infrastructure Security Agency (CISA) to coordinate on defending the Healthcare and Public Health Sector [1].
The Senate passed the bill without objection on September 30, 2026, and the bill now goes to the House of Representatives [2], [3]. It is not law until the House passes it and it is signed, but its text already names the controls HHS will be told to require.
Why was the Health Care Cybersecurity Act introduced?
The Health Care Cybersecurity Act was introduced to protect patient data and keep care running as cyberattacks on health care organizations increase [4]. A bipartisan Senate working group formed in 2023 drafted it, and it was first introduced in November 2024 and reintroduced in December 2025 [4], [5].
The February 2024 Change Healthcare attack shows the risk. Attackers used stolen credentials on a remote access portal without multifactor authentication, and about 192.7 million individuals were affected [6].
The bill also puts into law many of the changes HHS proposed for the HIPAA Security Rule in January 2025. HHS has delayed the final version of that rule until at least July 2027 [3].
Who must comply with the new HIPAA security requirements?
The new HIPAA security requirements in the Health Care Cybersecurity Act apply to covered entities and business associates as defined in 45 CFR 160.103, and to non-governmental entities in the Healthcare and Public Health Sector identified in National Security Memorandum-22 [1].
Covered entities are health plans, health care clearinghouses and health care providers that conduct standard electronic transactions. Business associates are the vendors that create, receive, maintain or transmit protected health information on their behalf. Section 8(a) places the new minimum practices on all three groups directly, so business associates carry the obligation themselves rather than only through contract.
What are the new HIPAA security requirements under S. 3315?
Section 8(a) of the Health Care Cybersecurity Act requires HHS to update the HIPAA Security Rule so that covered entities and business associates adopt minimum risk-based cybersecurity practices, including multifactor authentication, encryption of protected health information, monitoring that includes penetration testing, and other minimum standards reflected in national cybersecurity frameworks [1].
To learn what these requirements mean for security teams in practice, read our blog, New HIPAA Security Requirements: What the Health Care Cybersecurity Act Means for Security Teams.
When do the new HIPAA security requirements take effect?
Under Section 8(c), the updated HIPAA Security Rule requirements take effect 36 months after the date of enactment, and Section 8(d) allows the Secretary to exercise enforcement discretion for entities facing extraordinary circumstances [1].
Other deadlines run faster. Section 7(b) gives HHS one year from enactment to issue regulations on recognized security practices, Section 9 requires rural cybersecurity guidance within the same year, and Section 10 authorizes grants of up to three years for eligible providers.
How Picus Helps You Meet the New HIPAA Security Requirements
Meeting the new HIPAA security requirements takes more than having the right controls in place. Covered entities and business associates need to show, on an ongoing basis, what an attacker can actually reach and whether their controls stop and detect that attack. Section 7 ties regulatory credit to that evidence.
The Picus Autonomous Exposure Validation Platform produces that evidence through three validation techniques, each covering what the others cannot. Picus Breach and Attack Simulation runs real attack techniques safely against the live prevention and detection stack and records whether each action was blocked, detected, logged only or missed. Picus Autonomous Penetration Testing safely runs real exploits against reachable assets to prove which exposures an attacker can actually exploit, then chains them into attack paths to show how far that attacker could get. Picus Exposure Validation proves exploitability without firing a live exploit, which extends validation to business-critical, clinical, restricted and air-gapped systems that live testing cannot safely touch.
Every result feeds one decision per exposure (Patch, Mitigate, Monitor, or Accept with Evidence), with an owner, a deployed fix and a verified re-test, so the record HHS will ask for under Section 7 is produced as the program runs rather than assembled before a review.
Below, we look at how Picus helps with each of these requirements:
- Section 8(a)(3): Penetration Testing
- Section 8(a)(3): Monitoring to Maintain the Protections of Information Systems
- Section 10(c)(5): Cybersecurity Risk Assessments and Vulnerability Assessments
- Section 7: Recognized Security Practices and Lower HIPAA Fines
- Section 10(f)(1): Baseline Measures and Benchmarks
- Sections 8(a)(4) and 8(b): Minimum Standards Reflected in National Cybersecurity Frameworks
S. 3315 Section 8(a)(3): Penetration Testing
|
"...including penetration testing, to maintain the protections of information systems..." (Section 8(a)(3), minimum risk-based cybersecurity practice) |
The HIPAA Security Rule has never explicitly named penetration testing. Section 8(a)(3) now names it as a required practice for keeping systems protected.
To meet that goal, penetration testing has to keep up with change. A test shows exposure only on the day it runs, while new systems, vendors and vulnerabilities appear every week. A report from March says little about the attack paths open in October.
How does Picus support S. 3315 Section 8(a)(3) penetration testing?
Picus Autonomous Penetration Testing runs stealthy, production-safe penetration tests continuously instead of once a year. It chains real weaknesses and exploits into attack paths that show impact, and prevents harmful exploits from running in production, so a hospital can test the network its clinicians depend on without disrupting care.

Figure 1. Attack path validated by Picus Autonomous Penetration Testing, from initial access to compromised credentials.
Tests start automatically when something changes. Picus Swarm, a team of five specialist AI agents (Discovery, Exploitation, Validation, Mobilization and Reporting) orchestrated by Numi AI, watches for signals from both the threat landscape, such as a newly exploited vulnerability, and the environment itself, such as a new asset. When a signal arrives, Swarm starts a new test automatically, so results always reflect the environment as it is today.

Figure 2. Picus Swarm, five specialist AI agents orchestrated by Numi AI.
The covered entity ends up with a dated series of tests tied to the changes that triggered them, rather than a single annual report, which is a much stronger answer to a reviewer who asks whether penetration testing actually maintained the protections Section 8(a)(3) describes.
S. 3315 Section 8(a)(3): Monitoring to Maintain the Protections of Information Systems
|
"...requirements to conduct monitoring... to maintain the protections of information systems..." (Section 8(a)(3), minimum risk-based cybersecurity practice) |
Section 8(a)(3) makes monitoring a required practice rather than an addressable one, and states its purpose: to maintain the protections of information systems. For covered entities and business associates, that means EDR, SIEM, firewall and email controls must keep working as the environment changes, not just be licensed and switched on.
Monitoring tools only report what they see, not what they miss. If a log stops arriving or a detection rule breaks, the dashboard still looks fine while an attacker moves through the network. The only way to find these gaps is to run the attack and check what happens.
How does Picus support S. 3315 Section 8(a)(3)?
Picus Breach and Attack Simulation runs attack simulations safely against the live security stack, from endpoint and network controls to email gateways, web application firewalls and cloud workloads, and records for each action whether it was blocked, detected, logged only or missed.

Figure 3. Picus Breach and Attack Simulation dashboard with prevention and detection scores and blocked, logged and alerted results.
Simulations draw on the Picus Threat Library, which holds more than 30,000 attack techniques and 7,500 threat scenarios mapped to MITRE ATT&CK. Picus Labs updates the library continuously and adds critical emerging threats that have a public proof of concept (PoC) within 24 hours, so the monitoring program is tested against the attacks currently aimed at health care.

Figure 4. Picus Threat Library, continuously updated by Picus Labs with the latest threats.
When a test finds a gap, the Picus Mitigation Library provides ready-to-apply, vendor-specific fixes, such as prevention signatures and detection rules, for the security controls already in place. Teams can close the gap quickly and re-run the same attack to confirm it is fixed.

Figure 5. Picus Mitigation Library, providing ready-to-deploy, vendor-specific fixes for the security tools already in place.
Additionally, Detection Rule Validation checks your SIEM and EDR detection rules without running any attacks. It shows which rules will not work, for example because their logs are missing or their logic is broken, and explains how to fix them. This way, a rule that can never fire is no longer counted as protection.
Like penetration tests, these checks also run when something changes, such as a detection rule update or a new threat. Each test finds controls that stopped working before an attacker does, and the results build a dated record showing that the monitoring Section 8(a)(3) requires was working, and when any gaps were fixed.
S. 3315 Section 10(c)(5): Cybersecurity Risk Assessments and Vulnerability Assessments
|
"...an eligible entity may use grant funds... to conduct cybersecurity risk assessments and vulnerability assessments..." (Section 10(c)(5), use of grant funds) |
Section 10 lets HHS give grants to smaller providers, such as rural health clinics and nonprofit hospitals, and they can use the money for risk and vulnerability assessments. These organizations have small teams and tight budgets, so each assessment needs to show clearly what to fix first.
A vulnerability assessment produces a list of CVEs, and even for a small hospital that list is usually longer than the team available to work it. Severity scores show what might be dangerous in general, not what an attacker can actually use in this environment. As a result, grant money can end up creating a bigger backlog instead of reducing risk.
How does Picus support S. 3315 Section 10(c)(5) assessments?
Picus Autonomous Penetration Testing safely runs real exploit chains against reachable assets to prove which vulnerabilities an attacker can actually use.
When there is no safe exploit, or a system is too critical to test live, Picus Exposure Validation takes over. It tests the attack techniques the exploit relies on against current defenses, which gives an answer on the day a vulnerability is disclosed without touching production systems.
Business Scopes group assets by criticality, so an electronic health record system is ranked above a test server with the same CVE. The Picus Exposure Score then prioritizes risk using validation results and asset criticality, not CVSS alone.

Figure 6. Picus Exposure Score re-ranking a critical CVSS vulnerability by its validated exploitability in the environment.
The outcome is an assessment that separates the exposures an attacker can use from the ones existing controls already neutralize, with a Patch, Mitigate, Monitor, or Accept with Evidence decision on each.
S. 3315 Section 7: Recognized Security Practices and Lower HIPAA Fines
|
"Not later than 1 year after the date of enactment of this Act, the Secretary shall promulgate regulations implementing section 13412 of the HITECH Act..., which shall include... (1) recognized security practices that the Secretary may consider when determining fines...; (2) the extent to which such recognized security practices should be in place...; (3) procedural requirements or information that shall be submitted by a covered entity or business associate...; and (4) how the Secretary will take into account such recognized security practices when determining fines, earlier favorable termination of audits, or mitigating remedies..." (Section 7(b), regulation on recognized security practices) |
Section 13412 of the HITECH Act, the law that sets how HIPAA is enforced, already lets HHS lower fines and close audits sooner for organizations that had recognized security practices in place for the previous 12 months. Section 7 of the bill updates that section. Within one year, HHS must define which practices count, how fully they must be in place and what proof organizations need to send.
The bill does not say yet what proof HHS will ask for. But a clear record of what was tested, what the defenses stopped, what failed and how each gap was fixed is the strongest way to be ready.
How does Picus support S. 3315 Section 7 recognized security practices?
Picus keeps the record as a by-product of running the program. For every material exposure, the platform preserves the affected asset and its business context, the attack path that was tested, proof of exploitability, the controls that blocked, detected or missed the attack, the decision taken, the owner, the verified re-test result and, for accepted risk, the rationale behind it, along with the history of how that risk changed.
When the Secretary's regulations specify the information to submit, the covered entity can answer with a continuous record of tested practices covering the full period under review, instead of a reconstruction assembled after an incident or a letter from HHS.
S. 3315 Section 10(f)(1): Baseline Measures and Benchmarks
|
"...a description of how the eligible entity will establish baseline measures and benchmarks that meet the Secretary's requirements to evaluate performance outcomes..." (Section 10(f)(1), grant application requirement) "...a strategic plan for how, after the end of the grant period, the eligible entity will sustain the activities funded under the grant and continue to adopt cybersecurity best practices." (Section 10(f)(2), grant application requirement) |
Section 10(f) asks grant applicants to set a baseline and measure their progress against it. Section 10(f)(2) also asks for a plan to keep that progress going after the grant ends. In short, HHS wants proof that the money improved security, not just that it was spent.
Most security reports count what the team did, not whether it worked. Activity can go up while the share of attacks the environment actually stops stays the same, so a benchmark built only on activity cannot show HHS whether the grant reduced risk.
How does Picus support S. 3315 Section 10(f)(1) baselines?
Within the first day of deployment, Picus Breach and Attack Simulation turns control effectiveness into a measured number, showing the share of attack techniques the environment prevents and the share it detects, per control and per layer. That first run is the baseline, and every later run is a data point against it, so performance outcomes are reported as a trend rather than estimated.
Progress is tracked through decisions, not activity. Every exploitable exposure gets one decision (Patch, Mitigate, Monitor, or Accept with Evidence), an owner and a verified re-test, so the record shows not just what was found but what was resolved. Because the loop keeps running, that progress continues after the grant ends, which supports the strategic plan Section 10(f)(2) requires.
S. 3315 Sections 8(a)(4) and 8(b): Minimum Standards Reflected in National Cybersecurity Frameworks
|
"...other minimum cybersecurity standards, as reflected in national cybersecurity frameworks... shall be based on... national cybersecurity frameworks, as appropriate, such as... the National Institute of Standards and Technology Risk Management Framework...; the National Institute of Standards and Technology Cybersecurity Framework...; the National Institute of Standards and Technology SP 800-53 r5 Security and Privacy Controls for Information Systems and Organizations...; or... the National Institute of Standards and Technology Artificial Intelligence Risk Management Framework;... the Health Sector Coordinating Council Cybersecurity Healthcare and Public Health Cybersecurity Performance Goals; and... the health care-specific cybersecurity performance goals of the Cybersecurity and Infrastructure Security Agency." (Sections 8(a)(4) and 8(b), basis for minimum practices) |
HHS will decide the full list of minimum practices, but these sections tell it where to look. That makes these frameworks the best preview of the new HIPAA Security Rule.
How does Picus support S. 3315 framework-based standards?
Picus results are mapped to MITRE ATT&CK, and the platform builds a coverage map from techniques that actually ran in the covered entity's environment rather than from mappings assumed on paper. That gives each framework control a tested result behind it.
Picus also supports the NIST Cybersecurity Framework 2.0 wherever testing can produce direct evidence:
- ID.RA-01 asks for vulnerabilities to be identified, validated and recorded. Autonomous Penetration Testing and Exposure Validation do this by proving which vulnerabilities an attacker can actually exploit.
- ID.RA-05 asks for risk to guide what gets fixed first. The Picus Exposure Score ranks exposures by validated exploitability and asset criticality.
- DE.CM-01 and DE.CM-09 ask for networks and systems to be monitored. Breach and Attack Simulation and Detection Rule Validation show whether that monitoring actually detects attacks.
- ID.IM-02 asks for improvements to come from security tests. Every failed test leads to a fix and a re-test, which builds a record of improvement over time.
The Report Center exports these results to PDF and CSV for compliance teams.
Since the new HIPAA Security Rule will be based on these frameworks, test results mapped to NIST CSF and SP 800-53 today can also be used as evidence once HHS publishes the rule.
Get Ready for the New HIPAA Security Requirements Today
The Health Care Cybersecurity Act is not law yet, but its direction is clear. It makes multifactor authentication, encryption and monitoring with penetration testing required, builds the new rules on frameworks such as NIST CSF, and ties lower fines and shorter audits to security practices an organization can prove.
Picus helps healthcare organizations get ready today. Autonomous Penetration Testing shows what an attacker can actually reach. Breach and Attack Simulation and Detection Rule Validation show whether defenses stop and detect attacks. Exposure Validation proves whether an exposure is exploitable, even on the most critical systems that cannot be tested live. Together, they show which exposures put patient data at real risk and whether defenses hold, so teams can fix what matters first. Every result is kept as a record of what was tested, what failed and how it was fixed.
Starting now also matters because HHS already looks at the security practices in place over the previous 12 months. Organizations that begin validating today will have that record ready when the new rules arrive.
Get a demo to see how Picus shows what attackers can actually exploit and what your defenses really stop, so you can meet the new HIPAA security requirements with proof.
References
[1] U.S. Congress, "S. 3315, Health Care Cybersecurity and Resiliency Act of 2026 (Engrossed in Senate)," Congress.gov, Sep. 30, 2026. [Online]. Available: https://www.congress.gov/bill/119th-congress/senate-bill/3315/text
[2] GovTrack.us, "S. 3315 (119th): Health Care Cybersecurity and Resiliency Act of 2026." [Online]. Available: https://www.govtrack.us/congress/bills/119/s3315
[3] S. Alder, "Senate Unanimously Passes the Health Care Cybersecurity and Resiliency Act," The HIPAA Journal, Oct. 5, 2026. [Online]. Available: https://www.hipaajournal.com/senate-unanimously-passes-the-health-care-cybersecurity-and-resiliency-act/
[4] Office of Sen. Mark R. Warner, "Warner and Colleagues Reintroduce Legislation to Strengthen Cybersecurity in Health Care," Dec. 4, 2025. [Online]. Available: https://warner.senate.gov/public/index.cfm/2025/12/sens-warner
[5] Office of Sen. Mark R. Warner, "Warner, Cassidy, Colleagues Introduce Legislation to Strengthen Cybersecurity in Health Care Sector as Part of Bipartisan Working Group," Nov. 2024. [Online]. Available: https://www.warner.senate.gov/public/index.cfm/2024/11/warner-cassidy-colleagues-introduce-legislation-to-strengthen-cybersecurity-in-health-care-sector-as-part-of-bipartisan-working-group
[6] A. Ćemanović, "Change Healthcare Revises Breach Impact to 192.7 Million Individuals," CyberInsider, Aug. 15, 2025. [Online]. Available: https://cyberinsider.com/change-healthcare-revises-breach-impact-to-192-7-million-individuals/
