HIPAA §164.312 evidence the HHS-OCR audit actually accepts.

TL;DR — what this does for HIPAA

NSAuditor AI EE generates §164.312 Technical Safeguards evidence — and ONLY §164.312. It maps cloud infrastructure findings (AWS, Azure, GCP) and network scan results to specific HIPAA Technical Safeguard control IDs, produces signed evidence artifacts (cover-page Scope Attestation, SHA-256 chain-of-custody sidecars, RFC 3161 trusted-timestamps, cryptographic suppression signing — all at the same institutional grade as the SOC 2 framework), and ships HIPAA reports in machine-readable form suitable for HIPAA-focused GRC platform ingestion.

What it IS: the technical-evidence layer for §164.312, complete and auditor-ready; compatible with §164.308(a)(1)(ii)(D) Information System Activity Review and §164.308(a)(7)(ii)(A) Data Backup Plan (provides their technical substrate); compatible with HHS-OCR 2024 ransomware-enforcement guidance via the §164.312(c)(1) Integrity substrate (Logically Air-Gapped Backup Vault cross-verification — the strongest evidence available on the AWS layer for ransomware-resilient ePHI backups).

The market split: HIPAA-focused GRC platforms (Drata HIPAA, Vanta HIPAA, Compliancy Group) automate workforce-policy + BAA-tracking workflow but lack deep cloud-infrastructure scanning; legacy scanners (Tenable, Qualys, Rapid7) produce voluminous CVE reports but don't map findings to §164.312 sub-criteria. NSAuditor's wedge is the bridge — deep scanning + HIPAA-mapped output + same Zero Data Exfiltration architecture used for SOC 2 (no BAA required — ePHI never leaves customer infrastructure).

Required vs Addressable — HHS discipline

HIPAA Security Rule specifications carry one of two HHS-defined classifications:

• Required (R) — Covered entities and business associates MUST implement the specification (with reasonable and appropriate measures for size, complexity, capabilities).
• Addressable (A) — Covered entities / BAs MUST assess whether the specification is reasonable and appropriate; if yes, implement; if not, document why AND implement an equivalent alternative that achieves the same purpose.

Misrepresenting an Addressable specification as "must-implement" or treating Required as Addressable is overclaiming — auditors specifically test for this discipline. NSAuditor surfaces the R/A classification per control in data/compliance/hipaa.json and in every rendered compliance report.

Coverage matrix — §164.312 Technical Safeguards

Source of truth is data/compliance/hipaa.json; this matrix mirrors it. The anchor-drift defense test asserts every (source, titlePattern) pair in hipaa.json exists in soc2.json (inheritance contract — closes the silent false-CLEAN class at the HIPAA mapping layer).

Read this: "Covered" means the engine produces direct evidence the auditor can attach to the §164.312 sub-criterion. "Partial" means we evidence one dimension of the control (e.g., backup-substrate integrity but not application-layer record-level checksumming) but not all of it. "Out of scope" means the control is fundamentally not addressable by infrastructure scanning — a different evidence source is required.

How to run a HIPAA scan

Once the EE package is installed and your license is activated, every scan can emit HIPAA evidence by passing --compliance hipaa. The CLI's --compliance flag accepts CSV — added in EE 0.3.0, no flag-parser change needed in 0.9.0.

For the §164.308(a)(8) Evaluation requirement (periodic technical and non-technical evaluation), run the same compliance scan on a fixed cadence; the recurring-attestation module automatically discovers prior scans, builds a chronological matrix across your assessment window, detects cadence gaps and scope drift, and emits the technical-evaluation evidence component. Pair with HR-tracked policy reviews for the non-technical component.

Dual-framework: SOC 2 + HIPAA in one scan

Pre-EE 0.9.0, the engine emitted SOC 2 artifacts only. EE 0.9.0 makes the engine framework-agnostic — loadFrameworkMap reads data/compliance/{framework}.json by parameter, schema-additive fields pass through transparently. One scan with --compliance soc2,hipaa produces separate per-framework artifacts:

HIPAA reports no longer cite SOC 2 control IDs — auditor-detectable cross-framework citation leak closed in EE 0.9.0 via the new frameworkControlCitation(framework, slot) helper. SOC 2 reports remain byte-identical apart from a single-line cosmetic citation-prefix diff (redundant "SOC 2 " prefix removed since the report-level Framework declaration already names the framework). Same findings → two evidence packs; auditors get one HIPAA pre-audit gap report and one SOC 2 pre-audit gap report from a single execution.

What you get — output artifacts

Each --compliance hipaa run writes the evidence bundle to out/<scan-id>/. Every artifact ships with a .sha256 integrity sidecar.

All artifacts can run side-by-side with the SOC 2 artifacts when --compliance soc2,hipaa is used.

Covered controls — direct evidence

