HIPAA Security Rule in Safeguard: Risk Analysis, Safeguards and Evidence

Safeguard helps a covered entity or business associate prepare for the HIPAA Security Rule by checking six software requirements on every product scan, from risk analysis foundations to documentation, and by tracking evidence for the administrative, physical and technical safeguards a scan cannot see. The compliance and GRC suite is generally available (GA). It prepares your evidence; it does not make you compliant, and no HIPAA certification exists.

That is the short answer. The rest of this post is for the security lead at a health tech vendor who is a business associate, and for the compliance officer at a covered entity who has to show that the software touching electronic protected health information (ePHI) is inventoried, assessed and controlled. It starts with what 45 CFR Part 164 Subpart C actually requires, then walks through the real Safeguard flow, then sets out plainly what stays with you.

Key takeaways

• The HIPAA Security Rule (45 CFR 164.302 to 164.318) requires an accurate and thorough risk analysis, risk management, technical safeguards and six years of documentation. The rule text in force in October 2026 is the 2013 version.
• HHS proposed a rewrite in January 2025; the federal regulatory agenda now targets July 2027 for a final rule. None of it is law yet.
• Safeguard's compliance and GRC suite (GA) includes a HIPAA Security Rule framework with six scan requirements, all decided by a scan, plus catalogue controls that you evidence with automated tests, uploaded evidence, policies or attestations.
• Scans use SBOM generation and analysis (GA) and SCA with vulnerability management, including EPSS and CISA KEV enrichment (GA), to link a software inventory to known vulnerabilities.
• Automated tests from connected systems map directly to HIPAA Security Rule controls. Roughly 50 evidence connectors are live today, with more on request.
• Third Party Risk Manager, or TPRM (GA), collects and monitors SBOMs from suppliers in the ePHI path. It does not replace a business associate agreement.
• The Safeguard CLI (GA) feeds scans in; the Safeguard MCP server (GA), added from Claude's connector directory, lets an assistant read them. Only a person can approve.
• A readiness score is Safeguard's assessment of what it can see. It is not an audit opinion, an attestation of compliance or a certification.

What the HIPAA Security Rule requires

The Security Rule sits in Subpart C of 45 CFR Part 164. It applies to covered entities (health plans, clearinghouses and most providers) and, since the 2013 Omnibus Rule, directly to business associates and their subcontractors. Five sections carry most of the weight for a software team.

164.306: the general duty and the flexibility clause

Section 164.306(a) sets the general duty. Covered entities and business associates must ensure the confidentiality, integrity and availability of all ePHI they create, receive, maintain or transmit, and must protect against reasonably anticipated threats or hazards to its security or integrity.

Section 164.306(b) gives flexibility. You may use any security measures that reasonably and appropriately implement the standards, and you decide based on your size and complexity, your technical infrastructure and software security capabilities, cost, and the probability and criticality of potential risks to ePHI.

Section 164.306(d) splits implementation specifications into "Required" and "Addressable". Addressable does not mean optional. You must implement it if reasonable and appropriate, or document why not and implement an equivalent alternative where that is reasonable. Section 164.306(e) adds a maintenance duty: review and modify your measures as needed and keep the documentation current.

164.308(a)(1)(ii)(A): risk analysis

The security management process standard at 164.308(a)(1) has four required implementation specifications. The first is the one auditors and investigators ask about first. The regulation calls for "an accurate and thorough assessment of the potential risks and vulnerabilities" to the confidentiality, integrity and availability of ePHI. The second, risk management at (a)(1)(ii)(B), requires security measures that reduce those risks to a reasonable and appropriate level. The other two are a sanction policy for workforce members and regular information system activity review, such as audit logs and access reports.

HHS's Office for Civil Rights (OCR) guidance on risk analysis says the rule "does not prescribe a specific risk analysis methodology". It does set objectives every method must meet: scope covering all ePHI in every form of electronic media, data collection that identifies where ePHI is stored, received, maintained or transmitted, documented threats and vulnerabilities, an assessment of current security measures, likelihood, impact, a level of risk for each threat and vulnerability pair, documentation, and periodic review. OCR also says the process should be ongoing, because the rule requires you to update measures as needed.

