sha3:d72d4cbb3729e5c35fa75e082b362dbc1ee7c53b8bdc998b57b7568ae4c0195eIntactHIPAA Security Rule 164.308 / .310 / .312 / HITRUST CSF
PHI governance, audit-ready by default.
The HIPAA Security Rule asks covered entities and business associates to show that administrative, physical, and technical safeguards operated over protected health information, and to keep the documentation six years. PolicyCortex records the configuration of your PHI environments, every change to it, and every machine action, hash chained inside your tenant. It processes configuration metadata, never patient records.
790f15be5e05c727d789f5d54aded139e4d30c67adf2ce01ba398d9a15d8b9e9prev:101a012dd9a5What the Security Rule asks you to prove
HHS Office for Civil Rights enforces the Security Rule against covered entities and business associates alike. 164.308 covers administrative safeguards including the risk analysis, 164.310 physical safeguards (largely inherited from the cloud provider under a BAA), and 164.312 technical safeguards: access control, audit controls, integrity, authentication, transmission security. Documentation must be retained six years. HITRUST CSF adds the certification-grade artifacts assessors expect on top of the same controls.
The audit question is about an interval: was ePHI encrypted at rest on this date, who could reach this database on that date, and what changed between the two. A current dashboard cannot answer it; a record can.
- hipaa.308
- Administrative safeguards: risk analysis, workforce, information access management, evaluation.
- hipaa.310
- Physical safeguards: inherited from the cloud provider under a business associate agreement; the BAA scope is a declared boundary.
- hipaa.312
- Technical safeguards: access control, audit controls, integrity, person or entity authentication, transmission security.
- hipaa.retention
- Six years of documentation required. Records are retained seven years, append only.
- hipaa.phi
- PolicyCortex processes configuration metadata returned by cloud APIs. It never sees patient records.
d13f72e7c8821272951952bd9e502b55269346ba7145b6f921da40fa8f37733dprev:790f15be5e05The evidence produced over PHI environments
OCR asks for documentation of safeguards over time. Where each proof files:
- 164.312(a) access control
- Proof of state: which identities could reach which PHI-bearing resources as of any date, captured from the provider APIs and content hashed.
- 164.312(a)(2)(iv) · (e) encryption
- Proof of state: encryption at rest and in transit settings as point-in-time records with the raw response attached.
- 164.312(b) audit controls
- The chain itself: an audit record that cannot be edited without detection, with declared gaps where a collector was down.
- 164.312(c) integrity
- Proof of change: who or what altered a PHI-scope resource, under what authority, with before and after hashes and a rollback identifier.
- Machine actions
- Proof of agency: what any automated fix on a PHI environment was permitted to do before it ran, in the trust mode you set. GATED is the default.
Exhibit SB-10 · every control in one of five honest states, with the automatic fixes the envelope permits flagged per control. Illustrative demo data; the interface is real.
76bbdd7f4dc2df3c8ad6a07cbdd7b807eab7ded3eb9a6a42f49bf9d1c544cf3dprev:d13f72e7c882How the Security Rule documentation is verified
For a Security Rule question the recomputation covers an interval over a PHI environment, and because PolicyCortex processes configuration metadata rather than patient records, the chain the assessor recomputes never contains PHI.
Every record PolicyCortex writes for this obligation is content hashed with SHA3-256 and carries the digest of the record before it, so each line commits to the entire history above it. The log is append only: a correction is a new record, never an edit. Verification is a recomputation, not an assertion. Run the chain from the first record forward and it returns one of two answers: intact, or the sequence number of the first record that breaks.
A second party can do that recomputation without our help. The records, the digests, and the chain rule are everything required: no PolicyCortex account, no API of ours in the loop. When a collector was down or a scope was unobserved, the chain carries a declared gap with the interval and the reason, never silently fewer rows. Absence is declared, not inferred.
5d45246e683fadece690634c29072476fa1370666a886e218577572e6c498199prev:76bbdd7f4dc2How you evaluate it over a PHI environment
The fourteen days run inside your own accounts with the BAA scope declared on every record; cloud APIs return resource state, and no patient record is read.
Connect read only for fourteen days, in SHADOW mode, inside your own tenant. Nothing executes. Policy evaluation, evidence collection, and action gating run where your data already is; there is no telemetry pipeline to PolicyCortex servers and no egress of evidence. At the end of the fourteen days you hold the records and can recompute the chain yourself.
- eval.mode
- SHADOW. Watch only; nothing executes.
- eval.duration
- Fourteen days.
- eval.location
- Your tenant. Azure, AWS, and GCP are observed clouds, including AWS GovCloud, Azure Government, and GCC High.
- eval.egress
- None. No telemetry pipeline to PolicyCortex servers; no evidence leaves the tenant.
- eval.after
- You keep the records. Licensing is annual and the tenant owns the evidence; a delivery engagement is optional.
05a8aa74804709afe7b2d071a88b897528749dfc48b42485343ea65e0781f7beprev:5d45246e683fDelivery, if you want the record stood up for you
Licensing does not depend on it, but a fixed-scope delivery engagement is available: thirty days, one agreed primary cloud environment, an evidence package built and defended through assessor review. The independent assessor makes the certification decision. No certification is guaranteed.
- engagement.scope
- Thirty days. One agreed primary cloud environment.
- engagement.outcome
- An evidence package built and defended through assessor review.
- engagement.limit
- The independent assessor decides. No certification is guaranteed.
d72d4cbb3729e5c35fa75e082b362dbc1ee7c53b8bdc998b57b7568ae4c0195eprev:05a8aa748047Questions assessors and buyers ask
Does this satisfy the HIPAA Security Rule?
It produces the documentation the Rule asks for: 164.308 administrative, 164.310 physical (inherited from the cloud provider), and 164.312 technical safeguards evidenced as records, retained beyond the required six years. Whether the safeguards satisfy the Rule is a determination your compliance officer and, if it comes to it, OCR make. PolicyCortex does not make it.
What about HITRUST CSF?
HITRUST CSF v11 controls are mapped to the same records. The record adds the certification-grade artifacts assessors expect; the assessor remains the authority on what passes.
How is PHI handled?
PolicyCortex processes configuration metadata, not PHI. Cloud APIs return resource state; PolicyCortex never sees patient records. There is no telemetry pipeline to PolicyCortex servers and no egress of evidence. BAA coverage is provided where applicable.
Does it help with breach notification?
Proof of change and proof of state give an incident its timeline: what the environment was, what changed it, and when. Whether HHS and state notification are required, and the 60-day clock, are determinations your privacy officer makes from that record.
Does PolicyCortex make us compliant?
No. It produces the records compliance decisions rest on. The authorizing official, the C3PAO, or the accountable official makes the determination; PolicyCortex hands them evidence they can recompute instead of a narrative they have to believe.
What happens when a collector is down?
The chain carries a declared gap: the stream, the interval, the reason, and when it was declared. Evidence never silently has fewer rows.
Show OCR the record, not the reconstruction.