For each control below, the engine produces a finding that the auditor can attach to the §164.312 sub-criterion with a stable HIPAA-grounded rationale. Patterns inherited from soc2.json's grep-verified pattern set; HIPAA-specific rationales cite §164.312 rule text and cross-reference §164.308 information-access-management (§164.308(a)(4)) where appropriate.

§164.312(a)(1) — Access Control R · Standard

"Implement technical policies and procedures for electronic information systems that maintain ePHI to allow access only to those persons or software programs that have been granted access rights as specified in §164.308(a)(4)."

§164.312(a)(2)(i) — Unique User Identification R · Implementation Spec

"Assign a unique name and/or number for identifying and tracking user identity."

§164.312(a)(2)(iv) — Encryption and Decryption A · Implementation Spec

"Implement a mechanism to encrypt and decrypt electronic protected health information." Addressable per HHS — but encryption-at-rest is the safe-harbor approach to breach-notification (45 CFR §164.402).

§164.312(b) — Audit Controls R · Standard

"Implement hardware, software, and/or procedural mechanisms that record and examine activity in information systems that contain or use ePHI." HIPAA reports cite §164.312(b) audit-controls cadence for SLA/MTTR tracking (the analog of SOC 2's CC7.1).

§164.312(d) — Person or Entity Authentication R · Standard

"Implement procedures to verify that a person or entity seeking access to ePHI is the one claimed." HIPAA reports cite §164.312(d) for identity-verification (the analog of SOC 2's CC6.2 / CC6.3).

§164.312(e)(1) — Transmission Security R · Standard

"Implement technical security measures to guard against unauthorized access to ePHI being transmitted over an electronic communications network."

§164.312(e)(2)(ii) — Encryption (Transmission) A · Implementation Spec

Subset of §164.312(e)(1) focused specifically on the encryption mechanism. Patterns mapped: crypto_agent deprecated-protocol + weak-cipher + weak-KEX; aws-rds-auditor SSL enforcement; aws-sqs-sns-auditor SecureTransport Deny; aws-elasticache-redis-auditor transit encryption; aws-ses-auditor TLS policy.

Partially Covered Controls — single-dimension evidence

For each control below, NSAuditor evidences ONE dimension of the §164.312 requirement (typically the storage-substrate dimension) but not all dimensions (typically the application-layer record-level dimension). Auditors should pair with application-tier attestations for full coverage.

§164.312(c)(1) — Integrity PARTIAL · R · Standard

"Implement policies and procedures to protect ePHI from improper alteration or destruction."

§164.312(c)(2) — Mechanism to Authenticate ePHI PARTIAL · A · Implementation Spec

"Implement electronic mechanisms to corroborate that ePHI has not been altered or destroyed in an unauthorized manner." Subset of §164.312(c)(1) focused on integrity-verification specifically — KMS-policy verifier, KMS-Grants verifier, air-gapped KMS-VPC-endpoint, S3 MFA Delete, CloudTrail log-file validation.

§164.312(e)(2)(i) — Integrity Controls (Transmission) PARTIAL · A · Implementation Spec

"Implement security measures to ensure that electronically transmitted ePHI is not improperly modified without detection until disposed of." Subset of §164.312(e)(1) focused on TLS-integrity substrate — deprecated TLS protocols (integrity-weakening), weak cipher suites (weak MAC), RDS SSL enforcement, ElastiCache transit encryption.

§164.312(c)(1) ransomware-defense substrate — the HHS-OCR angle

HHS-OCR has highlighted ransomware-resilient ePHI backups in 2024 enforcement actions. Healthcare organizations under HIPAA must demonstrate that backed-up ePHI can be restored in its last-known-good state even after a full source-account compromise. NSAuditor AI EE's aws-backup-auditor plugin provides the strongest substrate evidence available on the AWS layer for this requirement:

The mapping is at data/compliance/hipaa.json under 164.312(c)(1) (also dual-mapped to 164.312(c)(2) for the integrity-verification dimension).

Explicitly Out of Scope — what infrastructure scanning fundamentally cannot evidence

Within §164.312 (2 specs)

Entire §164.308 Administrative Safeguards (31 specs)

All §164.308 specifications cover the human-process and governance dimensions of the HIPAA Security Rule: Security Management Process, Assigned Security Responsibility, Workforce Security, Information Access Management, Security Awareness and Training, Security Incident Procedures, Contingency Plan, Evaluation, and Business Associate Contracts. These are governance, training, contractual, and policy-cycle evidence streams — they require HR systems, signed policies, training records, formal risk-register documents, and BAA legal records, none of which infrastructure scanning can produce. Pair NSAuditor with a HIPAA-focused GRC platform (Drata HIPAA, Vanta HIPAA, Compliancy Group, Tugboat Logic) for §164.308 coverage.

Note: §164.312 technical-safeguard substrate evidence DOES inform §164.308(a)(1)(ii)(D) Information System Activity Review and §164.308(a)(7)(ii)(A) Data Backup Plan (technical substrate FOR those administrative reviews), but the formal administrative-process documentation itself is OOS.

Entire §164.310 Physical Safeguards (12 specs)

All §164.310 specifications cover physical-asset and facility dimensions: Facility Access Controls, Workstation Use, Workstation Security, and Device and Media Controls. These are physical-asset evidence streams — they require building access logs, badge systems, workstation-inventory + endpoint-management records, hardware-disposal certificates (e.g., NAID-certified destruction), and physical chain-of-custody documentation. Pair NSAuditor with facilities-management + endpoint-management + asset-disposal vendors for §164.310 coverage.

The infrastructure-layer KMS-key-disposal substrate (Vault Lock, Key Vault purge protection, multi-region key controls) is mapped under §164.312(a)(2)(iv) Encryption/Decryption — the technical-safeguard counterpart to §164.310(d) media-disposal controls.

Type-I vs Type-II support for HIPAA

HIPAA does not formally use the Type-I / Type-II terminology (that's SOC 2 / SSAE 18 / ISAE 3402 convention). However, HHS-OCR audits typically expect:

• Point-in-time evidence — what's the current state of the §164.312 Technical Safeguards posture? NSAuditor produces this directly with scan_compliance_hipaa.* artifacts.
• Operating effectiveness over time — does the §164.312 posture hold over an attestation window (typically 6-12 months for HIPAA audits)? NSAuditor's recurring-scan attestation + SLA/MTTR tracking provide the cadence proof; multi-period attestation reports cover §164.312(b) audit-controls + §164.312(c)(1) integrity cadence dimensions.

Zero Data Exfiltration — no BAA required

The same architectural principle that makes NSAuditor AI EE a Zero-BAA tool for SOC 2 applies to HIPAA: ePHI never leaves customer infrastructure under any condition. Nsasoft does not see, store, or process customer ePHI. No Business Associate Agreement is needed under HIPAA §160.103 because Nsasoft is not a Business Associate — this is a self-hosted scanner, not a SaaS service. Customer credentials, scan results, and ePHI all remain in customer-managed compute; reports are written to the customer's local out/ directory.

This is the institutional differentiator vs SaaS HIPAA-focused GRC platforms (Drata HIPAA, Vanta HIPAA, Compliancy Group) — those platforms require BAAs because they process customer policy + workforce-training + BAA-tracking data SaaS-side. NSAuditor AI EE pairs with them (covering §164.308 + §164.310 surfaces they specialize in) without BAA scope creep on the §164.312 technical evidence layer.

Comparison vs the HIPAA market

Auditor FAQ

Does NSAuditor require a Business Associate Agreement?

No. Zero Data Exfiltration architecture means ePHI never leaves customer infrastructure. No BAA needed — Nsasoft is not a Business Associate under §160.103.

Does NSAuditor cover the entire HIPAA Security Rule?

No — explicitly only §164.312 Technical Safeguards. §164.308 Administrative + §164.310 Physical are architecturally out of scope. Pair with a HIPAA-focused GRC platform.

Can NSAuditor substitute for a HIPAA Risk Analysis?

No. §164.308(a)(1)(ii)(A) Risk Analysis is a formal documented process. NSAuditor produces input data the risk analysis can consume but cannot itself BE the risk analysis.

How does NSAuditor handle the Required vs Addressable distinction?

Per-control requiredOrAddressable: 'R'|'A' field in data/compliance/hipaa.json surfaced in the rendered report. Addressable specs (e.g., §164.312(a)(2)(iv) Encryption-at-rest) are not over-reported as "must implement".

What's the §164.312(c)(1) Integrity ransomware-defense angle?

HHS-OCR has highlighted ransomware-resilient ePHI backups in 2024 enforcement actions. NSAuditor's aws-backup-auditor plugin provides Logically Air-Gapped Backup Vault cross-verification (KMS policy + Grants + replicas + VPC-endpoint composite attestation). A PASS evidences that ePHI backups would survive a full source-account compromise.

Does NSAuditor support §164.314 Business Associate Contracts?

No. BAAs are legal documents managed in contract-lifecycle systems (e.g., GRC platforms, contract-management software).

How does NSAuditor handle the §164.530(j) 6-year retention requirement?

§164.530(j) is administrative — the technical floor must SUPPORT 6-year retention. NSAuditor flags audit-log retention below institutional baseline (aws-rds-auditor CloudWatch Logs retention check). Operator configures the baseline per audit-retention policy.

Why don't you include DKIM/DMARC findings in HIPAA?

DKIM/DMARC are email-authentication controls — they evidence cross-organizational sender identity assurance, NOT HIPAA Technical Safeguards. The defense test at tests/hipaa_mapping_anchor_drift.test.mjs explicitly excludes DKIM/DMARC patterns from hipaa.json.