The rest of 164.308(a) covers assigned security responsibility, workforce security, information access management, security awareness and training (including periodic security updates and protection from malicious software as addressable specifications), security incident procedures, a contingency plan with data backup, disaster recovery and emergency mode operation, and periodic evaluation. Section 164.308(b) requires satisfactory assurances, through a contract that meets 164.314(a), before a business associate or subcontractor handles ePHI on your behalf.

164.310: physical safeguards

Section 164.310 covers facility access controls, workstation use, workstation security, and device and media controls, including disposal and media reuse. These are about buildings, desks, laptops and disks. Software scanning does not see them, which matters later in this post.

164.312: technical safeguards

Section 164.312 has five standards:

The integrity standard is worth reading twice. It asks you to protect ePHI from improper alteration or destruction. If the software that processes ePHI has been tampered with, or carries a component with a known flaw that permits tampering, the integrity of the data is only as good as that software.

164.316: documentation and the six year clock

Section 164.316(b)(1) requires written (which may be electronic) policies and procedures, and a written record of every action, activity or assessment the subpart requires you to document. Section 164.316(b)(2) adds three required specifications:

• Time limit. Retain that documentation for six years from the date of its creation or the date it was last in effect, whichever is later.
• Availability. Make it available to the people responsible for the procedures it covers.
• Updates. Review it periodically and update it in response to environmental or operational changes that affect ePHI security.

A risk analysis is a documented assessment, so it falls under the six year rule. So does every version of every policy that was in force during that window.

The proposed Security Rule update and where it stands

On 6 January 2025, HHS published a notice of proposed rulemaking titled "HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information" (90 FR 898, RIN 0945-AA22). Comments closed on 7 March 2025. Among other things, the proposal would:

• Remove the distinction between required and addressable implementation specifications, making almost all of them required, with limited exceptions.
• Add a standard at proposed 164.308(a)(1) for a written technology asset inventory and a network map of electronic information systems and all technology assets that may affect ePHI, reviewed at least once every 12 months and when the environment changes. The proposal calls the inventory the foundation for an accurate risk analysis.
• Require vulnerability scanning at least once every six months and penetration testing at least once every 12 months.
• Require written verification, at least once every 12 months, that business associates have deployed the required technical safeguards.
• Require a documented compliance audit at least once every 12 months.
• Require written procedures to restore critical systems and data within 72 hours of a loss.

The federal Unified Agenda entry for RIN 0945-AA22, checked on 24 October 2026, lists the rulemaking stage as "Long-Term Actions" with final action timetabled for July 2027. Agenda dates are not binding. Until a final rule is published, the 2003 rule as amended in 2013 is the law, and that is the version this post and Safeguard's framework page cite.

Even so, a written software inventory tied to vulnerability data is something a good risk analysis already needs under today's rule, and it is the easiest part of the proposal to start on now.

Guidance that helps you interpret the rule

NIST SP 800-66 Rev. 2 (February 2024) gives practical guidance for each standard, with key activities and sample questions, and maps the rule to the Cybersecurity Framework and SP 800-53 Rev. 5. The HHS 405(d) programme publishes Health Industry Cybersecurity Practices and voluntary sector Cybersecurity Performance Goals. Neither is binding, but both are useful references.

For a deeper read on the rule itself, see our HIPAA technical safeguards checklist for 45 CFR 164.312 and HIPAA risk analysis versus risk management.

Why a risk analysis needs an accurate software inventory

OCR's data collection objective is to identify where ePHI is stored, received, maintained or transmitted. For most health tech products, the honest answer is "in our application, which is made of our code plus hundreds or thousands of open source and commercial components we did not write".

A risk analysis that rates "patient portal" as one asset misses most of the attack surface. A vulnerable parsing library deep in the dependency tree is a vulnerability in the 164.308(a)(1)(ii)(A) sense: a weakness that a threat could exploit to reach ePHI. If you cannot name that component and its version, you cannot match it against known vulnerabilities, cannot judge its likelihood and impact, and cannot show that your risk management plan addressed it.

This is the gap a software bill of materials (SBOM) fills. An SBOM lists every component in a build, with versions and identifiers that vulnerability databases understand. Once the inventory exists and is matched against vulnerability data, the abstract question "what are the threats to our ePHI systems" becomes a concrete list: these components, these known vulnerabilities, these that are actively exploited, these with a fix available.

The usual failures are an inventory of applications rather than components, an analysis that was accurate only on the day it was written, and no dated record of what was known when. That last one matters most after an incident.

