HIPAA technical safeguards
that survive an audit.
The Security Rule demands technical safeguards for ePHI. Our infrastructure provides them — and produces the documentation OCR expects during an investigation.
The Security Rule
decoded.
The HIPAA Security Rule (45 CFR Part 164, Subpart C) establishes national standards for protecting electronic protected health information (ePHI). It applies to covered entities — health plans, healthcare clearinghouses, and healthcare providers — as well as their business associates.
The rule organizes safeguards into three categories: Administrative (§164.308), Physical (§164.310), and Technical (§164.312). PrismWeb’s infrastructure directly addresses the technical safeguards and provides evidence supporting several administrative requirements.
Technical safeguards include access control (§164.312(a)), audit controls (§164.312(b)), integrity controls (§164.312(c)), person or entity authentication (§164.312(d)), and transmission security (§164.312(e)). These aren’t optional — they’re required standards.
When the Office for Civil Rights (OCR) investigates a breach, they look for evidence that reasonable and appropriate safeguards were in place before the incident. “We had a policy” without evidence of implementation is how organizations end up in Resolution Agreements with seven-figure settlements.
How PrismWeb maps to
Security Rule requirements.
| Check | HIPAA Requirement | Safeguard Category |
|---|---|---|
| DNSSEC | §164.312(c)(1), §164.312(e)(1) | Technical — Integrity, Transmission |
| SSL/TLS | §164.312(e)(1), §164.312(e)(2)(ii) | Technical — Transmission Security |
| Enhanced HTTPS | §164.312(e)(1), §164.312(e)(2)(ii) | Technical — Transmission Security |
| Enhanced TLS | §164.312(e)(1), §164.312(e)(2)(ii) | Technical — Transmission Security |
| Certificate Validation | §164.312(d), §164.312(e)(1) | Technical — Authentication |
| Security Headers | §164.312(a)(1), §164.312(c)(1) | Technical — Access Control |
| SPF | §164.312(c)(1), §164.312(e)(1) | Technical — Integrity |
| DKIM | §164.312(c)(1), §164.312(e)(2)(i) | Technical — Integrity |
| DMARC | §164.312(c)(1), §164.312(e)(1) | Technical — Integrity |
| MTA-STS | §164.312(e)(1), §164.312(e)(2)(ii) | Technical — Transmission Security |
| TLS-RPT | §164.312(b), §164.308(a)(1)(ii)(D) | Technical — Audit Controls |
| IP Abuse | §164.312(b), §164.308(a)(6)(ii) | Technical/Admin — Audit, Incident |
| WordPress Detection | §164.308(a)(1)(ii)(A), §164.312(a)(1) | Admin — Risk Analysis |
| Website Scanning | §164.308(a)(1)(ii)(A), §164.312(b) | Admin/Technical — Risk, Audit |
| IPv6 | §164.312(a)(1) | Technical — Access Control |
| RPKI | §164.312(c)(1), §164.312(e)(1) | Technical — Integrity, Transmission |
What survives
an OCR audit.
Written documentation of each technical safeguard implementation, aligned to the specific Security Rule standard it satisfies. Ready for OCR review.
Our sixteen checks identify and document infrastructure risks continuously, supporting the §164.308(a)(1)(ii)(A) requirement for an accurate and thorough risk analysis.
Continuous monitoring logs that satisfy audit control requirements (§164.312(b)). Hardware, software, and procedural mechanisms recording and examining activity.
Our infrastructure is designed to support Business Associate Agreement obligations. We document the safeguards we implement to protect ePHI entrusted to our systems.
In the event of a security incident, our monitoring evidence demonstrates what safeguards were in place, when they were last verified, and what was detected — critical for the breach notification risk assessment under §164.402.
Technical safeguards
that document themselves.
OCR doesn’t accept “we thought we had that configured.” Our infrastructure proves your safeguards are implemented, operating, and monitored.