HIPAA risk analysis evidence from the code behind your ePHI systems
The Security Rule asks you to identify the vulnerabilities in the systems that handle ePHI, reduce them to a reasonable level, and keep the documentation. Codacy analyzes every code change and records the result.
Trusted by 15,000+ organizations and 200,000+ developers worldwide
How Codacy supports
your HIPAA Security Rule evidence
An accurate and thorough assessment of the potential risks and vulnerabilities to the ePHI you hold
Codacy surfaces supported weaknesses in code, dependencies, infrastructure-as-code files and secrets across your connected repositories.
Security measures to reduce risks and vulnerabilities to an appropriate level
Severity levels and configurable remediation deadlines, with overdue status, so reduction is tracked against deadlines you set.
Procedures to regularly review records of information system activity
Audit logs record selected changes to Codacy settings, members and tokens, so a change to what gets analyzed is itself a reviewable record.
Procedures for guarding against, detecting and reporting malicious software
Dependency scanning checks your manifest files daily against the OpenSSF Malicious Packages database for known malware, and against public CVE and advisory data for known-vulnerable components.
Periodic evaluation of changes affecting ePHI security
Analysis runs on every pull request and commit, so a technical check follows each change. Usage reporting shows which repositories are analyzed and which are not.
Policies and procedures to protect ePHI from improper alteration or destruction
Code analysis flags injection, input validation and mass assignment patterns. Infrastructure-as-code checks catch datastores defined without backup retention, versioning or deletion protection. Secrets detection catches credentials that would allow either.
Policies, procedures, actions, activities and assessments maintained in writing, and kept for six years
Codacy gives you findings, analysis history and CSV export as a written record of the activity. Audit logs are saved for one year.
“Codacy has improved communication between security and development teams, and it’s continuing to raise the bar for compliance.”
David Morton Manager of Security Operations at Genesys
HIPAA Security Rule evidence
for engineering leaders
Connect your Git organization in two clicks. First evidence report the same day.
A recorded check on every change
Set the security thresholds you want a pull request to meet. Codacy evaluates each change against them and posts the result as a status check: a dated record of what was tested on the code that handles ePHI. 164.308(a)(8) asks for periodic evaluation and re-evaluation when things change; a check on every pull request gives you dated evidence for both.
Every finding in one view
Code scanning, infrastructure-as-code and exposed secrets report into a single findings view, alongside open-source dependency and application scanning findings, with severity and overdue status. Export it as CSV for the risk analysis and the risk management plan behind it.

Component inventory, rescanned daily
See which open-source components the applications that handle ePHI depend on, at which versions, and which repositories use an affected version — the software half of the inventory 164.308(a)(1)(ii)(A) asks your risk analysis to cover. Rescanned daily, so a newly disclosed vulnerability surfaces at the next daily rescan rather than at the next code change.

SAST on every commit
Injection and input validation patterns that let data be altered improperly (164.312(c)(1)), authentication and authorization weaknesses in the code behind access control (164.312(a)(1), 164.312(d)), and weak cryptographic and insecure transport patterns (164.312(e)(1)) — all identified before merge.
Malicious package detection
Manifest files are checked against the OpenSSF Malicious Packages database, so a typosquat or a hijacked dependency is flagged on the pull request that introduces it — the supply-chain side of 164.308(a)(5)(ii)(B).
Secrets caught before commit
Supported secret patterns detected in analyzed code and in the IDE, so credentials to the systems holding ePHI are not sitting in a repository — the code side of 164.312(a)(1).
Deadlines and overdue status
Set a remediation deadline per severity, and every finding shows as on track, due soon or overdue. Those deadlines become your documented definition 164.308(a)(1)(ii)(B) asks for.
Repository coverage report
164.308(a)(8) evaluation is scoped to the systems that handle ePHI. Report which repositories are analyzed and which are not, so the gap is visible to you before it is visible to an assessor, with CSV and JSON export.
CSV findings export
Export severity-ranked findings and remediation records into your own evidence store, where the six-year record lives.
Frequently asked questions
Does the Security Rule require static analysis or code review?
45 CFR Part 164 Subpart C requires an accurate and thorough risk analysis, measures sufficient to reduce what that analysis finds, periodic technical evaluation, and six years of documentation. Under 164.306(b) the method is yours. For an organization that writes the software handling ePHI, code analysis is a defensible answer to those obligations, not a named requirement.
Does this apply if we are pursuing HITRUST?
Mostly, yes. Healthcare organizations commonly use HITRUST certification as the evidence vehicle for their HIPAA program, and the same dated analysis records serve both. Certification attaches to your organization for an assessed scope, so a tool contributes evidence to a control rather than satisfying one. HITRUST itself says an assessment should not be submitted alone to demonstrate Security Rule compliance: OCR expects a narrative response and a valid risk analysis alongside it — the first row of the table above. Ask us for the Category 10 detail on the call.
Do our developers have to change how they work?
Analysis runs on pull requests in the Git provider they already use, results post as a status check, nothing new to open.
What do we actually hand an assessor?
A CSV export of findings with severity and remediation status, the analysis history for each repository, the status check recorded on every pull request, and a coverage report showing which repositories were in scope.
Risk analysis refresh or
security questionnaire coming up?
See your first evidence report today. Bring your current risk analysis or the questionnaire a covered entity has sent you. Talk to our team about:
- The repositories and languages that handle ePHI.
- The severities and deadlines your risk management plan commits to.
- The records you need to keep for six years.