We go deeper on this in add software dependencies to your HIPAA risk analysis and which HIPAA safeguard a vulnerable dependency undermines.

How Safeguard covers the HIPAA Security Rule

Safeguard's compliance and GRC suite (GA) is a set of areas in the web app: Overview, Frameworks, Controls, Evidence, Monitoring, Tests, Policies, Questionnaires, Risks, Vendors, Trust Center and Connectors. The Trust Center is early access; everything else used in this post is GA. The framework library covers hundreds of frameworks, and HIPAA appears in it twice: as the HIPAA Security Rule and as HIPAA / HITECH.

Safeguard's docs describe four kinds of coverage for any framework, and the HIPAA Security Rule uses all four:

The HIPAA Security Rule is one of a small number of frameworks in the library that automated tests map to directly. The others named in the docs are SOC 2, ISO/IEC 27001, PCI DSS and NIST CSF 2.0, plus the CIS benchmarks. For most frameworks in the library, coverage is the scan requirements, the controls and your own evidence, so HIPAA gets more automation than average.

On the framework page, HIPAA is on in your workspace unless you switch it off in Compliance › Manage. Your Safeguard plan decides which frameworks your organisation can choose from.

The six scan checked HIPAA requirements

Each scan of a product checks six HIPAA requirements against what the scan found. Safeguard's docs mark all six as decided by a scan. Here is what each one looks at, in plain words, next to the regulation it rests on.

Read these carefully, because they are narrower than their names. Each one asks whether the software inventory gives you what that HIPAA clause needs from software. HIPAA-164-308RA does not perform your risk analysis. It checks that the foundation exists: identifiable components matched against vulnerability data. HIPAA-164-308BA does not check that you have signed a business associate agreement. It checks that the suppliers behind your software components can be identified, which is the starting point for deciding which of them handle ePHI and need one.

Put together, the six checks ask one question per clause: does the software inventory for this product give you what that part of HIPAA needs from software? The SBOM supplies the inventory, and vulnerability management (GA) matches it against known vulnerabilities enriched with EPSS and CISA KEV status, which gives you the threat and vulnerability pairs, with a likelihood signal, that OCR's guidance asks you to document. Software suppliers are not automatically business associates; a library author who never sees your data is not one, while a hosted service your product sends ePHI to usually is. The scan makes the supplier list visible so a person can make that call.

The HIPAA / HITECH framework in the same library adds six more scan requirements with a breach and business associate slant, including audit controls (164.312(b)), vulnerability identification for ePHI systems and breach notification readiness under 164.400 to 164.414. If your programme tracks HITECH separately, switch that framework on too. Automated tests do not map to it directly, but you can link tests to its controls yourself.

Catalogue controls you evidence yourself

Beyond the six scan requirements, the HIPAA framework's Controls tab lists catalogue controls drawn from the rule's administrative, physical and technical safeguards and its organisational and documentation requirements. You evidence these with automated tests, uploaded evidence, policies or an attestation.

Safeguard's connector page for HIPAA states that automated tests map to most of these controls, and that some tests read Safeguard's own records (policies, people, training and devices) and so need no connector at all. It also says plainly that "a passing result is evidence toward a control, not proof". Treat every green test as one input to your evaluation, not the evaluation itself.

Policy templates for HIPAA

Every framework in the library has a standard set of policy templates adapted to it. HIPAA also has templates written specifically for it, including an information security policy, an access control and authentication policy, an audit controls and logging policy, a breach notification policy, a business associate management policy, and an encryption and transmission security policy. Where a HIPAA specific template exists on the same subject as a standard one, the HIPAA version replaces it.

A template is a starting point. It does not know your systems, your workforce, your risk tolerance or your contracts, and it should be edited before anyone approves it.

Step by step: from switching on HIPAA to a readiness review

This is the flow for a business associate that builds a product processing ePHI. Screen names are from Safeguard's docs; where the docs describe an outcome rather than a screen, so does this walkthrough.

1. Confirm the HIPAA Security Rule framework is on

Open Compliance › Manage, then the Frameworks tab. Find the HIPAA Security Rule by region (Americas), country (United States), industry (healthcare) or by search. It is on by default; if someone switched it off, switch it on and select Save. It then appears on Compliance › Frameworks, Controls and Overview. If you also track HITECH, switch on HIPAA / HITECH in the same place. If neither appears, your plan does not include them; ask your Safeguard administrator.

