Originally published at ictfax.org
If you run your own fax server, you have probably done a risk analysis at some point. Maybe a spreadsheet, maybe a proper report. The question that matters in 2026 is different: after you wrote it, what did you actually change, and can you prove when?
The HHS Office for Civil Rights has widened its Risk Analysis Initiative to cover risk management as well. Same Security Rule, next subsection. It moves the audit from whether you looked to whether you acted.
Two rules, not one, and open source fax server software touches both
People talk about "the risk assessment" as a single obligation. It isn't. The Security Rule splits it in two, and they sit right next to each other at 45 CFR 164.308(a)(1)(ii).
Subsection (A) is risk analysis: identify the threats and vulnerabilities to your electronic protected health information. Subsection (B) is risk management: put in place security measures that reduce those risks to a reasonable and appropriate level. One finds the hole. The other fills it.
The two subsections sit together in the rule, but most teams only have paperwork for the first one.
Here is my honest read of why this hurts self hosted teams more than hosted ones. When you buy a fax service, somebody else owns the spool, the trunk and the archive, and their compliance team writes the remediation notes. When you host it yourself, you own all three, and the notes are yours to write. Nobody writes them.
What OCR expects to see in the file
The expectation is not a certificate. It is a paper trail that ties findings to actions and puts dates on both. In practice that means a risk register listing what you found across every system that creates, receives, maintains or transmits ePHI, and against each entry a record of what was decided, what was implemented, and when it closed.
For a fax stack, "every system" is wider than the application. The inbound spool holds images. The outbound queue holds images. The archive holds years of them. The SIP leg carries them across a network you may not control. Your database holds the metadata, which is often enough to identify a patient on its own.
Five rows, four closed, one open. The open row is fine as long as it has a decision and an owner.
Notice the last row is still open. That is not a failure. An unresolved finding with a documented decision behind it reads very differently from a finding nobody touched. What gets punished is silence.
The part teams get wrong
A risk analysis dated 2023 with no remediation trail after it is worse than no analysis at all, because it proves you knew. That sounds harsh, but it is the logic every enforcement summary follows. You identified a vulnerability, you documented it, and then nothing happened for three years.
The second mistake is scoping the analysis to the application and stopping there. If your T.38 fax transport runs unencrypted across a shared link, that belongs in the register whether or not the fax software itself is hardened. The rule follows the data, not the product boundary.
Third, and this one is specific to open source: people treat "we can read the code" as a control. It is an advantage, genuinely, because you can verify what happens to a fax instead of trusting a datasheet. But reading the code is not the same as writing down what you changed after you read it.
The metadata problem nobody writes down
Ask most teams where the PHI lives in their fax stack and they point at the image files. Fair enough, that is where the clinical content sits. But the database row describing that fax is frequently enough to identify someone on its own.
A row that says an inbound fax arrived from a named oncology practice, on a given date, addressed to a named patient, has told you something clinical before anyone opens the TIFF. Sender number, recipient, timestamp and subject line together are often identifying, and they are usually the least protected part of the system because they feel like plumbing.
Same story with logs. Debug logging on a fax gateway has a habit of capturing numbers and sometimes headers, then shipping them to a log aggregator that was never in scope for anything. If you run centralised logging, that aggregator belongs in the register.
I would put both in the risk analysis explicitly rather than assuming they are covered by a line about the application. Auditors read scope literally, and so should you.
What counts as a material change
The rule says reassess on material change, which sounds vague until you list what has actually changed on a fax server in the last two years. Most of these are obvious in hindsight and invisible at the time.
Swapping SIP providers changes the transport path and often the encryption posture. Moving from bare metal to containers changes where the spool physically lives and who can reach it. Adding a second site for redundancy doubles the number of places images rest. Turning on a new integration, even a read only one, adds a system that touches ePHI.
Staff changes count too, which teams almost never record. If the person who held the shared admin credential left in March and the credential still works in September, that is a finding with a date attached whether you wrote it down or not.
My rule of thumb: if you would mention it in a change log, it is material enough to note in the register. One line is fine.
A workable cadence for small teams
You do not need a compliance department. You need a file that someone updates when things change. Start the register with the systems that actually hold images, add the transport, add the metadata store, then work down.
Re-check when something material changes, and at least once a year even when nothing does. A migration counts. A new trunk provider counts. Moving the archive to different storage definitely counts. If you have just moved to a container deployment, that is a material change and the register should say so.
Keep it boring. A dated table in a repository beats a polished document nobody opens. The audit value is in the dates, not the formatting.
Where ICTFax fits
ICTFax is open source, so the parts you need to write about are inspectable rather than assumed. You can state where images sit on disk, which transport carries them, and what the retention job does, because you can read it. That makes the register easier to fill honestly.
Self hosting also means the remediation is yours to schedule rather than something you wait on a vendor for. If the finding is an unencrypted spool, you can close it this week. Have a look at the installation guide if you are standing up a fresh deployment and want the storage and transport decisions recorded from day one.
Frequently asked questions
Does a risk analysis expire?
There is no fixed expiry date in the rule. The expectation is that you reassess on material change and periodically regardless. Most teams settle on annually plus after any significant infrastructure change, which is a defensible reading.
Is risk management a separate document from risk analysis?
It does not have to be. A single register with a remediation column works fine, and is easier to keep current than two files that drift apart. What matters is that findings and actions are linked and dated.
We are a small practice. Does this really apply to us?
Yes. The rule scales in how you implement it, not in whether it applies. A four person practice can satisfy this with a short table. The obligation is the same, the effort is not.
What if a finding is still open when an audit lands?
Open findings are normal. Show the decision, the planned measure and the reason for the timeline. An open item with a documented plan is a very different conversation from one with no record at all.
Does using open source fax server software make compliance harder?
Harder in that nobody else writes your documentation. Easier in that you can verify what the software actually does with PHI rather than taking a vendor's word for it. On balance I would take the verifiability.
Related resources
If you are reviewing your fax path this quarter, start the register before you start the hardening. The register is what you will be asked for. ICTFax is free and open source, so you can inspect every step a fax takes and write the entries from what the code does rather than from what a brochure claims.
Top comments (0)