2. Put the software that touches ePHI into a product

In Safeguard, a product groups projects, and a project is a repository, a scanned URL or an uploaded artifact. Create a product for the system that handles ePHI (for example, your patient portal) and add every repository and image that is part of it. The scan requirements are checked per product, so this grouping decides which software counts as "the ePHI system" in your HIPAA view. Be generous: include the background workers, the integration services and the infrastructure images, not only the front end.

For how products, projects, SBOMs and findings fit together, and how to count vulnerabilities without double counting, see the series post on how Safeguard data is structured.

3. Scan, so the six requirements have something to check

Connect your repositories through the web app, or scan from the Safeguard CLI (GA). The CLI's interactive terminal uploads the SBOM and findings to the platform, never your source:

# Install the CLI
curl -fsSL https://cli.safeguard.sh/install | bash

# Open the terminal, then type /login and /scan .
safeguard

For a pipeline, the docs show safeguard ci scan, which waits for the platform result and can fail the job on a severity you choose:

SAFEGUARD_API_KEY=... safeguard ci scan --wait --fail-on critical \
  --repository-url "$REPO_URL" --branch "$BRANCH" --commit "$COMMIT"

Each scan produces an SBOM (SBOM generation and analysis, GA), matches components against known vulnerabilities (SCA and vulnerability management, GA) and evaluates the six HIPAA scan requirements for the product. Scanning in CI on every merge keeps the inventory current, which is what an ongoing risk analysis needs. For choosing between a repository connection, the CLI and the local runner, see repo connection, CLI or local runner.

4. Read the scan requirement results on the Controls tab

Open the HIPAA Security Rule on Compliance › Frameworks, then its Controls tab. The six scan requirements appear as controls, each met or not met for the product, alongside the catalogue controls. A failing HIPAA-164-308RA usually means part of the product was not scanned or a component could not be identified. Fix the coverage before you fix anything else, because every other result depends on it.

5. Connect systems for automated tests

Open the framework's Connectors tab. It lists the connectors that answer this framework's tests, which of them you have connected, and whether each connection is healthy. Connect your identity provider, cloud accounts, code hosts and device management first; those carry the technical safeguards (access control, audit controls, authentication, transmission security) and much of the workforce and information access evidence.

Roughly 50 evidence connectors are live today. The catalogue lists many more, which are available on request; use Compliance › Connectors › Request integration to ask for one. The docs also note that automated tests are switched on per workspace by the Safeguard team, so confirm with your administrator that they are active before you rely on them.

6. Run the tests and read the results

Tests run on their schedule, or straight away with Run now on Compliance › Tests. A passing test counts toward its controls once its preview period has ended. A failing test tells you which resource failed and why.

If a resource should legitimately be outside a test, such as a break glass account used only during an outage, use Exclude on the test's detail page. Give a Reason, choose an Approver and set Expires on. Nothing is excluded until the approver approves it, and the reason becomes the evidence. That matters for HIPAA because the emergency access procedure at 164.312(a)(2)(ii) is required, and an approved, expiring exclusion with a written reason is a far better record than a silent gap.

7. Attach evidence for what a test cannot see

On Compliance › Evidence, add evidence against a control. You choose the control, the evidence type, a title, a file or a link, an optional note and how often it should be reviewed. Typical uploads for HIPAA:

• Your written risk analysis and risk management plan, against 164.308(a)(1).
• The name and role of your security official, against 164.308(a)(2).
• Contingency plan test results, against 164.308(a)(7).
• Facility access records and media disposal certificates, against 164.310.
• Signed business associate agreements, against 164.314(a).

Evidence starts as submitted, and a compliance reviewer chooses Accept or Reject. The decision is stamped with who made it, when and why. Results recorded by an automated test from its own run start accepted on that basis.

8. Start your policies from templates and get them approved

Open the framework on Compliance › Frameworks, then its Policies tab, select New policy and choose Start from template. Edit the template to describe what you actually do, then use Submit for review. A reviewer approves it. On approval, the effective date defaults to the approval day and the next review to one year later.

9. Record risks and decide treatment

On Compliance › Risks, record the risks your analysis identified and how you are treating them. If you accept a residual risk, the rules depend on its level: the risk owner can accept a low or medium risk with a recorded reason, while a high or critical risk needs an approver with an admin role and a review date within a year. If the residual risk later rises above the accepted level, the acceptance shows Needs re-approval. That is a useful pattern for HIPAA's risk management specification, which expects measures sufficient to reduce risk to a reasonable and appropriate level, not a one time sign off.

10. Review readiness, and know what the number means

The framework's readiness score is the share of its in-scope requirements that pass. A requirement passes on a scan that finds it met, or on an attestation by a person that names its evidence. A requirement waiting for evidence counts as not passing. A requirement scoped out with a written justification leaves the score. Beside the score, Safeguard shows how many requirements a scan evaluated and how many need evidence or an attestation.

The docs are explicit: a readiness score "is not an audit opinion or a certification". Use it to find gaps and to track progress between assessments. Do not quote it to a covered entity as proof of compliance.

Example: what a scan result looks like in a HIPAA review

The figures below are illustrative, not customer data. Suppose a patient portal product has four projects. After the first scan, the Controls tab shows five of the six HIPAA scan requirements met and HIPAA-164-308RA not met, because one integration service had never been scanned. The team adds that repository to the product and rescans; the requirement is then met.

The product's vulnerability list, sorted by KEV status, reachability and fix availability, then becomes the software section of the risk analysis. Each row is a threat and vulnerability pair with a likelihood signal, and the treatment is an upgrade by a date or an acceptance with a reason. The dated scan records show when each was first known.

For a ranked, batched fix list built from the same data, see the series post on what to fix first, and our published guide to prioritising with reachability, EPSS and KEV.

Using an assistant on your HIPAA data, safely

To let an assistant read this data, add Safeguard from Claude's connector directory (a community listing): connect, sign in to Safeguard, check the app name and host, and authorise access. On a Team or Enterprise plan, an Owner adds it first. ChatGPT has its own apps route; follow OpenAI's documentation. Our post on Safeguard in your IDE and in the Claude and ChatGPT connector directories covers both.

Through the Safeguard MCP server (GA), the assistant can list products, projects and vulnerabilities and read a CVE's full record; which tools appear depends on your plan and administrator settings. Safeguard's approvals docs set two rules: an assistant or MCP client can draft and submit but never accept, approve, launch or acknowledge, and a write runs only after you confirm it in the client. So an assistant can draft the software section of a risk analysis from live data, or ticket text for a person to file. It cannot accept evidence or approve a policy.

Business associate assurance and TPRM

Section 164.308(b) is two layered. A covered entity needs satisfactory assurances from its business associates, and a business associate needs them from its subcontractors. Section 164.314(a) says what the contract or other arrangement must contain, including that the business associate will comply with the Security Rule, will ensure its subcontractors agree to the same, and will report security incidents, including breaches of unsecured PHI.

The contract is the legal assurance. What it does not give you is visibility into the software your business associates run. That is where Third Party Risk Manager (GA) helps. TPRM lets you:

• Keep a vendor directory with risk categorisation, contacts and contract and SLA tracking.
• Request SBOMs, projects or products from suppliers, with request templates, follow ups and response tracking.
• Analyse what suppliers send: vulnerability mapping and risk scoring against the same data your own scans use.
• Monitor suppliers continuously, with alerts when new vulnerabilities affect what they shipped you, and periodic reassessment.
• Apply policies and gates, and view mitigations others have applied.

Safeguard's TPRM docs suggest risk tiers by criticality. A supplier that sits in the ePHI path and has significant data access is a natural candidate for the high or critical tier, with an SBOM required and refreshed on a schedule.

Under today's rule, this is good practice that supports the risk analysis: a business associate's software is part of the threat picture for your ePHI. Under the proposed rule, it would line up with the annual written verification of business associates' technical safeguards. Either way, TPRM supports assurance; it does not replace the agreement, and it does not tell you whether a given supplier is legally a business associate. For more on supplier software risk across regulations, see supplier software risk under DORA, NIS2 and M-22-18 with Safeguard TPRM.

Six years of records: evidence versions and expiry

The documentation standard asks for six years of retention, availability to the people who need it, and periodic updates. Three behaviours in Safeguard's evidence and policy handling are relevant.

Versions, not overwrites. Changing accepted evidence (its file, link, note, dates or control) creates a new version, which goes back to submitted. An acceptance covers the version the reviewer saw. For policies, editing an approved policy sends the new version to review while the approved one stays in force, so staff keep following the text they were asked to follow. That gives you a history of what was in force when, which is what "the date when it last was in effect" in 164.316(b)(2)(i) needs.

Expiry that you can see. Accepted evidence with an end date becomes expiring inside its reminder window and expired from that date. A contingency plan test from last year, or a business associate agreement past its term, shows as a gap rather than quietly counting forever.

Decisions are recorded. Every acceptance, rejection, exclusion, risk acceptance and policy approval records who made it, when and why.

One honest caveat. Safeguard's docs describe versions, expiry and decision records; they do not state a retention period for the platform. Six year retention under HIPAA is your obligation. Check your contract and data retention settings with your Safeguard administrator, and keep your own export of the records you need for the full window, especially if you might change tools within six years.

Requirement, what Safeguard does, what you still own

What Safeguard does not do

• It does not make you HIPAA compliant, and there is no HIPAA certification. There is no official HIPAA certification for an organisation, and no tool can grant one. Safeguard's readiness score is its assessment of what it can see. Compliance is a legal state that depends on your whole programme, and OCR decides questions of compliance in an investigation.
• It does not hold, sign or negotiate your business associate agreements. You can upload agreements as evidence and track their expiry, and TPRM helps you see your suppliers' software. The agreements, and the judgement about who is a business associate, stay with you and your counsel. Nothing in this post says Safeguard signs a BAA with you; ask Safeguard directly if you need to know whether ePHI would ever reach its platform under your deployment.
• It does not see paper processes or physical spaces. Workforce sanctions, clearance decisions, facility security, visitor logs and media destruction happen outside software. Safeguard can store the evidence; it cannot observe the practice.
• It does not perform your risk analysis. The six scan requirements check that the software foundations exist. Scope, likelihood, impact, risk levels and the decision to accept or treat a risk are yours, and OCR expects them to be documented as yours.
• It does not make breach determinations. Whether an incident is a breach of unsecured PHI, and who must be notified within 60 days of discovery, is a legal decision under 164.402 to 164.414. Scan records can help you find affected components quickly. They do not answer the legal question.
• It does not cover every system out of the box. Roughly 50 evidence connectors are live today; others are available on request, and automated tests are switched on per workspace. A system you cannot connect needs uploaded evidence.
• It does not track the proposed rule for you. Safeguard's HIPAA framework cites the current rule. If HHS finalises the 2025 proposal, requirements and mappings may change.
• It does not replace an assessor. If a covered entity asks you for an independent assessment, a qualified third party performs it. Safeguard helps you prepare and hand over evidence; it does not issue an opinion.

Common mistakes

Scoping the product too narrowly. Teams put the main web application into the ePHI product and forget the background job that exports claims files or the integration service that receives lab results. Those are often where ePHI moves. Put every component in the data path into the product, then let the scan requirements tell you what is missing.

Reading a green scan requirement as a finished control. HIPAA-164-308RA met means the software inventory is good enough to support a risk analysis. It does not mean you have one. Upload the analysis itself against 164.308(a)(1).

Treating addressable as optional. Under today's rule you either implement an addressable specification, or document why it is not reasonable and implement an equivalent alternative. A test exclusion with no reason, or a skipped control with no justification, is the documentation gap OCR finds.

Quoting the readiness score to customers. A covered entity asking for assurance wants your risk analysis summary, your policies and evidence of your technical safeguards. A percentage from a tool, presented as compliance, invites the wrong question.

Letting evidence go stale. A contingency test or business associate agreement that expired last quarter still sits in a folder somewhere. Put end dates on evidence that has one, so it shows as expiring before it becomes a gap.

Waiting for the final rule. The proposal may change, but a component level inventory matched to vulnerabilities improves today's risk analysis regardless.

FAQ

Does Safeguard make my organisation HIPAA compliant?

No. Safeguard's compliance and GRC suite (GA) checks six HIPAA Security Rule requirements on every product scan and tracks evidence for the rest of the rule's controls. It helps you prepare and keep records. Compliance depends on your whole programme, and there is no HIPAA certification for any organisation or tool.

Does Safeguard sign a business associate agreement?

The offering materials this post is based on do not say so, so we make no claim either way. Ask Safeguard directly about your deployment. Separately, you can upload your own business associate agreements as evidence against 164.314(a) and track when they expire.

What does the HIPAA risk analysis requirement actually say?

Section 164.308(a)(1)(ii)(A) requires an accurate and thorough assessment of the potential risks and vulnerabilities to the confidentiality, integrity and availability of the ePHI you hold. OCR's guidance says the rule does not prescribe a method, but lists objectives: scope, data collection, threats and vulnerabilities, current measures, likelihood, impact, risk level, documentation and periodic review.

Is the new HIPAA Security Rule final?

Not as of 24 October 2026. HHS published the proposal on 6 January 2025. The federal regulatory agenda lists the rulemaking as a long term action, with final action timetabled for July 2027. Agenda dates are not binding, and the current rule stays in force until a final rule takes effect.

How long do I need to keep HIPAA Security Rule documentation?

Six years from the date of creation or the date it was last in effect, whichever is later, under 164.316(b)(2)(i). Safeguard keeps versions of policies and evidence and records each decision, but retention for the full six years is your obligation; confirm your retention settings and keep exports.

Do I need an SBOM for HIPAA?

The current rule does not use the word. But an accurate and thorough risk analysis of software that handles ePHI needs to name the components in it and match them against known vulnerabilities, and an SBOM is the standard way to do that. The 2025 proposal would add a written technology asset inventory as a separate standard.

Can Safeguard test my HIPAA technical safeguards automatically?

Partly. Automated tests from connected identity providers, cloud accounts, code hosts and device management map to HIPAA Security Rule controls such as access control, audit controls, authentication and transmission security. Roughly 50 connectors are live today. A passing test is evidence toward a control, not proof that the control is met.

Can I use Claude to review my HIPAA posture in Safeguard?

Yes, by adding Safeguard from Claude's connector directory, where it is a community listing. The assistant can read products, projects and vulnerabilities within your access. It can draft, but it cannot accept evidence, approve policies or make any decision that counts.

Fix it without waiting for upstream applies directly to HIPAA because the risk management specification expects you to reduce the vulnerabilities your analysis finds, not just record them. The block below is how Safeguard helps close those vulnerabilities in the open source dependencies and container images you ship.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would help

The first demo is a real Safeguard CLI session. You install the CLI, open the interactive terminal with safeguard, and ask it to fix the lodash CVE in a repository. It reads the finding and the advisory, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with your approval, prints a summary and pushes nothing. It then shows /permissions, /model and /scan . In a HIPAA programme, that last command is what refreshes the product's SBOM and the six scan requirements, and the approved fix is the risk management step your analysis called for.

Click through it at your own pace, or open it full screen.

The second demo shows Claude connecting to Safeguard with an OAuth sign in and choosing which tools Claude can use. For your own setup, add Safeguard from Claude's connector directory rather than configuring it by hand. Once connected, you can ask Claude to summarise the KEV listed vulnerabilities in your ePHI product or draft the software section of your risk analysis, and then review the draft yourself, because the assistant cannot approve anything.

Click through it at your own pace, or open it full screen.

To try this on your own software, download the apps at safeguard.sh/download and read the setup guides at docs.safeguard.sh.

Quick check

Sources

• eCFR: 45 CFR 164.306, Security standards: general rules
• eCFR: 45 CFR 164.308, Administrative safeguards
• eCFR: 45 CFR 164.310, Physical safeguards
• eCFR: 45 CFR 164.312, Technical safeguards
• eCFR: 45 CFR 164.314, Organizational requirements
• eCFR: 45 CFR 164.316, Policies and procedures and documentation requirements
• eCFR: 45 CFR 164.404, Notification to individuals
• HHS OCR: Guidance on Risk Analysis Requirements under the HIPAA Security Rule
• Federal Register: HIPAA Security Rule To Strengthen the Cybersecurity of Electronic Protected Health Information (NPRM, 6 January 2025)
• GovInfo: Full text of the January 2025 Security Rule NPRM
• Reginfo.gov: Unified Agenda entry for RIN 0945-AA22
• NIST SP 800-66 Rev. 2: Implementing the HIPAA Security Rule
• HHS 405(d) Program
• Safeguard docs: HIPAA Security Rule
• Safeguard docs: HIPAA / HITECH
• Safeguard docs: HIPAA Security Rule and connectors
• Safeguard docs: Compliance frameworks
• Safeguard docs: Approvals
• Safeguard docs: Third Party Risk Manager

Last reviewed: 24 October 2026. Product capabilities change; check docs.safeguard.sh for the current state.